【深入浅出】RedLock设计教程，一文讲透核心原理

RedLock(红锁)是 Redis 官方提出的一种分布式锁算法，旨在解决在 Redis 集群或主从架构下，因单点故障或异步复制导致锁丢失的安全问题。

以下是一份系统化的 RedLock 设计教程，涵盖背景、核心原理、算法流程、代码实现及争议点。

 1. 为什么需要 RedLock?(背景)

在分布式系统中，我们常用 Redis 实现分布式锁。最简单的做法是单节点执行 SET lock_key unique_value NX PX 30000。但这个方案存在两个致命问题：

单点故障：如果唯一的 Redis 节点宕机，整个加锁服务不可用。

主从异步复制导致锁丢失：即使部署了主从 + 哨兵，由于复制是异步的，客户端 A 在主节点加锁成功后，主节点在同步锁数据到从节点之前宕机，从节点被提升为新主节点。此时新主节点没有锁记录，客户端 B 可以再次加锁成功，导致两个客户端同时持有锁，造成并发安全问题。

为了解决主从架构下的锁丢失问题，Redis 作者 Salvatore Sanfilippo(Antirez)提出了 Redlock 算法。

 2. RedLock 的核心思想

RedLock 不使用主从复制，而是部署 N 个独立的 Redis Master 节点(通常 N=5)。客户端加锁时，需要向所有节点发送加锁请求，只有当超过半数节点(N/2+1)返回成功，且总耗时小于锁有效期时，才认为加锁成功。

多数派原则：任意两个成功的加锁请求，它们的节点集合必然有交集，交集节点会拒绝第二个请求，从而保证互斥。

 3. RedLock 的加锁流程(详细步骤)

假设有 5 个独立 Redis 节点(A、B、C、D、E)，锁超时时间 TTL = 10秒。

获取当前时间：记录开始加锁的时间戳 start_ms(毫秒级)。

依次向所有节点请求锁：

对每个节点执行：SET my_lock random_value NX PX 10000

my_lock：锁的名称(标识共享资源)。

random_value：全局唯一随机值(如 UUID)，用于安全释放锁。

NX：只有键不存在时才设置(保证互斥)。

PX 10000：锁自动过期时间 10 秒。

注意：每个请求设置极短的网络超时(例如 5~50 毫秒)，避免某个故障节点长时间阻塞。

计算加锁总耗时：elapsed = now_ms - start_ms。

判断加锁是否成功：需同时满足两个条件：

成功节点数 ≥ 3(5 个节点中的多数派)。

elapsed < TTL(加锁过程没有超过锁的有效期)。

如果成功，则锁的真正有效时间 = TTL - elapsed。

失败处理：如果加锁失败(成功节点数不足或总耗时超时)，则立即向所有节点发送释放锁请求(执行 Lua 脚本，验证 random_value 后删除)。

 4. 释放锁的流程

无论加锁成功与否，释放时都需要向所有 5 个节点发送释放脚本。必须使用 Lua 脚本保证“获取值”和“删除”操作的原子性，防止误删别人的锁：

lua

编辑

1if redis.call("get", KEYS[1]) == ARGV[1] then

2 return redis.call("del", KEYS[1])

3else

4 return 0

5end

 5. 代码实现示例(Java + Redisson)

在实际工程中，很少手写 RedLock 的底层逻辑，通常使用成熟的客户端库，如 Java 的 Redisson。

java

编辑

1// 1. 配置多个独立的 Redis 节点

2Config config = new Config();

3config.useReplicatedServers()

4 .addNodeAddress("redis://127.0.0.1:6379")

5 .addNodeAddress("redis://127.0.0.1:6380")

6 // ... 添加更多节点

7;

8RedissonClient redisson = Redisson.create(config);

9

10// 2. 获取红锁对象

11RLock lock1 = redisson.getLock("lock1");

12RLock lock2 = redisson.getLock("lock2");

13RLock lock3 = redisson.getLock("lock3");

14

15// 3. 创建 RedLock 实例

16RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3);

17

18// 4. 尝试加锁

19// 等待 100 秒，锁持有时间 10 秒

20if (redLock.tryLock(100, 10, TimeUnit.SECONDS)) {

21 try {

22 System.out.println("RedLock 获取成功，执行业务...");

23 // 业务逻辑

24 } finally {

25 redLock.unlock();

26 }

27}

 6. RedLock 的争议与缺点

尽管 RedLock 提升了安全性，但它并非完美，主要争议来自分布式系统专家 Martin Kleppmann：

时钟跳变问题：RedLock 强依赖多个节点的时钟保持同步。如果某个 Redis 节点的系统时钟发生跳变(例如 NTP 同步导致时间向前跳跃)，可能导致锁提前过期，破坏互斥性。

GC 停顿问题：如果客户端在获取锁后、释放锁前发生了长时间的 GC 停顿，可能导致锁在客户端不知情的情况下过期，而其他客户端获取了锁。

性能与复杂度：需要维护多个独立的 Redis 实例，部署成本高;加锁和释放锁需要与所有节点通信，网络延迟较高。

行业现状：由于上述争议，Redisson 在 3.12.5 版本后弃用了 RedLock 的实现，转而使用 WAIT 命令进行同步复制来保证一定的安全性。如果你对并发安全性零容忍，建议结合数据库唯一索引等兜底方案。