分布式锁的几种实现

前言

针对共享资源的互斥访问历来是很多业务系统需要解决的问题。用到分布式锁说明遇到了多个进程共同访问同一个资源的问题。

一般是在两个场景下会防止对同一个资源的重复访问:

  • 提高效率。比如多个节点计算同一批任务,如果某个任务已经有节点在计算了,那其他节点就不用重复计算了,以免浪费计算资源。不过重复计算也没事,不会造成其他更大的损失。也就是允许偶尔的失败。
  • 保证正确性。这种情况对锁的要求就很高了,如果重复计算,会对正确性造成影响。这种不允许失败。

引入分布式锁势必要引入一个第三方的基础设施,比如 MySQL,Redis,Zookeeper 等。本文聊聊各种实现的方案。

1. 单机锁和分布式锁

由此抽象一下分布式锁的概念,首先分布式锁需要是一个资源,这个资源能够提供并发控制,并输出一个排他性的状态,也就是:

锁 = 资源 + 并发控制 + 所有权展示

以常见的单机锁为例:

  • Spinlock = BOOL +CAS(乐观锁)
  • Mutex = BOOL + CAS + 通知(悲观锁)

Spinlock 和 Mutex 都是一个 Bool 资源,通过原子的 CAS 指令:当现在为 0 设置为 1,成功的话持有锁,失败的话不持有锁,如果不提供所有权的展示,例如 AtomicInteger,也是通过资源(Interger)+ CAS,但是不会明确的提示所有权,因此不会被视为一种锁,当然,可以将“所有权展示”这个更多地视为某种服务提供形式的包装。

单机环境下,内核具备“上帝视角”,能够知道进程的存活,当进程挂掉的时候可以将该进程持有的锁资源释放,但发展到分布式环境,这就变成了一个挑战,为了应对各种机器故障、宕机等,就需要给锁提供了一个新的特性:可用性。

如下图所示,任何提供三个特性的服务都可以提供分布式锁的能力,资源可以是文件、KV 等,通过创建文件、KV 等原子操作,通过创建成功的结果来表明所有权的归属,同时通过 TTL 或者会话来保证锁的可用性,通过超时释放,可以避免死锁。
分布式锁的特性和实现.jpg

2. 分布式锁的系统分类

根据锁资源本身的安全性,我们将分布式锁分为两个阵营:

  • 基于异步复制的分布式系统,例如 mysql,tair,redis 等。

  • 基于 paxos 协议的分布式一致性系统,例如 zookeeper,etcd,consul 等。

基于异步复制的分布式系统,存在数据丢失(丢锁)的风险,不够安全,往往通过 TTL 的机制承担细粒度的锁服务,该系统接入简单,适用于对时间很敏感,期望设置一个较短的有效期,执行短期任务,丢锁对业务影响相对可控的服务。

基于 paxos 协议的分布式系统,通过一致性协议保证数据的多副本,数据安全性高,往往通过租约(会话)的机制承担粗粒度的锁服务,该系统需要一定的门槛,适用于对安全性很敏感,希望长期持有锁,不期望发生丢锁现象的服务。

2.1 Redis 实现

Redis 客户端加锁也要根据Redis 部署情况来使用不同的加锁方式。

2.1.1 单机Redis的分布式锁

单机方式可根据lua脚本实现

思路大概是这样的:在redis中设置一个值表示加了锁,然后释放锁的时候就把这个key删除。具体代码是这样的:

// 获取锁  
// NX是指如果key不存在就成功,key存在返回false,PX可以指定过期时间 
      SET d_lock unique_value NX PX 30000
// 释放锁:通过执行一段lua脚本 
// 释放锁涉及到两条指令,这两条指令不是原子性的  
// 需要用到redis的lua脚本支持特性,redis执行lua脚本是原子性的   
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])    
else
    return 0
end

这种方式有两大要点:

1)一定要用SET key value NX PXmilliseconds 命令

如果不用,先设置了值,再设置过期时间,这个不是原子性操作,有可能在设置过期时间之前宕机,会造成死锁(key永久存在)。

2)value要具有唯一性

这个是为了在解锁的时候,需要验证value是和加锁的一致才删除key。

