Redlock分布式锁解决击穿死锁的高可用方案

在讨论Redlock时，一个常见的误区是将其视为解决所有分布式锁问题的万能方案。实际上，Redlock的核心价值在于降低单点故障导致的锁丢失风险，它并不能直接解决缓存击穿问题，也无法完全杜绝死锁。要真正抵御缓存击穿和死锁，必须依赖业务层的精细设计、合理的超时控制，以及看门狗机制等兜底策略。

Redlock与缓存击穿并无直接关联

首先需要明确概念：缓存击穿是指某个热点key在失效的瞬间，大量并发请求绕过缓存，直接穿透到数据库。而Redlock是一种分布式互斥锁工具，其设计目标与缓存策略并无直接关联。它既不关心key是否过期，也不感知缓存是否命中。

一个常见的误解是：通过Redlock锁定“查询数据库并回填缓存”这段逻辑，就能防止缓存击穿。但实际情况并非如此，原因如下：

• SET key value NX PX 30000 这类加锁命令本身与缓存key的生命周期没有任何绑定关系。
• 如果业务逻辑中先删除缓存再加锁查询数据库，而删除缓存的操作并非原子性，那么Redlock无法阻止并发的回源请求。
• 当加锁失败时，Redlock仅抛出异常或返回false，至于是否阻塞重试、降级返回或触发熔断——它完全交由上层处理，内部并未内置任何重试或兜底逻辑。

死锁防护：Redlock降低风险，但无法根除

Redlock的锁自动过期依赖于每个节点上通过PX设定的TTL，但它并不能完全避免以下死锁场景：

• 客户端成功获取锁后，业务逻辑发生卡顿（例如死循环、Full GC、线程挂起），既未完成操作也未主动释放锁，只能等待TTL过期。
• 网络分区导致部分节点响应超时，客户端误判加锁失败，但某些节点实际上已经成功设置锁——此时若未执行unlockInner()清理，锁便会残留。
• 多个Redlock实例之间缺乏协调机制，A锁等待B锁，B锁等待A锁，形成环形依赖。Redlock既无法检测到这种情况，也不会自动打破死锁。

要有效防范死锁，需要依赖以下措施：

• 所有加锁调用必须明确指定waitTime和leaseTime（例如Redisson的tryLock(3, 30, TimeUnit.SECONDS)）。
• 业务代码中需设置清晰的超时边界，例如使用CompletableFuture.orTimeout()包裹核心流程。
• 监控redis.call('pttl', KEYS[1])的返回值，在续期之前确认锁仍然有效。

高可用部署：节点必须真正独立

许多开发者部署了5个Redis实例，却将它们全部运行在同一台物理机、同一个Docker Compose网络，甚至共享同一个配置中心——这完全违背了Redlock对节点独立性的要求。一旦宿主机宕机，5个节点将同时失效，多数派协议瞬间失去作用。

必须满足以下部署条件：

• 5个节点应分布在至少3个不同的可用区（AZ），且不能跨AZ共享存储或网络平面。
• 每个节点使用独立的redis.conf，禁用sla veof、replicaof，不开启AOF或仅使用appendfsync no。
• 客户端连接串不应写死IP，而应使用DNS或服务发现（如Nacos）动态感知节点健康状态。
• 加锁时的超时时间（例如commandTimeout）必须远小于锁的TTL，建议设置为≤ TTL/3，否则网络抖动容易导致多数派失败。

生产环境推荐：使用Redisson的RedissonRedLock，避免手动实现

手动实现Redlock极易遗漏关键细节：

• 加锁失败后未对已成功节点执行EVAL ... DEL清理，导致锁残留。
• 使用System.currentTimeMillis()计算耗时，忽略了时钟漂移问题——跨机房部署时NTP同步误差可能高达上百毫秒。
• 解锁时仅向“加锁成功的节点”发送请求，但Redlock规范要求向全部N个节点发送Lua脚本，无论之前是否加锁成功。

Redisson的RedissonRedLock已经封装了上述复杂逻辑：

RLock lock1 = redisson.getLock("lock1");
RLock lock2 = redisson.getLock("lock2");
RLock lock3 = redisson.getLock("lock3");
RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3);
// 同时向3个节点申请锁，至少2个成功才算获取锁
boolean isLocked = redLock.tryLock(10, 30, TimeUnit.SECONDS);

注意：tryLock(10, 30, ...)中的第一个参数10是最大等待时间，第二个参数30是leaseTime（看门狗初始TTL），并非过期时间——看门狗会自动续期，直到unlock()被调用或线程终止。

最容易被忽略的一点是：Redlock的可靠性提升伴随着性能代价。5节点Redlock的P99加锁延迟通常是单节点的3到5倍，且吞吐量明显下降。如果业务场景能够容忍短暂的不一致（例如库存超卖允许0.001%的误差），那么采用单节点配合Redisson看门狗以及本地限流，往往比Redlock更稳定、更快速，也更节省资源。