收官复盘：一张作战地图串起整个系列

从 110 块的糊涂账说起

系列开篇那笔糊涂账：储值卡剩 100，两店同时刷卡，流水扣了 110，账面剩 20，一笔扣款凭空蒸发。二十篇之后回头看，那笔账的病灶一行代码就能定位——「读、判断、写」之间的竞态窗口，被多实例部署从单机问题放大成了分布式问题。但真正值得带走的是处置它的完整地图：怎么互斥、互斥的代价是什么、互斥靠不住时谁兜底、以及大多数时候根本不需要互斥。收官篇把这张地图摊开。

二十篇的行军路线

第 1 到 7 篇是Redis 锁的进化史：SETNX 起步、TTL 防死锁、Lua 保原子、UUID 保身份、看门狗保续期、Redisson 做工程封装，RedLock 论战立起「效率与正确性」的分野，主从切换的丢锁窗口给时间型锁画上安全边界。第 8 到 11 篇是ZooKeeper 的共识课：ZNode 与临时节点搭台，ZAB 用过半提交与 epoch 更替背书，临时顺序节点把锁做成天生公平，会话幽灵与性能天花板交底短板。第 12 到 14 篇是Raft 的工业化：一票一任期一份日志，两条提交红线守住「已提交不丢」，Lease 与 revision 两块积木造出更简洁的锁。第 15 到 20 篇是落地与兜底：五维选型、四个替代方案、fencing 终审、运维权衡、七个事故、这张地图。

症状速查表

三条铁律

铁律一：锁分效率与正确性，先分类再选型。效率锁（防重复跑、防击穿）单实例 Redisson 足矣，配幂等兜底；正确性锁（资金、库存）要么共识派（ZK/etcd）要么 fencing 兜底，绝不裸奔。分不清这两类，后面十八篇白读。铁律二：锁的生死绑活性，不绑业务时长。看门狗、会话、租约的共同智慧是「持有人活着，锁就活着」；TTL 猜业务时长的写法，短了互斥破碎，长了故障拖死——参数永远赌不赢没有上界的业务。铁律三：资金级安全要三层防线。锁的知情机制（减损）+ 幂等与唯一索引（防重）+ fencing token（终审）三层全上；任何单层都可能被幽灵击穿，叠加才构成纵深。

四步选型路径

第一步  能不能用替代方案？
        防重复 → 唯一索引   改数据 → 乐观锁
        短事务 → 行锁       高频写 → 队列串行化
第二步  能不能消掉竞争？
        分段、单飞、请求收敛——锁是止损不是吞吐
第三步  效率还是正确性？
        效率 → Redis 单实例（幂等兜底）
        正确性 → 进第四步
第四步  共识派怎么选？
        K8s/云原生 → etcd    Dubbo/Kafka 老栈 → ZK
        资金级 → 共识锁 + fencing token 三层防线

十项上线检查清单

一，unlock 全部在 finally 里，异常路径也释放；二，锁 key 带用途与负责人元数据，事故能取证；三，无参 lock 交给看门狗，带 leaseTime 的调用逐个注释业务上界；四，释放与续期的 Lua 身份校验在位，不存在裸 DEL；五，业务实测时长与锁 TTL 的比值有监控告警；六，等待方有超时与退避，不存在无限自旋；七，「防重复」类需求已用唯一索引兜底，锁只做第一道；八，资金路径的灵魂拷问通过：「丢锁了会怎样？」答案不是「不会丢」；九，协调服务一身不兼二职，高频锁与注册配置隔离；十，全链路故障演练跑过一遍——主从切换、GC 停顿、网络分区都演过。十项全绿再上生产。

系列之外

Redis、MySQL、消息队列、Elasticsearch、分布式 ID、分布式事务，加上这套分布式锁与一致性协议，七个系列把后端主干地图拼得七七八八。还有一块硬骨头与本系列血脉相连——事故五里「重试风暴拖垮下游」、压测里「雪崩式连坐」，都是同一个主题的不同面孔：限流与熔断。流量是散装的商品，系统的容量是有限的货架，怎么限流、怎么熔断、怎么优雅降级，是下一个系列的主角。老王的 503 咖啡馆继续开门，我们下个系列见。

小结

收官一句话：先分类再选型、锁绑活性不绑时长、资金级三层防线——三条铁律扛走，二十篇的细节都在这张地图上，用的时候来查。分布式锁与一致性协议实战系列，全二十篇，完结撒花。