Redlock 是 Redis 作者 antirez 在 2016 年提出的一种分布式锁算法，旨在解决单节点 Redis 锁在故障切换场景下可能丢失锁的问题。然而，这个算法自诞生以来就争议不断，尤其是 Martin Kleppmann 与 antirez 之间的著名论战，让 Redlock 的安全性成为分布式系统领域最受关注的话题之一。如果你在面试中被问到这个问题，面试官考察的往往不是“安全还是不安全”这个二元结论，而是你对分布式锁本质、异步系统模型以及一致性与可用性权衡的理解深度。
为什么需要 Redlock
在理解 Redlock 之前，先回顾单节点 Redis 分布式锁的问题。通常我们用 SET key value NX PX 30000 来实现加锁，逻辑简单且性能极高。但它存在一个致命缺陷：如果 Redis 是主从架构，客户端 A 在主节点加锁成功，主节点还没来得及把数据同步到从节点就宕机了，哨兵机制将从节点提升为新主节点。此时客户端 B 向新主节点请求同一把锁，会成功获取，于是 A 和 B 同时持有锁，互斥性被破坏。
Redlock 的思路是：不依赖单个 Redis 节点，而是向 N 个（通常为 5 个）相互独立的 Redis 主节点依次请求加锁。客户端只有在超过半数节点（即 N/2+1）上成功加锁，并且总耗时小于锁的过期时间时，才认为加锁成功。这样即使少数节点崩溃或网络分区，只要多数节点存活，锁的安全性就能得到保障。释放锁时，需要向所有节点发送释放请求。
从直觉上看，这个设计确实比单节点锁更健壮。但问题在于，“更健壮”是否等于“安全”？
Martin Kleppmann 的质疑
Martin Kleppmann 是《Designing Data-Intensive Applications》的作者，他对 Redlock 提出了系统性的批评，核心论点可以归纳为以下几点。
第一，Redlock 依赖时钟假设，而时钟不可靠。 Redlock 的安全性证明建立在一个前提上：各个 Redis 节点的时钟漂移是有界的，且不同节点的时间流逝速率大致相同。但现实中，NTP 校时可能导致时钟跳变，虚拟机暂停、GC 停顿都会让本地时钟与真实时间产生偏差。Kleppmann 举了一个具体场景：客户端 A 获取锁后发生长时间的 GC 停顿，锁在多个节点上因过期而被释放；A 恢复后以为自己仍持有锁，继续操作共享资源，而此时客户端 B 已经获取了同一把锁。这种情况下，Redlock 并不能提供真正的互斥保证。
第二，Redlock 无法提供 fencing token。 这是 Kleppmann 认为最根本的问题。分布式锁的真正目的不是“防止两个客户端同时进入临界区”，而是“防止旧的客户端在锁失效后继续对共享资源造成破坏”。正确的做法是引入单调递增的 fencing token：每次加锁时返回一个递增的版本号，共享资源（如存储系统）在写入时检查该版本号，拒绝旧版本号的写入。这样即使锁已经过期、旧客户端仍在操作，存储层也能兜底。而 Redlock 的 API 只返回一个布尔值表示是否加锁成功，不提供任何单调递增的令牌，因此无法与下游资源配合实现真正的安全。
第三，Redlock 的性能与复杂度不匹配。 为了获得比单节点锁更强的安全性，Redlock 需要部署 5 个独立 Redis 实例，加锁需要多次网络往返，延迟显著增加。但在 Kleppmann 看来，它换来的安全性提升并不足以弥补这种复杂度——因为它依然没有解决时钟依赖和 fencing 这两个根本问题。
antirez 的回应
antirez 对上述批评进行了逐条反驳。他认为 Kleppmann 混淆了“效率型锁”和“正确性型锁”的适用场景。对于大多数需要分布式锁的场景，锁的作用是提升效率、避免重复劳动，偶尔的锁冲突并不会导致数据损坏；真正需要绝对正确性的场景，本来就应该在存储层做 fencing 校验，而不是把责任全部推给锁。
关于时钟问题，antirez 指出 Redlock 并不要求绝对精确的时钟，只要求时钟漂移在一个合理的范围内，并且算法中已经通过“加锁总耗时必须小于锁有效期”这一条件来补偿时钟误差。只要时钟漂移不是恶意的或极端的，Redlock 在实践中是可靠的。他还强调，如果攻击者能够随意操纵系统时钟，那么任何分布式协调系统都会失效，这不应成为单独针对 Redlock 的指责。
关于 fencing token，antirez 承认这是一个有用的模式，但他认为这属于存储层的职责，而不是锁服务的职责。Redlock 的定位是提供一个“尽力而为”的互斥保证，使用者应当根据自己的场景决定是否需要额外的 fencing 机制。
到底安不安全：分场景看
经过这场论战，社区逐渐形成了一个相对共识：Redlock 的安全性取决于你对“安全”的定义和使用场景。
如果你的场景是“效率型锁”——比如避免多个 worker 重复执行同一个定时任务，偶尔的重复执行只是浪费一点资源，不会造成数据不一致——那么 Redlock 完全够用，甚至单节点 Redis 锁也够用。
如果你的场景是“正确性型锁”——比如保证同一时刻只有一个进程能修改某条关键数据，任何一次互斥失败都会导致数据损坏或资金损失——那么 Redlock 不足以提供你需要的保证。此时正确的做法是：使用带 fencing token 的锁机制，并在存储层做版本校验；或者直接使用 ZooKeeper、etcd 这类基于共识算法（ZAB、Raft）的协调服务，它们提供的锁具有更强的理论保证。
还有一点值得注意：Redis 官方文档在 Redlock 页面也明确写道，如果你需要强一致性的锁，建议考虑其他方案。这某种程度上也反映了 Redlock 的定位边界。
面试中如何回答
如果面试官问你“Redlock 到底安不安全”，一个加分的回答结构是：
- 先说明 Redlock 的设计目标和基本原理（多数派加锁、时钟补偿）。
- 指出它的核心争议：依赖时钟假设、缺乏 fencing token、性能与复杂度权衡。
- 区分场景给出结论：效率型场景可用，正确性型场景不够，需要 fencing 或换用共识系统。
- 最后点出分布式锁的本质——锁本身无法解决所有问题，下游资源的幂等性和版本校验才是最后一道防线。
这样的回答既展示了你对算法细节的掌握，也体现了你对分布式系统本质问题的思考，远比简单回答“安全”或“不安全”更有说服力。
总结
Redlock 不是一个“错误”的算法，但它也不是分布式锁的银弹。它的安全性在理论上存在被质疑的边界，在实践中则高度依赖具体场景。理解 Redlock 的争议，本质上是在理解分布式系统中的一个核心事实：在异步网络中，没有完美的锁，只有适合特定场景的权衡。作为工程师，重要的不是记住“Redlock 安不安全”的结论，而是学会根据业务对正确性的要求，选择合适的协调机制，并在架构中为最坏情况留下兜底。
未经允许不得转载：任鹏个人博客 » Redis 的 Redlock 算法到底安不安全
