聊聊分布式锁

最新推荐文章于 2024-01-10 16:55:53 发布

huangshanchun

最新推荐文章于 2024-01-10 16:55:53 发布

阅读量216

点赞数

分类专栏：系统设计&架构设计

本文链接：https://blog.csdn.net/huangshanchun/article/details/106441090

版权

系统设计&架构设计专栏收录该内容

13 篇文章 3 订阅

订阅专栏

0 概述

本文将what（是什么、使用场景）、how（如何实现，实现原理）、why （为什么这么实现）来分析下分析下分布式锁。

1 什么是分布式锁

1.1 分布式锁简介

分布式锁是控制分布式系统之间同步访问共享资源的一种方式，分布式锁。分布式锁是解决分布式系统之间进程之间访问共享资源同步机制，本地锁如java lock 是解决一个进程中多线程并发同步机制，它不适于分分布式场景（多进程）。

1.2 分布式锁使用场景

分布式系统幂等设计、秒杀、分布式共享资源访问等等

2 如何实现&实现原理

2.1实现分布式锁条件

1.互斥性：在任意时刻，只有一个客户端（线程）能持有锁。其实也就要求加锁必须是原子性的。
2.不能出现死锁：如何某个客户端在加锁成功系统宕机锁没有主动释放，也要保住后续其它客户端（线程）能继续加锁
3.可靠性：多节点的，不会因为某个节点挂掉导致分布锁无法获取和释放

2.2常见的实现方案

基于数据库表（不推荐使用）
使用SQL的唯一键或者悲观锁（数据库需要支持事务）


CREATE TABLE `lock_table` (
  `id` bigint(20)  NOT NULL AUTO_INCREMENT COMMENT '主键',
  `key` varchar(64) NOT NULL  COMMENT '锁定的key',
  `desc` varchar(128) NOT NULL  '备注信息',
  `create_time` datetime NOT NULL COMMIT '创建时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uidx_key` (`key`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='锁表';

唯一键使用，加锁时候直接插入，捕获唯一键冲突转换成加锁失败。释放锁就直接删除key。问题：1）锁没有失效时间，旦解锁操作失败，就会导致锁记录一直在数据库中（可以考虑做个定时任务，定时清理下或者加锁之前查询一下比较时间）2）不可重入，也可考虑先查询一把

基于缓存（redis、tair）实现，如下图使用redis 命令
NX 代表只在键不存在时，才对键进行设置操作，PX 9000 设置键的过期时间为9000毫秒，设置过期时间可以防止死锁。

 SET lock_key lock_value NX PX 9000

解锁的过程就是将lock_key键删除，但是不能误删，比如：一个客户端A（线程）加锁成功并在处理中，执行时间过长，锁过期释放了；另一个客户端B(线程)加锁成功，执行过程中，等待A执行完就会B的锁释放。因此在执行删除的时候要判断lock_value 是否相等，可以考虑使用lua 脚本让删除变成一个原子操作。

del lock_key

// lua 脚本
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

基于redis 实现分布式锁比较简单，但是基于redis实现分布式锁是不可重入的，另外redis实现的分布式锁一定可靠吗？
答案是否定的，因为redis 是AP（CAP理论）并不是强一致性的。主从复制是异步的，也就是一个客户端（线程）在master加锁成功后，突然宕机，可能此时slave 上还没有数据；那么此时另一个客户端（线程）就能加锁成功。
为了解决这些问题，redis 作者提出了redlock算法
算法描述
1.获取当前时间毫秒
2.尝试使用相同的key和随机的value为N个实例进行加锁。当为每个实例设置锁的时候，客户端用一个较小的超时时间，相比于锁的的过期时间。比如一个锁的过期时间是10s那么每个客户端加锁的超时时间应该在5-50ms。
3.计算出获取锁所消耗是时间如小于锁的过期时间，并且成功设置锁的实例数>= N/2 + 1，那么加锁成功。如果获取失败，要释放所有的实例

redlock 算法也没有从本质上解决掉master 宕机问题导致的锁不可靠，且性能不是不高，目前在企业用到不是特别多。

基于Zookeeper实现分布式锁
用Zookeeper不能重复创建一个节点的特性来实现一个分布式锁，这看起来和redis实现分布式锁很像。但是Zookeeper是cp 的很好的解决redis 加锁不可靠以及可重入的问题。但是其在性能上&并发控制上上不如使用缓存实现分布式锁且高可用上，其在选主的过程中其是不可用的。

可以直接使用zookeeper第三方库Curator客户端，这个客户端中封装了一个可重入的锁服务。

InterProcessMutex lock = new InterProcessMutex(client, lockPath);
if ( lock.acquire(maxWait, waitUnit) ) 
{
    try 
    {
        // do some work
    }
    finally
    {
        lock.release();
    }
}