三种锁横向对比：一张选型地图

选型的第一性问题

老王把三家的资料翻完，问了个直击灵魂的问题：「etcd 看着哪都好，为什么不都用 etcd？」这个问题问出了选型的第一性：世上没有全优的锁，只有匹配场景的锁——性能、一致性、可用性、运维、生态五个维度互相牵制，先把维度摆平，再看场景往里套。

五维度横评

三个注解。性能一列：ZK 的写锁要过半落盘，吞吐天花板最低；etcd 用 Raft 加工程优化（batch、pre-vote、pipelining）比 ZK 快一档，但「共识税」逃不掉。高频竞争锁（每秒成千上万次抢锁）只有 Redis 扛得住。一致性一列：Redis 的丢锁窗口（第 7 篇）是架构级的，共识派不存在这个问题。「锁绝对不能双持有」只有 ZK/etcd 能给。生态一列：K8s 自带 etcd——如果你的服务跑在 K8s 上，一个经过千锤百炼的 Raft 集群就在你身边，复用它做锁几乎零增量运维；同理，Dubbo、Kafka 传统栈里往往早就有 ZK。

场景决策树

锁的竞争频率高吗（每秒 > 百次抢锁）？
├─ 是 → 双跑代价大吗？
│       ├─ 只浪费资源 → Redisson 单实例（效率锁）
│       └─ 双跑即事故 → 重新设计：先消竞争（分段/队列/单飞）
│                          实在消不掉 → Redis 锁 + fencing 兜底
└─ 否（低频）→ 双跑即事故吗？
        ├─ 否 → Redis 锁足够
        └─ 是（选主/任务分配/元数据变更）
                ├─ 跑在 K8s → etcd（复用集群）
                ├─ Dubbo/Kafka 栈 → ZK（复用集群）
                └─ 资金/库存强一致 → 共识锁 + fencing token

注意第一层分叉里的隐藏结论：高频且双跑即事故的锁，本身就说明设计有问题——每秒千次抢锁意味着串行化瓶颈，正确的路子是把竞争消掉（库存分段、请求进 MQ 串行消费、单飞收敛结果），而不是换更快的锁。锁是止损工具，不是吞吐工具。

一个反直觉的结论

把决策树跑一遍真实业务会发现：绝大多数锁需求落在「高频但可容忍极小概率双跑」或「低频且双跑只是浪费」两格里——多数团队的最优解就是一把 Redisson 锁，配上幂等（分布式事务系列第 10 篇）和唯一索引兜底，根本不需要引入 ZK/etcd。共识锁的阵地集中在少数几个点上：定时任务调度的选主、配置的分发仲裁、长任务的执行权分配、资金的强一致互斥。这四类场景共同特征是低频、高危、值得为它养一个协调集群。

老王听完拍板：503 咖啡馆的储值卡扣款走「Redis 锁加幂等」，三家门店的当班调度和促销开关仲裁上 etcd（反正已经跑在 K8s 上）。混用不丢人，按场景配锁、不追求全家桶统一，才是工程成熟的样子。下一篇换个视角：把锁的替代方案翻个遍——乐观锁、唯一索引、队列串行化，很多「抢锁」的冲动，其实是设计可以绕开的信号。