快速搞懂红锁（redLock）和联锁(multiLock)

Redis 的主从异步复制机制确实给分布式锁带来了一个经典的挑战：在主节点获取锁成功后，如果锁数据还未同步到从节点时主节点发生故障，从节点晋升后可能丢失锁信息，导致多个客户端同时持有锁，破坏互斥性

。为了应对这一问题，Redisson 提供了 RedLock（红锁）和 MultiLock（联锁）两种机制。它们在设计目标和适用场景上有所不同。

下面是一个表格，帮助你快速了解两者的核心区别：

特性	RedLock (红锁)	MultiLock (联锁)
​​设计目标​​	​​解决主从异步复制导致的锁丢失问题​​，提供更高的一致性保证	​​同时锁定多个资源​​，保证对多个资源的操作具备原子性（要么全锁，要么全不锁）
​​底层节点要求​​	需要多个（推荐至少5个）​​完全独立的 Redis 主节点​​，且无副本关系	所有锁通常在​​同一个 Redis 集群或实例​​内
​​成功条件​​	必须在超过半数的独立节点上成功获取锁 (N/2 + 1)	​​所有​​指定的锁都必须成功获取
​​容错性​​	允许部分节点故障（最多 (N-1)/2 个）	任一锁对应的 Redis 节点故障则整体获取失败
​​典型应用场景​​	对锁的​​可靠性要求极高​​的场景，如金融交易	需要​​原子性操作多个资源​​的场景，如分布式事务中同时锁定订单、库存和优惠券
​​性能开销​​	较高（需与多个独立节点通信并等待多数响应）	相对较低（但锁越多，耗时越长）
​​是否要求时钟同步​​	是，节点间时钟漂移可能影响锁有效性	否

🔧 工作原理详解

​​RedLock (红锁)​​

RedLock 算法通过​​在多个独立的 Redis 主节点上获取锁​​，并要求​​多数节点（N/2 + 1）成功​​来解决主从复制延迟问题

。其核心流程如下：

1. 1.

   ​​获取当前时间​​：记录开始加锁的时间点 T1。

2. 2.

   ​​依次向所有节点加锁​​：使用相同的键和随机值，向每个独立节点发送加锁命令（如 SET key random_value NX PX），并设置一个较短的超时时间

   。
3. 3.

   ​​计算总耗时​​：获取锁完成后，计算总耗时 T2 = 当前时间 - T1。

4. 4.

   ​​判断成功条件​​：必须同时满足：

   • •

     成功获取锁的节点数 ≥ (N/2 + 1)

     。
   • •

     总耗时 T2 ​​小于​​ 锁的有效时间 (TTL)

     。这是为了确保锁在获取成功后仍有合理的有效时间。
5. 5.

   ​​解锁​​：向所有节点发送解锁请求（通常通过 Lua 脚本确保仅当值匹配时才删除）

   。

​​MultiLock (联锁)​​

MultiLock 的目标是​​将多个 RLock 对象关联为一个逻辑上的“大锁”​​，确保这些资源上的操作具备原子性

。其核心流程如下：

1. 1.

   ​​创建多个锁对象​​：为每个需要锁定的资源创建一个 RLock对象。

2. 2.

   ​​组合成联锁​​：将这些 RLock对象组合成一个 RedissonMultiLock。

3. 3.

   ​​尝试加锁​​：按顺序尝试获取所有锁

   。
   • •

     若​​所有锁​​都成功获取，则联锁获取成功。

   • •

     若​​任何一个锁获取失败​​（如超时或异常），则​​立即释放所有已经获取的锁​​，然后根据策略（如等待重试）进行后续操作

     。
4. 4.

   ​​执行业务逻辑​​。

5. 5.

   ​​解锁​​：释放联锁时，会按顺序释放所有组成该联锁的单个锁

   。

⚠️ 注意事项与争议

• •

  ​​RedLock 的争议​​：RedLock 算法在分布式系统领域存在一些争议。其主要焦点在于它对​​系统时钟的强依赖​​。若节点间发生严重的时钟漂移，可能导致锁异常失效

  。Martin Kleppmann 曾对此提出质疑，而 Redis 作者 Antirez 进行了反驳。此外，在极端情况下（如客户端发生长时间的 GC 停顿），也可能导致锁的安全性被破坏。​​因此，是否采用 RedLock 需仔细评估你的业务场景对一致性的容忍度、基础设施状况（节点独立性和时钟同步）和运维成本。​​
• •

  ​​MultiLock 的局限​​：MultiLock 本身​​并不能直接解决主从一致性问题​​

  。如果其管理的所有 RLock都在同一个 Redis 主从架构中，那么该主节点宕机同样会导致锁丢失风险。它更侧重于保证多个资源锁定的原子性。
• •

  ​​性能考量​​：RedLock 由于需要与多个独立节点通信，其延迟和性能开销通常高于单节点锁或 MultiLock

  。MultiLock 的性能则取决于需要同时获取的锁的数量和网络状况。
• •

  ​​错误处理​​：对于 RedLock，如果加锁失败（未获多数同意或超时），必须​​清理所有节点上可能已设置的锁​​，以避免留下垃圾数据

  。

🎯 如何选择？

• •

  ​​追求更高一致性，能容忍一定性能损耗​​：如果你的业务场景对分布式锁的​​可靠性要求极高​​（例如金融交易关键步骤），且你能够部署和维护多个​​独立的 Redis 主节点​​，并确保节点间时钟同步，可以考虑使用 ​​RedLock​​

  。
• •

  ​​需要原子性操作多个资源​​：如果你的业务逻辑需要​​同时锁定多个关联资源​​（例如下单时同时锁订单、库存和优惠券），以确保这些操作要么全部成功要么全部回滚，那么应该使用 ​​MultiLock​​

  。
• •

  ​​注意​​：在一些讨论和实践中（例如 Redisson 的某些实现），RedLock 在底层是通过继承或封装 MultiLock 来实现的，但其成功判断条件（多数派）和部署要求（独立节点）是不同的

  。也有资料指出 Redisson 中的 RedissonRedLock已被标记为弃用（deprecated），使用时需查阅当前版本的官方文档。

💎 总结

Redisson 的 RedLock 和 MultiLock 是应对不同分布式锁需求的工具。

• •

  ​​RedLock​​ 旨在通过​​多数派机制​​和​​独立节点部署​​来克服​​主从复制延迟​​导致锁失效的问题，提供更高的一致性保证，但代价是复杂性和性能开销

  。
• •

  ​​MultiLock​​ 则专注于解决​​多个资源原子性加锁​​的问题，确保业务操作中涉及的所有资源都能被同时锁定或释放，但它本身不直接提供抵御主从故障的能力

  。

选择时，请务必根据你的​​业务需求​​、​​基础设施状况​​和对​​一致性级别的要求​​进行审慎评估。对于绝大多数应用场景，使用单节点锁并保证业务幂等性可能是更简单实用的选择；若确有强一致性需求，或许值得探索 ZooKeeper 或 etcd 等 CP 系统的分布式锁方案。