Redis 分布式锁的进阶之旅

逃离我推掉我的手 2024-03-26 19:48 57阅读 0赞

在分布式系统中，针对共享资源的互斥访问 (mutually exclusive access) 一直是很多业务系统需要解决的问题，而**分布式锁**常常作为一种通用的解决方案被提出来。互斥能力一般是由第三方中间件来提供，比如：Redis 、ZooKeeper 和 Etcd 等；当然 MySQL 也是可以的，我们可以新建一个专门的锁表 (tbl\_lock)，数据插入成功意味着抢占到了锁，而数据删除成功则意味着释放了锁，在数据没有删除的情况下，另一客户端试图抢占该锁 (即插入一条记录) 的话则会报主键重复的错误。

### 1 Redis 分布式锁的进阶之旅 ###

#### 1.1 key 的设计 ####

key 要能够全局地标识共享资源的唯一性，一般多选择 bizKey 来充当。

#### 1.2 锁的粒度 ####

锁的粒度尽量精细一些。比如在一个长流程的业务逻辑中，只有扣减库存才涉及对共享资源的互斥访问，那就应该只针对扣减库存逻辑进行锁的抢占与释放。

#### 1.3 锁的释放 ####

锁一旦抢占成功，待业务逻辑执行完毕，必须要显式地释放掉，建议将释放锁的逻辑放在`finally`代码块中；此外，锁只能由持有该锁的对象来释放，绝不允许出现“张三释放了李四持有的锁”这一现象。

大家觉得下面这段伪代码在锁的释放上有啥问题？

String rst = jedis.set(bizKey, randomIntValue, SetParams.setParams().nx().px(30));
    if (!OK.equals(rst)) {
        return;
    }
    try {
        doBizAction();
    } finally {
        jedis.del(bizKey);
    }

想象一下，如果 Client 1 抢占到了锁之后发生了 Full GC，整个 JVM 进程卡在那里不动了，业务逻辑当然是不会执行的，当 Full GC 执行完毕后锁已经过期而被 Redis 自动释放掉了；然后 Client 2 将会抢占到该锁，此时 Client 1 执行完业务逻辑之后会把 Client 2 持有的锁给释放掉。如下图所示。

![format_png][]

针对这一问题，我们可以在抢占锁的时候将 requestId 作为 value，改进版伪代码如下所示。

String rst = jedis.set(bizKey, requestId, SetParams.setParams().nx().px(30));
    if (!OK.equals(rst)) {
        return;
    }
    try {
        doBizAction();
    } finally {
        if(requestId.equals(jedis.get(bizKey))) {
            jedis.del(bizKey);
        }
    }

很遗憾，这么改还是有问题，主要体现在 get()、equals() 和 del() 这三个操作不满足原子性。如果在执行 get() 操作之后发生了 Full GC，当 JVM 进程恢复后 Client 1 所持有的锁已经过期而被释放，此时 Client 2 成功抢占到了该锁，可此时 Client 1 所在线程会继续执行 equals() 和 del() 操作，也就是说 Client 1 还是释放掉了 Client 2 持有的锁。如下图所示。

![format_png 1][]

显然，此时我们需要使用 lua 脚本来确保 get()、equals() 和 del() 这三个操作满足原子性即可。lua 脚本如下所示。

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

#### 1.4 死锁 ####

锁一定要有过期时间，万一持有锁的对象无法释放掉锁，那么该锁后续也就无法再次被持有了。

#### 1.5 锁过期时间的设定 ####

![format_png 2][]

如果锁过期时间设定过短，那么在业务还未执行完毕的情况下，锁可能被别人抢占了；而过期时间设定过长，又会严重影响业务的吞吐量。比较好的方案是开启一个线程来不断续期，Redisson 就是这么干的，下一章节会详细介绍。

#### 1.6 抢占锁失败之后的处理方式 ####

抢占锁失败之后，一般有两种处理方式。1) 直接抛出异常从而让用户重试，存在用户体验不佳的问题；2) 通过自旋机制不断地重新抢占锁，该方案在高并发场景下并不可取，因为会导致 CPU 资源的浪费。笔者这里蹭个热点，来看看 ChatGPT 是如何回答该问题的。

![format_png 3][]

#### 1.7 异步复制 ####

为了构建高可用的 Redis 服务，往往很少选择单节点或者单纯的 master-slave 部署架构，一般会选择哨兵 (Sentinel) 或 集群 (Cluster) 部署架构。在哨兵和集群架构中，一个 master 节点总会有一个或多个 slave 节点，毕竟为了高可用，数据冗余是必须的，而在 master 节点通过异步复制 (asynchronous replication) 机制将数据传递到若干 slave 节点过程中，由于没有 ZooKeeper 那种强一致性共识协议，这可能造成数据不一致的现象，也就是说分布式锁的互斥性在 Redis 中是无法做到百分之百可靠的！

