分布式锁的实现

基于Redis实现分布式锁

redis单进程、单线程，唯一线程串行化处理。

实现方式：

    redis setnx命令在指定的key不存在时，为key设置指定的值。

    setnx keyname value expire time ：设置成功，返回1，设置失败，返回0。

存在问题：

    锁时间不可控，无法续租期。

    单点问题：单实例存在进程一旦死掉，会彻底阻塞业务流程；主从方式，主从数据异步，会存在锁失效问题。（极端情况下，高可用无法保证，所以在交易场景这种锁是不ok的，但是在一些社交场景也ok）

官方建议：

    redis本身建议使用rediock（相当于RAFT）算法来保证，但是问题是需要至少三个redis主从实例来完成，维护成本相对较高。rediock等同于自己实现简单的一致性协议，细节繁琐，且容易出错

 

if (conn.setnx(lockKey, value) == 1) {

 }

基于zookeeper实现的分布式锁

一般用Zookeeper实现分布式锁有两种方案:

• 基于Zookeeper不能重复创建同一个节点
  利用名称唯一性，加锁操作时，只需要所有客户端一起创建/Lock/test节点，只有一个创建成功，成功者获得锁。解锁时，只需删除/Lock/test节点，其余客户端再次进入竞争创建节点，直到所有客户端都获得锁.
  这种方案的正确性和可靠性是ZooKeeper机制保证的，实现简单。缺点是会产生“惊群”效应，假如许多客户端在等待一把锁，当锁释放时候所有客户端都被唤醒，仅仅有一个客户端得到锁。
• 基于临时有序节点
  对于加锁操作，可以让所有客户端都去/Lock目录下创建临时顺序节点，如果创建的客户端发现自身创建节点序列号是/Lock/目录下最小的节点，则获得锁。否则，监视比自己创建节点的序列号小的节点（比自己创建的节点小的最大节点）.进入等待。对于解锁操作，只需要将自身创建的节点删除即可,然后唤醒自己的后一个节点。
  特点：利用临时顺序节点来实现分布式锁机制其实就是一种按照创建顺序排队的实现。这种方案效率高，避免了“惊群”效应，多个客户端共同等待锁，当锁释放时只有一个客户端会被唤醒。

由于Curator客户端已经提供了分布式锁的实现,可以直接使用如下代码:

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

基于数据库实现分布式锁

利用DB来实现分布式锁，有两种方案。两种方案各有好坏，但是总体效果都不是很好。但是实现还是比较简单的。

1. 利用主键唯一约束：
   我们知道数据库是有唯一主键规则的，主键不能重复，对于重复的主键会抛出主键冲突异常。
   其实这和分布式锁实现方案基本是一致的，首先我们利用主键唯一规则，在争抢锁的时候向DB中写一条记录，这条记录主要包含锁的id、当前占用锁的线程名、重入的次数和创建时间等，如果插入成功表示当前线程获取到了锁，如果插入失败那么证明锁被其他人占用，等待一会儿继续争抢，直到争抢到或者超时为止
2. 利用Mysql行锁的特性：
   利用for update加显式的行锁，这样就能利用这个行级的排他锁来实现分布式锁了，同时unlock的时候只要释放commit这个事务，就能达到释放锁的目的。

基于 ETCD的分布式锁

机制

etcd 支持以下功能，正是依赖这些功能来实现分布式锁的：

• Lease 机制：即租约机制（TTL，Time To Live），Etcd 可以为存储的 KV 对设置租约，当租约到期，KV 将失效删除；同时也支持续约，即 KeepAlive。
• Revision 机制：每个 key 带有一个 Revision 属性值，etcd 每进行一次事务对应的全局 Revision 值都会加一，因此每个 key 对应的 Revision 属性值都是全局唯一的。通过比较 Revision 的大小就可以知道进行写操作的顺序。
• 在实现分布式锁时，多个程序同时抢锁，根据 Revision 值大小依次获得锁，可以避免 “羊群效应” （也称 “惊群效应”），实现公平锁。
• Prefix 机制：即前缀机制，也称目录机制。可以根据前缀（目录）获取该目录下所有的 key 及对应的属性（包括 key, value 以及 revision 等）。
• Watch 机制：即监听机制，Watch 机制支持 Watch 某个固定的 key，也支持 Watch 一个目录（前缀机制），当被 Watch 的 key 或目录发生变化，客户端将收到通知。

过程

实现过程：

• 步骤 1: 准备

客户端连接 Etcd，以 /lock/mylock 为前缀创建全局唯一的 key，假设第一个客户端对应的 key="/lock/mylock/UUID1"，第二个为 key="/lock/mylock/UUID2"；客户端分别为自己的 key 创建租约 - Lease，租约的长度根据业务耗时确定，假设为 15s；

• 步骤 2: 创建定时任务作为租约的“心跳”

当一个客户端持有锁期间，其它客户端只能等待，为了避免等待期间租约失效，客户端需创建一个定时任务作为“心跳”进行续约。此外，如果持有锁期间客户端崩溃，心跳停止，key 将因租约到期而被删除，从而锁释放，避免死锁。

• 步骤 3: 客户端将自己全局唯一的 key 写入 Etcd

进行 put 操作，将步骤 1 中创建的 key 绑定租约写入 Etcd，根据 Etcd 的 Revision 机制，假设两个客户端 put 操作返回的 Revision 分别为 1、2，客户端需记录 Revision 用以接下来判断自己是否获得锁。

• 步骤 4: 客户端判断是否获得锁

客户端以前缀 /lock/mylock 读取 keyValue 列表（keyValue 中带有 key 对应的 Revision），判断自己 key 的 Revision 是否为当前列表中最小的，如果是则认为获得锁；否则监听列表中前一个 Revision 比自己小的 key 的删除事件，一旦监听到删除事件或者因租约失效而删除的事件，则自己获得锁。

• 步骤 5: 执行业务

获得锁后，操作共享资源，执行业务代码。

• 步骤 6: 释放锁

完成业务流程后，删除对应的key释放锁。

 

建议选择etcd实现分布式锁（redis也可以）

    简单KV、强一致、高可用（无单点）、数据高可靠（持久化）

获取锁平均耗时：

    获取锁的平均耗时大概是在2.1ms左右。

    由于etcd的强一致性，根据raft算法，消耗时间稍微长一点。

 

etcd兼容性测试：

    etcd提供了独有的集群管理模式，方便进行极端case下的测试，以三个节点的etcd集群为例：

        1.单节点停机，不影响持续写入，不影响读，结果有一致性。

        2.当只有一个节点时，读会停机，写入正常。

        3.理论上只要不是多节点同时停机，线上服务不会受影响。

 

etcd恢复/版本：

    etcd有自有的数据恢复方式，如果服务停机后，可以将所有数据转移重启。

    etcd的增删节点，节点迁移等部署相关，均有相关操作方式。

    etcd版本选择，选择用etcd3.2.9，因为V3 API暂时还不够完备，建议用V2方式实现：

        V3提供gRPC接口，天然提供分布式锁功能：只需申请锁、释放锁，不用关注锁的租期问题。