Redis分布式锁的三种实现方案与可靠性陷阱

Redis分布式锁的三种实现方案与可靠性陷阱

在分布式系统中，跨进程互斥访问共享资源是绕不开的工程问题。无论是秒杀扣库存、订单幂等处理，还是定时任务的单实例执行，都需要一把可靠的分布式锁。Redis 凭借极高的性能和成熟的生态，成为分布式锁最主流的落地选择。但很多团队只做到了「能加锁」，却忽略了锁的可靠性边界，最终在流量高峰时出现超卖、重复执行等严重事故。本文结合生产实践，系统梳理三种实现方案的差异与常见陷阱。

一、SETNX 方案的先天缺陷

最原始的写法是 SETNX key value 加 EXPIRE key seconds 两步操作，看似简单，实际上埋了两个致命隐患：

• 非原子性：两条命令之间存在时间窗口，若进程在 SETNX 成功、EXPIRE 未执行时崩溃，这把锁将永不过期，形成死锁，后续所有请求全部阻塞。
• 误删他人锁：线程 A 持锁期间因 GC 停顿或网络抖动导致业务超时，锁自动过期；线程 B 拿到锁继续执行，此时 A 恢复并执行 DEL，直接把 B 的锁删掉，互斥彻底失效。

正确的做法是使用单条原子命令 SET key value NX PX 30000，将「不存在才设置」与「设置过期时间」合并为一次原子操作，从根上消除时间窗口。同时 value 必须写入全局唯一标识（如 UUID + 线程 ID），解锁时用 Lua 脚本先比对 value 再删除，保证只释放自己持有的锁。

二、Redisson 看门狗机制的工程价值

业务执行时间往往不可预测，预设的过期时间要么太短导致锁提前释放，要么太长导致异常时长时间阻塞。Redisson 的看门狗（Watch Dog）机制解决了这个矛盾：加锁成功后启动一个后台定时任务，默认每 10 秒检测一次，若当前线程仍持有锁则将过期时间重置为 30 秒，直到业务执行完毕主动释放。

这一设计让锁的生命周期与业务执行周期动态绑定，既避免了「业务没执行完锁就过期」，也避免了「进程崩溃后锁长期不释放」。需要注意的是，看门狗依赖客户端进程存活，若机器宕机，锁会在最长 30 秒后自然过期，这属于可接受的故障收敛时间。

三、RedLock 的争议与适用边界

单节点 Redis 存在单点故障风险：主节点写入锁后尚未同步到从节点即宕机，哨兵切换后新主节点上并无这把锁，另一个客户端可重复加锁成功。Redis 作者提出的 RedLock 算法通过向 N 个独立 Redis 实例（通常为 5 个）依次加锁，当且仅当在超过半数节点加锁成功且总耗时小于锁有效期时才认为加锁成功，以此降低单点失效概率。

但 RedLock 的争议从未停止：它依赖各节点时钟不发生大幅漂移，且在网络分区场景下仍无法严格保证互斥性。工程上的结论是：对一致性要求极高的金融级场景，应优先选择 ZooKeeper 或 etcd 这类基于共识算法（Paxos/Raft）的锁服务；Redis 锁更适合高并发、允许极小概率重入的互联网业务场景。

四、生产环境可靠性准则

1. 锁粒度尽量小：按业务主键分片加锁（如 order:lock:10086），避免全局锁造成吞吐骤降。
2. 加锁必须设置超时：无论用哪种方案，都必须给「获取锁」动作设置最大等待时间，防止请求线程无限阻塞耗尽线程池。
3. 业务侧做幂等兜底：分布式锁不是万能的，数据库唯一索引、状态机校验等幂等设计才是最后一道防线。
4. 监控锁等待与超时率：将锁获取耗时、失败率纳入监控大盘，一旦 P99 突增即为潜在死锁或热点 Key 信号。

总结来说，分布式锁的本质是在「性能」与「一致性」之间做取舍。理解每种方案的失效边界，比背下某段代码更重要。