这是避免了一种情况:假设A获取了锁,过期时间30s,此时35s之后,锁已经自动释放了,A去释放锁,但是此时可能B获取了锁。A客户端就不能删除B的锁了。

如果采用单机部署模式,会存在单点问题,只要redis故障了。加锁就不行了。

2.1.2 集群分布式

redis 集群分布式集群方式有两种

  • master-slave + sentinel选举模式
  • redis cluster模式

集群使用redis锁的问题:
采用master-slave模式,如果设置锁之后,主机在传输到从机的时候挂掉了,从机还没有加锁信息,如何处理?即采用master-slave模式,加锁的时候只对一个节点加锁,即便通过sentinel做了高可用,但是如果master节点故障了,发生主从切换,此时就会有可能出现锁丢失的问题。

redis cluster 模式下,edis的作者提出可依据RedLock算法:
这个算法的意思大概是这样的:假设redis的部署模式是redis cluster,总共有6个master节点,通过以下步骤获取一把锁:

1.获取当前时间戳,单位是毫秒;

2.轮流尝试在每个master节点上创建锁,过期时间设置较短,一般就几十毫秒;

3.尝试在大多数节点上建立一个锁,比如5个节点就要求是3个节点(n / 2+1);

4.客户端计算建立好锁的时间,如果建立锁的时间小于超时时间,就算建立成功了;

5.要是锁建立失败了,那么就依次删除这个锁;

6.只要别人建立了一把分布式锁,你就得不断轮询去尝试获取锁。

但是这样的这种算法还是颇具争议的,可能还会存在不少的问题,无法保证加锁的过程一定正确。

基于Redission的实现:

Javaer都知道Jedis,Jedis是Redis的Java实现的客户端,其API提供了比较全面的Redis命令的支持。Redission也是Redis的客户端,相比于Jedis功能简单。Jedis简单使用阻塞的I/O和redis交互,Redission通过Netty支持非阻塞I/O。

Redission封装了锁的实现,其继承了java.util.concurrent.locks.Lock的接口,让我们像操作我们的本地Lock一样去操作Redission的Lock,下面介绍一下其如何实现分布式锁。

如果自己写代码来通过redis设置一个值,是通过下面这个命令设置的。

SET d_lock unique_value NX PX 30000

这里设置的超时时间是30s,假如我超过30s都还没有完成业务逻辑的情况下,key会过期,其他线程有可能会获取到锁。这样一来的话,第一个线程还没执行完业务逻辑,第二个线程进来了也会出现线程安全问题。所以我们还需要额外的去维护这个过期时间,太麻烦了~我们来看看redisson是怎么实现的:

 Config config = new Config();
       config.useClusterServers()
        .addNodeAddress("redis://192.168.1.101:7001")
        .addNodeAddress("redis://192.168.1.101:7002")
        .addNodeAddress("redis://192.168.1.101:7003")
        .addNodeAddress("redis://192.168.1.102:7001")
        .addNodeAddress("redis://192.168.1.102:7002")
        .addNodeAddress("redis://192.168.1.102:7003");
        RedissonClient redisson = Redisson.create(config);
        RLock lock = redisson.getLock("d_lock");
        lock.lock();
        lock.unlock();

我们只需要通过它的api中的lock和unlock即可完成分布式锁,他帮我们考虑了很多细节:

  • redisson所有指令都通过lua脚本执行,redis支持lua脚本原子性执行

  • redisson设置一个key的默认过期时间为30s,如果某个客户端持有一个锁超过了30s怎么办?

redisson中有一个watchdog的概念,翻译过来就是看门狗,它会在你获取锁之后,每隔10秒帮你把key的超时时间设为30s

这样的话,就算一直持有锁也不会出现key过期了,其他线程获取到锁的问题了。

  • redisson的“看门狗”逻辑保证了没有死锁发生

(如果机器宕机了,看门狗也就没了。此时就不会延长key的过期时间,到了30s之后就会自动过期了,其他线程可以获取到锁)

看门狗.png

Redis小结
优点: 对于Redis实现简单,性能对比ZK和Mysql较好。如果不需要特别复杂的要求,那么自己就可以利用setNx进行实现,如果自己需要复杂的需求的话那么可以利用或者借鉴Redission。对于一些要求比较严格的场景来说的话可以使用RedLock。

