别等 Redis 异步切主搞出重复扣款才后悔：从实战故障聊聊 Redisson 与 etcd 分布式锁选型

做支付和订单这些年，最怕半夜对账不平被叫起来排查，十次有八次能顺藤摸瓜扯到“分布式锁”头上。

聊聊这俩选型，别一上来就无脑推 Redisson 的看门狗机制。先说我以前踩过的一个血泪事故：

当时一笔大额退款走 Java 服务的 Redisson 锁防重，因果链其实特简单： JVM 突发长 Full GC（Stop-the-World） -> 续期线程直接卡死 -> Redis key 达到租期被自动释放 -> 另一个 Pod 成功抢锁并行执行 -> 重复调用下游渠道退款 -> 账目直接挂单，通宵手动做平账冲正。 更别提 Redis Cluster 异步主从复制在发生 Failover 时的天然丢锁问题了，本质上它就是个 AP 架构，防君子不防极端并发。

后来带 Go 团队重构底层扣款链路，我们把核心事务的互斥换成了 etcd 的 Lease + Revision 机制机制： Raft 共识保证强一致 -> 节点挂了不会脑裂 -> Revision 递增天然支持排队避免惊群。 但代价也很真实：etcd 的写性能上限明显，长连接一多、Lease 心跳高频打过来，Raft 状态机压力剧增，根本扛不住秒杀级吞吐。

个人的粗浅总结：

1. 重吞吐、容忍极低概率并发穿透（如：接口防抖、非核心定时任务、发券）：无脑走 Redisson，简单省事，吞吐量大；
2. 碰钱、碰库存、要求绝对强一致（如：资金清结算、跨系统状态冲正）：果断上 etcd / Consul，甚至直接退回到“数据库悲观锁 + 唯一键约束 + 状态机幂等”。

各位生产环境里是怎么抉择的？有没有在 Golang 高并发核心链路里硬扛 etcd 踩过坑的兄弟？大家来聊聊你们的锁降级策略。