分布式锁
2022年春节，我们优惠券系统出现了超发事故。
开发同学用了 Redis 分布式锁，但锁的 TTL 设置的是 10 秒。优惠券核销需要 15 秒，锁过期后另一个请求进来，两边同时核销，导致优惠券超发了 2000 张。
事后复盘，这个锅不在 Redis 锁本身，而在于开发同学没理解锁的 TTL 和任务执行时间的匹配关系。
【架构权衡】 分布式锁的坑，多到可以写一本书。锁的过期时间、续期机制、原子性保证、可重入性、主从切换丢锁......每一个点都是面试官追问的对象。理解这些坑，才能真正用好分布式锁。
一、内容总览
本模块覆盖分布式锁的完整知识体系，从实现原理到工程实践：
1.1 Redis 分布式锁 🔴
1.2 ZooKeeper 分布式锁 🟡
1.3 etcd 分布式锁 🟢
1.4 数据库锁 🟡
1.5 锁的选型与对比 🟡
二、学习路径指引
第一阶段：Redis 锁从入门到精通（5-7 天）
先看 Redis 分布式锁 理解 SETNX + TTL 的基本实现，理解为什么简单实现有缺陷。然后看 Redis 锁的 lease 机制，理解看门狗（Watchdog）续期原理，这是生产环境必备的能力。
Redis 锁最大的坑是：锁的 TTL 和任务执行时间的匹配。如果任务执行时间超过 TTL，锁就会过期，导致其他请求获取到锁，两个任务同时执行。解决方案是用看门狗机制续期，或者根据任务预估时间设置合理的 TTL。
第二阶段：啃透 RedLock（3-5 天）
RedLock 是 Redis 官方提出的分布式锁算法，用多个独立 Redis 节点提高可靠性。但它不是银弹，看 RedLock 的争议与批评 理解它的局限性。
【架构权衡】 RedLock 的核心假设是：多个 Redis 节点是独立部署的，不共享时钟。如果你的 Redis 是主从部署，RedLock 反而可能降低可靠性。理解这一点，才能正确选型。
第三阶段：ZooKeeper 与 etcd（3-5 天）
ZooKeeper 锁 用临时顺序节点实现锁，不依赖 TTL，锁会自动释放。但 ZooKeeper 的性能不如 Redis，适合对可靠性要求极高的场景。配合 选举与锁的关系 理解 ZooKeeper 的选主机制。
etcd 锁 基于 Raft 协议，有线性一致性保证，适合对一致性要求高的场景。
第四阶段：数据库锁补充（2-3 天）
数据库锁是兜底方案，乐观锁用 数据库乐观锁，悲观锁用 数据库悲观锁。适合锁要求不高的场景，或者作为其他锁的补充。
三、生产避坑速查
四、面试高频考点
第一追问：Redis 分布式锁怎么实现？看门狗机制是什么？
考察候选人对 Redis 锁的掌握深度。必须能说清楚 SETNX + TTL 的基本实现，以及 Redisson 的看门狗续期原理。
第二追问：Redis 锁过期了，任务还没执行完怎么办？
考察候选人的实战经验。必须能说清楚看门狗机制、TTL 设置的权衡、任务执行时间的预估方法。
第三追问：RedLock 有什么问题？为什么有人说它不靠谱？
考察候选人对 RedLock 局限性的理解。必须能说清楚 RedLock 的假设条件、独立时钟问题、以及什么场景下不适合用 RedLock。
【架构权衡】 分布式锁的选型没有最优解，只有最适合的解。Redis 锁性能高但有丢锁风险，ZooKeeper 锁可靠但性能低，etcd 锁介于两者之间。选择时必须权衡业务对一致性和可用性的需求。
五、锁的对比速查
本模块覆盖分布式锁从原理到生产的完整链路，每个知识点都来自真实生产事故和踩坑经验。