redis中红锁的使用小结_Redis

好的，我们来详细、深入地探讨一下 redis 红锁（redlock）。

redlock 是 redis 官方提出的一种用于在分布式环境下实现强一致性分布式锁的算法。它的提出，是为了解决在 redis 主从复制或哨兵模式下，使用单实例 redis 锁可能遇到的锁失效问题。

1. 为什么需要红锁？—— 问题的起源

在深入了解红锁之前，必须先理解它要解决什么问题。

假设我们使用单个 redis 实例实现分布式锁（通常用 set key random_value nx px 30000命令）：

客户端 a 在 master 节点上成功获取锁。
在 master 将锁数据同步到 slave 节点之前，master 宕机了。
哨兵机制触发，一个 slave 节点升级为新的 master。
此时，这个新的 master 节点上并没有客户端 a 持有的锁。
客户端 b 向新的 master 节点申请锁，成功获取。此时，客户端 a 和客户端 b 同时认为自己持有了锁，导致锁的安全性被破坏。

核心问题：在异步复制的场景下，锁数据在写入主节点后，到同步到从节点之间存在一个时间窗口。在这个窗口内主节点故障，会导致锁数据的丢失。

红锁的目标就是消除对单个 redis 实例的依赖，从而避免这类问题。

2. 红锁算法（redlock algorithm）的核心思想

红锁的基本思想非常直观：“不要把所有鸡蛋放在一个篮子里”。

它要求客户端向一个独立的、无主从关系的 redis 实例集群中的多数（n/2+1）个节点依次申请锁，只有当从多数节点都获取锁成功，并且总耗时小于锁的有效时间，才算最终加锁成功。

算法前提条件

部署多个 redis master 节点：这些节点必须是完全独立的，相互之间没有数据同步关系（例如，不是同一个哨兵或集群下的节点）。建议至少 5 个节点，这样可以容忍其中 2 个节点故障，从而保证系统的可用性。

算法步骤详解

假设我们有 n 个 redis 节点（例如 n=5）。

第一步：获取当前时间

客户端在开始获取锁之前，先记录一个开始时间 start_time。

第二步：依次向所有 n 个节点申请锁

客户端使用相同的键名和随机值，依次向 5 个 redis 实例发送锁申请命令（set lock_name my_random_value nx px 30000）。

为了减少因为某个节点故障而造成的长时间等待，可以为每个节点的请求设置一个远小于锁超时时间的网络超时时间（例如，锁超时 10 秒，网络超时 50-100 毫秒）。如果一个节点没有响应，应尽快尝试下一个节点。

第三步：计算获取锁的总耗时

当客户端从所有节点都收到响应（无论是成功还是失败）后，记录结束时间 end_time。计算总耗时：total_time = end_time - start_time。

第四步：检查锁是否获取成功

客户端需要同时满足以下两个条件，才认为锁获取成功：

多数派原则：客户端从至少 n/2 + 1个节点（对于 5 个节点，就是 3 个）上成功获取了锁。
有效性检查：获取锁的总耗时 total_time必须小于锁的自动释放时间（ttl）。例如，锁的 ttl 是 10 秒，而 total_time是 2 秒，那么是有效的。如果 total_time是 12 秒，则无效。

为什么需要条件 2？ 这是为了防止客户端在获取锁的过程中耗时太久，导致最早申请到的那些锁在客户端开始执行关键代码前就已经过期了。

如果锁获取失败：客户端必须向所有 redis 节点发起释放锁的请求（即执行 lua 脚本，检查随机值并删除锁）。即使某些节点返回失败（比如它本来就没加锁成功），也需要尝试释放，以确保清理现场。

3. 释放锁

释放锁的过程相对简单：客户端需要向第一步中尝试获取锁的所有 n 个节点发送释放命令。

释放命令必须使用 lua 脚本保证原子性：

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

这样做是为了确保只有锁的持有者才能释放锁，避免误删其他客户端创建的锁。

