第 11 章 · 分布式锁 — 可视化演示

三个交互演示：① V1/V2/V3 演进时序图 · ② 看门狗续期对比 · ③ Redlock 多实例

多客户端抢锁时序：V1 / V2 / V3 对比

选择算法版本，点「开始演示」。Client-A 在中途崩溃，看 Client-B 能否拿到锁。

算法版本：

Client-A

Client-B

Redis

lock 状态

0s2s4s6s8s10s

点「开始演示」观察时序

关键观察：V1 崩溃后锁永久占用 → 死锁；V2 SETNX 后崩溃，锁也无 TTL → 死锁；V3 一条原子命令含 TTL，崩溃后自动恢复。

左侧无看门狗：锁过期被别人抢；右侧有看门狗：每 3s 自动续期，业务安全完成。

业务执行(s)：锁 TTL(s)：续期间隔(s)：动画速度：

业务

锁所有者

业务

锁所有者

看门狗工作原理：一个守护线程每隔 TTL/3 检查持有者是否仍是自己（用 Lua 校验），是则 PEXPIRE 续到原 TTL。业务释放锁时停止守护线程。

陷阱：续期前必须校验，否则锁过期被别人拿走后还在续 → 把别人的锁续走了！

客户端依次向 5 个实例 SET NX，需要在 多数派 (≥3) 上成功，且 总耗时 < TTL。可调节失败实例数、单实例延迟。

故障/被占用实例：每实例 RTT（ms）：锁 TTL（ms）：慢实例（>TTL）：

状态等待启动

Redlock 判定：① 多数派加锁成功（5 实例需 ≥3）且 ② 总耗时 < TTL。两条任一不满足，去所有实例释放，加锁失败。

争议：Kleppmann 指出 GC 暂停 / 时钟回拨 / 网络分区下 Redlock 仍不安全。绝对一致请用 fencing token + 业务幂等。