Redis 分布式锁进阶：从看门狗到 Redlock 的高可用实践

一、缓存与锁的核心痛点：过期时间与高可用

在 Redis 缓存和分布式锁的实践中，有两个绕不开的核心问题：

1. 过期时间失控：如果业务执行时间超过缓存或锁的过期时间，会导致缓存失效或锁被提前释放，引发数据不一致或并发冲突。

2. 单点故障风险：单节点 Redis 宕机时，缓存和锁服务会完全中断，影响业务可用性。

为了解决这些问题，Redis 引入了看门狗（Watch Dog）和Redlock机制，分别应对过期时间失控和单点故障风险。

---

二、看门狗（Watch Dog）：自动续期的安全保障

过期时间的续约问题.

要在加锁的时候，给key设定过期时间.

过期时间，设置多少合适??

*如果设置的短，就可能在你的业务逻辑还没执行完，就释放锁了.

*如果设置的太长，就也会导致"锁释放不及时"问题.

更好的方式，是"动态续约"

往往也需要服务器这边有一个专门的线程，负责续约这个事情

把这个负责的线程，叫做"看门狗"(watch dog)

这也是一个比较广义的概念.很多场景都会涉及到这种

针对过期时间的操作.很多时候就会引入"看门狗"

1. 什么是看门狗？

看门狗是一种自动续期机制，用于解决"业务执行时间超过锁过期时间"的问题。它的核心逻辑是：

• 客户端获取锁后，启动一个后台线程（看门狗），定期检查锁的剩余过期时间。

• 当锁的剩余时间不足时，自动延长锁的过期时间，确保业务在执行期间锁不会被释放。

• 如果客户端宕机，看门狗线程会终止，锁会在过期时间后自动释放，避免死锁。

2. 看门狗的典型实现

以 Java 客户端 Redisson 为例，看门狗的实现流程如下：

1. 获取锁 ：客户端通过 lock() 方法获取锁，同时启动看门狗线程。

2. 定期续期：看门狗默认每 10 秒检查一次锁的状态，若锁仍被持有，则将过期时间延长至 30 秒（可配置）。

3. 释放锁 ：业务执行完成后，客户端调用 unlock() 方法释放锁，同时终止看门狗线程。

// Redisson 看门狗示例
RLock lock = redisson.getLock("lock:order");
// 获取锁，默认过期时间 30 秒，看门狗自动续期
lock.lock();
try {
    // 执行业务逻辑（可能超过 30 秒）
} finally {
    lock.unlock();
}

3. 看门狗的适用场景

• 长耗时业务：如批量数据处理、文件上传等，业务执行时间不确定的场景。

• 高并发场景：避免锁提前释放导致的并发冲突，保证数据一致性。

• 分布式事务：在分布式事务中，确保锁在事务提交前不会被释放。

---

三、Redlock：分布式锁的高可用终极方案

单节点 Redis 分布式锁存在单点故障风险：如果 Redis 节点宕机，锁服务会中断。Redlock 算法通过多个独立的 Redis 节点实现分布式锁，提升锁的可靠性。

使用redis作为分布式锁，redis本身有没有可能挂了呢?? 太可能了!!

要想保证"高可用"就需要通过这样一系列的"预案演习"

进行加锁，就是把key设置到主节点上

如果主节点挂了，有哨兵自动的把从节点

升级成主节点，进一步的保证刚才的锁仍然可用!!

主节点和从节点之间的数据同步，是存在延时的!!!

可能主节点收到了set请求，还没来得及同步给从节点呢，主节点就先挂了.

即使从节点升级成了主节点，但是，刚才的加锁对应的数据，也是不存在的!!

作为分布式系统，就需要随时考虑某个节点挂了的情况.需要保证某个节点挂不会影响到大局~~

1. Redlock 的核心原理

Redlock 算法基于**Quorum（法定人数）**机制，核心步骤如下：

1. 节点准备：部署 N 个独立的 Redis 节点（建议 N=5，奇数个节点），节点之间无主从关系，完全独立。

2. 获取锁 ：客户端向所有 N 个节点发送 SET key value EX px NX 命令，尝试获取锁。

3. 锁有效性判断：客户端收集成功获取锁的节点数量，若成功数量超过半数（如 N=5 时≥3），则认为锁获取成功。

4. 锁释放 ：客户端向所有 N 个节点发送 DEL key 命令，释放锁。

此处加锁，就是按照一定的顺序，针对这些组redis都进行加锁操作!!

如果某个节点挂了(某个节点加不上锁，没关系，可能是redis挂了)

继续给下一个节点加锁即可.

如果写入key成功的节点个数超过总数的一半.

就视为加锁成功.

同理，进行解锁的时候，也就会把上述节点都设置一遍解锁.

2. Redlock 的优势与局限性

优势

• 高可用：只要超过半数的节点正常运行，锁服务就能正常工作，避免单点故障。

• 强一致性：通过多节点验证，减少锁冲突的概率，保证数据一致性。

局限性

• 性能开销：需要向多个节点发送请求，锁的获取和释放延迟较高。

• 时钟同步依赖：节点之间的时钟必须保持同步，否则可能导致锁过期时间不一致。

• 网络分区风险：网络分区可能导致客户端与部分节点失联，影响锁的有效性判断。

3. Redlock 的实践建议

• 节点部署：将 N 个节点部署在不同的物理机或可用区，避免硬件故障或网络分区影响多个节点。

• 时钟同步：使用 NTP 协议确保节点时钟同步，误差控制在毫秒级。

• 超时设置：合理设置锁的过期时间和请求超时时间，避免网络延迟导致的误判。

---

四、生产环境的锁架构选型

1. 场景化选型指南

|-----------|---------------------|--------------|------------|
| 场景 | 推荐方案 | 优势 | 劣势 |
| 低并发、对性能敏感 | 单节点 Redis 分布式锁 | 性能高、实现简单 | 存在单点故障风险 |
| 高并发、长耗时业务 | 单节点 Redis + 看门狗 | 自动续期、避免锁提前释放 | 依赖客户端实现 |
| 金融级高可用场景 | Redlock | 多节点保障、可靠性高 | 性能开销大、实现复杂 |
| 强一致性要求场景 | ZooKeeper/Etcd 分布式锁 | 一致性强、支持事务 | 性能低于 Redis |

2. 锁架构的演进路径

随着业务规模的增长，锁架构通常会经历以下演进阶段：

1. 单节点 Redis 锁：初期业务量小，追求快速上线和性能。

2. 单节点 Redis + 看门狗：业务增长，出现长耗时业务，需要自动续期。

3. Redis Cluster 锁：业务规模扩大，需要高可用的 Redis 集群支撑。

4. Redlock 或第三方锁服务：金融级业务，对锁的可靠性要求极高。

---

五、总结

Redis 分布式锁的演进从单节点到多节点，从手动过期到自动续期，核心目标始终是提升锁的可靠性和可用性。看门狗解决了锁过期时间失控的问题，Redlock 则通过多节点机制避免了单点故障风险。在生产环境中，需要根据业务场景选择合适的锁方案，结合监控工具和运维经验，才能保证锁服务的稳定运行。随着云原生技术的发展，分布式锁与服务网格、混沌工程的结合将进一步提升系统的弹性和可观测性，为大规模业务提供更强的支撑。

---