缺点: 需要维护Redis集群,如果要实现RedLock那么需要维护更多的集群。

2.2 Zookeeper 实现

zk实现分布式锁的落地方案:

  1. 使用zk的临时节点和有序节点,每个线程获取锁就是在zk创建一个临时有序的节点,比如在/lock/目录下。

  2. 创建节点成功后,获取/lock目录下的所有临时节点,再判断当前线程创建的节点是否是所有的节点的序号最小的节点

  3. 如果当前线程创建的节点是所有节点序号最小的节点,则认为获取锁成功

  4. 如果当前线程创建的节点不是所有节点序号最小的节点,则对节点序号的前一个节点添加一个事件监听。

比如当前线程获取到的节点序号为/lock/003,然后所有的节点列表为:

[/lock/001,/lock/002,/lock/003],则对/lock/002这个节点添加一个事件监听器。

如果锁释放了,会唤醒下一个序号的节点,然后重新执行第3步,判断是否自己的节点序号是最小。
比如/lock/001释放了,/lock/002监听到时间,此时节点集合为[/lock/002,/lock/003],则/lock/002为最小序号节点,获取到锁。
整个过程如下:
zk实现分布式锁.png

Curator

Curator是一个zookeeper的开源客户端,也提供了分布式锁的实现。

他的使用方式也比较简单:


InterProcessMutex ipm = new InterProcessMutex(client,"/d_lock");
                        ipm.acquire();
                        ipm.release();

其实现分布式锁的核心源码如下:

 while ( (client.getState() == CuratorFrameworkState.STARTED) && !haveTheLock ) {
            // 获取当前所有节点排序后的集合  
            List<String> children = getSortedChildren();
            // 获取当前节点的名称   
            String sequenceNodeName = ourPath.substring(basePath.length() + 1); 
            // 判断当前节点是否是最小的节点  
            PredicateResults   predicateResults = driver.getsTheLock(client, children, sequenceNodeName, maxLeases);
            if ( predicateResults.getsTheLock() ) {
                // 获取到锁    
                haveTheLock = true;
            } else {
                // 没获取到锁,对当前节点的上一个节点注册一个监听器    
               ……
             }
        }

2.3 基于数据库实现

2.3.1 基于数据库表的排它锁

锁信息存储表结构如下:

