选型的第一性问题
老王把三家的资料翻完，问了个直击灵魂的问题：「etcd 看着哪都好，为什么不都用 etcd？」这个问题问出了选型的第一性：世上没有全优的锁，只有匹配场景的锁——性能、一致性、可用性、运维、生态五个维度互相牵制，先把维度摆平，再看场景往里套。
五维度横评
| 维度 | Redis | ZooKeeper | etcd |
|---|---|---|---|
| 性能 | 十万级 QPS，亚毫秒 | 千级 QPS（写走过半提交） | 万级 QPS（优化优于 ZK） |
| 一致性安全 | 异步复制有丢锁窗口 | ZAB 共识，强 | Raft 共识，强 |
| 可用性 | 哨兵秒级切换，切换即丢锁 | 过半存活即服务，选举秒级 | 同左，恢复更快 |
| 运维成本 | 最低，多数团队本来就有 | 最高，JVM 老系统伺候成本 | 中，云厂商托管普遍 |
| 生态 | Redisson（Java）全平台 | Dubbo/Kafka 传统生态 | K8s/云原生，Go 一等公民 |
三个注解。性能一列：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 上）。混用不丢人，按场景配锁、不追求全家桶统一，才是工程成熟的样子。下一篇换个视角：把锁的替代方案翻个遍——乐观锁、唯一索引、队列串行化，很多「抢锁」的冲动，其实是设计可以绕开的信号。
评论 (0)