4. 红锁的争议与局限性（非常重要！）

redlock 自提出以来，就在分布式系统领域引发了激烈的讨论，特别是来自 martin kleppmann（《数据密集型应用系统设计》作者）的挑战。理解这些争议点对于正确使用红锁至关重要。

主要争议点：

对系统时钟（时钟跳跃）的敏感性

场景：假设客户端 1 持有锁。某个 redis 节点因为系统时钟被调整（例如通过 ntp 同步或人为修改），导致其上的锁提前过期。
问题：客户端 2 向这个节点申请锁，可能成功。如果客户端 2 又从其他节点成功获取了足够多的锁，那么红锁算法就会认为客户端 2 获得了锁，从而导致两个客户端同时进入临界区。
红锁的辩护：redis 作者 antirez 认为，应该通过合理的运维手段禁止这种跳跃式的时钟调整，而使用“慢速收敛”的时钟同步方式。

gc pause（垃圾回收暂停）或进程暂停带来的安全性问题

场景（martin 描述的著名例子）：

客户端 1 成功获得红锁，并开始执行关键代码。
在执行过程中，发生了长时间的 gc pause（例如 30 秒），导致客户端 1 的进程被“冻结”。
在此期间，客户端 1 持有的锁因为超时（ttl 到期）而被所有 redis 节点自动释放。
客户端 2 成功获得了红锁，并开始执行关键代码。
客户端 1 从 gc pause 中恢复，继续执行关键代码。此时，客户端 1 和客户端 2 再次同时进入了临界区。

问题的本质：红锁（以及任何基于超时的锁）无法区分“客户端业务逻辑执行缓慢”和“客户端进程已崩溃”这两种情况。它依赖于超时机制，而超时机制在存在长时间进程暂停时就会失效。

解决方案的讨论：martin 提出需要使用一种能够在共享存储中留下“围栏令牌”（fencing token） 的锁服务。客户端在写数据时，需要检查一个单调递增的令牌，以确保自己的操作是在最新的锁状态下进行的。这实际上要求共享资源层（如 zookeeper、etcd）提供额外的协调能力。

5. 红锁的使用建议

考虑到上述争议，你应该在以下情况下考虑使用红锁：

对一致性要求极高：你确实需要一把强一致的锁，并且可以接受红锁带来的性能下降（因为需要与多个节点通信）。
可以控制运维环境：你能够确保 redis 节点所在的机器不会发生剧烈的时钟漂移。
理解其局限性：你清楚地知道，在极端情况下（如长时间的进程暂停），红锁仍然无法提供 100% 的安全保证。对于大多数业务场景，这种极端情况的发生概率和其带来的风险是可以接受的。

替代方案：

对于高可用要求不极端的场景：使用 redis 主从+哨兵模式，并接受在主从切换的极小时间窗口内可能出现的锁失效问题。很多业务场景下，这种风险是可接受的。
对于必须强一致的场景：考虑使用专门为分布式协调而设计的系统，如 zookeeper 或 etcd。这些系统使用了共识算法（如 zab、raft），它们本身就是为了在分布式环境下提供强一致性和容错性而设计的，实现分布式锁是它们的原生强项，通常能提供比红锁更可靠的安全保证。

总结

特性	描述
目标	在分布式 redis 环境下实现一个更安全、强一致的分布式锁。
核心思想	向多个独立的 redis 主节点申请锁，遵循“多数派”原则。
优点	解决了单点 redis 和主从架构下因异步复制导致的锁失效问题。
缺点/争议	1. 对系统时钟漂移敏感。 2. 无法完全解决 gc pause 等进程暂停问题。 3. 部署更复杂，性能低于单节点锁。
适用场景	对锁的一致性要求非常高，且愿意为了一致性牺牲部分性能和增加复杂度的场景。
替代方案	redis 主从锁（可接受风险）、zookeeper、etcd。