![format_png 4][]

如上图所示。Client 1 成功抢占到了锁；紧接着 master 节点挂点了，从而导致数据无法传递到 slave 节点；然后 salve 节点晋升为新的 master 节点；最终，Client 2 将会抢占到该锁。

为了解决这一问题，Redis 的设计者 antirez 提出了大名鼎鼎的 [RedLock][] 方案。RedLock 方案的前提是需要 N 个 Redis master 节点，这些 master 节点之间是完全相互独立的，不存在任何异步复制操作！RedLock 的核心思想：依次向 N 个 master 节点发起抢占锁的请求，如果在至少`N/2+1`个 master 节点中成功地抢占了锁，那么就认为最终锁抢占成功。

Martin Kleppmann 大神在其 [How to do distributed locking][] 一文中，评价 RedLock 是一种不伦不类、完全建立在三种假设基础上的分布式锁方案。这三种假设如下。

*  进程暂停 (processe pausing) ，假设进程暂停时间远远小于锁的过期时间。
 *  网络时延 (network delaying) ，假设网络时延远远小于锁的过期时间。
 *  时钟漂移 (clock drift) ，假设锁在所有 Redis 节点中的存活时间与其过期时间是相匹配的。

Redis 是由 C 语言开发而来的，自然不存在进程暂停之说，其实进程暂停的对象指的是 Redis 客户端，比如一个 Spring Boot 应用。Martin Kleppmann 给出了一个由 Redis 客户端进程暂停造成数据不一致的典型场景，如下图所示。

![format_png 5][]

针对上述问题，Martin Kleppmann 给出了一个名为 fencing token 的解决方案，如下图所示。

![format_png 6][]

### 2 Redisson 部分源码解读 ###

Redisson 应该是当前市面上最强大的一款 Redis 分布式锁解决方案了，使用起来比较省心，很多问题都替你考虑到了。

Config config = new Config();
    config.setLockWatchdogTimeout(30000)
            .useSingleServer()
            .setAddress("redis://127.0.0.1:6379")
            .setDatabase(0);
    RedissonClient redissonClient = Redisson.create(config);
    
    RLock lock = redissonClient.getLock("my-lock");
    boolean rst = lock.tryLock();
    try {
        if (rst) {
            doBizAction();
        }
    } finally {
        if (lock.isLocked() && lock.isHeldByCurrentThread()) {
            lock.unlock();
        }
    }
    
    redissonClient.shutdown();

`RedissonSpinLock`和`RedissonLock`是 Redisson 中两个极为常用的非公平、可重入锁。RedissonSpinLock 与 RedissonLock 最大的区别在于它没有将“发布-订阅”机制整合到锁的抢占与释放流程中，这应该是有意为之。因为在大规模 Redis Cluster 中，“发布-订阅”机制会产生**广播风暴**。具体地，Redis 的“发布-订阅”机制是按照 channel (通道) 来进行发布与订阅的，然后在 Redis Cluster 模式下，channel 不会参与基于 hash 值的 slot 分发，也就是说发布的消息将以广播的形式在集群中传播开来。那么问题是显而易见的，假设一个 Redis Cluster 中有 100 个分片主节点；用户在节点 1 发布消息，该节点就会把消息广播给其他 99 个节点；若在这 99 个节点中，只有零星几个节点订阅了该 channel，这势必会造成网络、CPU 等资源的浪费。幸运的是，Redis 7.0 终于支持`Sharded Pub/Sub`特性了。

RedissonSpinLock 与 RedissonLock 均使用 Redis Hash 数据结构来承载锁的抢占与释放动作，lockName 用于标识一个 Hash 实例，Hash 中的 key 由`UUI`

[format_png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/a9b844f3b617441d9b580246fd350385.png
[format_png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/f6947b3122024f688b4aa74a3afec42c.png
[format_png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/b62037d0b5414b5d97bd16b5475dcce0.png
[format_png 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/f029323043f04060bdb07914b7005e72.png
[format_png 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/4ecd29458e9d41b9aa7393f2058063ec.png
[RedLock]: https://link.juejin.cn?target=https%3A%2F%2Fredis.io%2Fdocs%2Fmanual%2Fpatterns%2Fdistributed-locks%2F
[How to do distributed locking]: https://link.juejin.cn?target=https%3A%2F%2Fmartin.kleppmann.com%2F2016%2F02%2F08%2Fhow-to-do-distributed-locking.html
[format_png 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/65570bd7fff14e0bbcd83b34a1ba212e.png
[format_png 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/332d2aa74da74e1894ad558608406063.png