CREATE TABLE `t_ms_lock` (
    `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
    `name` varchar(64) NOT NULL DEFAULT '' COMMENT '锁定的方法名',
    `desc` varchar(1024) NOT NULL DEFAULT '描述',
    `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存数据时间',
    PRIMARY KEY (`id`),
    UNIQUE KEY `uidx_name` (`name `) USING BTREE
  ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';

当我们想要锁住某个方法时,执行以下SQL:

insert into t_ms_lock(name,desc) values ('name','desc');

因为我们对name做了唯一性约束,这里如果有多个请求同时提交到数据库的话,数据库会保证只有一个操作可以成功,那么我们就可以认为操作成功的那个线程获得了该方法的锁,可以执行方法体内容。
当方法执行完毕之后,想要释放锁的话,需要执行以下Sql:

delete from t_ms_lock where name ='name';

上面这种简单的实现有以下几个问题:

  • 这把锁强依赖数据库的可用性,数据库是一个单点,一旦数据库挂掉,会导致业务系统不可用;

    • 对于数据库是单点可以搞两个数据库,数据之前双向同步。一旦挂掉快速切换到备库上;但切换也是单点?
  • 这把锁没有失效时间,一旦解锁操作失败,就会导致锁记录一直在数据库中,其他线程无法再获得到锁;

    • 对于没有失效时间,只要做一个定时任务,每隔一定时间把数据库中的超时数据清理一遍;
  • 这把锁只能是非阻塞的,因为数据的insert操作,一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列,要想再次获得锁就要再次触发获得锁操作;

    • 对于非阻塞:搞一个while循环,直到insert成功再返回成功;
  • 这把锁是不可重入的,同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。

    • 对于非重入, 在数据库表中加个字段,记录当前获得锁的机器的主机信息和线程信息,那么下次再获取锁的时候先查询数据库,如果当前机器的主机信息和线程信息在数据库可以查到的话,直接把锁分配给他就可以了。

2.3.2 基于数据库的排它锁

除了可以通过增删操作数据表中的记录以外,其实还可以借助数据中自带的锁来实现分布式的锁。

基于MySql的InnoDB引擎,可以使用以下方法来实现加锁操作:

public boolean lock(){
      connection.setAutoCommit(false)
      while(true){
 result = select * from t_ms_lock where name=xxx for update;
          if(result==null){
              return true;
          }
      }
      return false;
  }

在查询语句后面增加forupdate,数据库会在查询过程中给数据库表增加排他锁。当某条记录被加上排他锁之后,其他线程无法再在该行记录上增加排他锁。(这里再多提一句,InnoDB引擎在加锁的时候,只有通过索引进行检索的时候才会使用行级锁,否则会使用表级锁。这里我们希望使用行级锁,就要给method_name添加索引,值得注意的是,这个索引一定要创建成唯一索引,否则会出现多个重载方法之间无法同时被访问的问题。重载方法的话建议把参数类型也加上)

我们可以认为获得排它锁的线程即可获得分布式锁,当获取到锁之后,可以执行方法的业务逻辑,执行完方法之后,再通过以下方法解锁:

public void unlock(){
        connection.commit();
    }

这里还可能存在另外一个问题,虽然我们对name 使用了唯一索引,并且显示使用for update来使用行级锁。但是,MySql会对查询进行优化,即便在条件中使用了索引字段,但是否使用索引来检索数据是由MySQL 通过判断不同执行计划的代价来决定的,如果 MySQL 认为全表扫效率更高,比如对一些很小的表,它就不会使用索引,这种情况下 InnoDB 将使用表锁,而不是行锁。如果发生这种情况就悲剧了。。。

还有一个问题,就是我们要使用排他锁来进行分布式锁的lock,那么一个排他锁长时间不提交,就会占用数据库连接。一旦类似的连接变得多了,就可能把数据库连接池撑爆。

2.3.3 基于数据库的乐观锁

大多数是基于数据版本(version)的记录机制实现的。何谓数据版本号?即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库表添加一个“version”字段来实现读取出数据时,将此版本号一同读出,之后更新时,对此版本号加1。在更新过程中,会对版本号进行比较,如果是一致的,没有发生改变,则会成功执行本次操作;如果版本号不一致,则会更新失败。

注意ABA 问题等。

3. 比较总结

对于redis的分布式锁而言,它有以下缺点:

它获取锁的方式简单粗暴,获取不到锁直接不断尝试获取锁,比较消耗性能。另外来说的话,redis的设计定位决定了它的数据并不是强一致性的,在某些极端情况下,可能会出现问题。锁的模型不够健壮,即便使用redlock算法来实现,在某些复杂场景下,也无法保证其实现100%没有问题。但是另一方面使用redis实现分布式锁在很多企业中非常常见,而且大部分情况下都不会遇到所谓的“极端复杂场景”,所以使用redis作为分布式锁也不失为一种好的方案,最重要的一点是redis的性能很高,可以支撑高并发的获取、释放锁操作。

zookeeper天生设计定位就是分布式协调,强一致性。锁的模型健壮、简单易用、适合做分布式锁。如果获取不到锁,只需要添加一个监听器就可以了,不用一直轮询,性能消耗较小。

但是如果有较多的客户端频繁的申请加锁、释放锁,对于zk集群的压力会比较大。

我们介绍了几种分布式锁的实现方式,并进行了一些优缺点比较,哪种方式都无法做到完美。就像CAP一样,在复杂性、可靠性、性能等方面无法同时满足,所以需要根据不同的应用场景选择最适合的方式。

比较角度 结果
从理解的难易程度角度(从低到高) 数据库 > 缓存 > Zookeeper
从实现的复杂性角度(从低到高) Zookeeper >= 缓存 > 数据库
从性能角度(从高到低) 缓存 > Zookeeper >= 数据库
从可靠性角度(从高到低) Zookeeper > 缓存 > 数据库

References:

posted @ 2020-11-30 10:05  胖大星-  阅读(1407)  评论(0编辑  收藏  举报