从最简单的 SETNX 到 Redisson 的看门狗机制，再到 RedLock 算法，分布式锁的演进中包含了多少并发安全的设计思想。

一、分布式锁的核心要求

  • 1.1 互斥性——同一时刻只有一个客户端持有锁
  • 1.2 防死锁——锁的持有者崩溃后锁能被释放
  • 1.3 解铃还须系铃人——谁加的锁只能谁来解
  • 1.4 可重入性——同一客户端可重复获取

二、V1：SETNX + EXPIRE 的原子性问题

  • 2.1 SETNX key value + EXPIRE key ttl——两步不是原子的
  • 2.2 在 SETNX 和 EXPIRE 之间崩溃 → 死锁
  • 2.3 Redis 2.6.12 之前的局限

三、V2：SET key value NX EX ttl——原子性解决

  • 3.1 SET lock_key unique_value NX EX 30 原子操作
  • 3.2 unique_value 的作用——UUID 确保解铃还须系铃人
  • 3.3 Lua 脚本释放锁——先判断 value 再 DEL

四、V3：锁续期——看门狗机制

  • 4.1 业务执行时间超过锁的过期时间怎么办
  • 4.2 Redisson 的 Watch Dog——自动续期
  • 4.3 看门狗源码分析——scheduleExpirationRenewal()
  • 4.4 默认续期间隔——锁过期时间的 1/3

五、V4：RedLock 算法

  • 5.1 主从架构下的锁安全性问题——主节点宕机，锁丢失
  • 5.2 RedLock 的思路——向 N 个独立 Redis 实例加锁，过半成功才算成功
  • 5.3 RedLock 的争议——Martin Kleppmann 的质疑
  • 5.4 Redisson 的 RedissonRedLock 使用

六、生产环境实践建议

  • 6.1 单实例 Redis 分布式锁——适合大部分场景
  • 6.2 Redis Cluster 环境——RedLock 的必要性
  • 6.3 ZooKeeper 分布式锁的对比——强一致性 vs 高性能
  • 6.4 分布式锁的监控——锁持有时间、等待队列长度

七、总结

  • 技术演进路线图
  • 在你的场景下应该选哪个版本