在讨论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更稳定、更快速，也更节省资源。
