脑裂导致redis锁失效的典型现象是跨机房或主从切换后，两个节点同时认为自己持有同一把锁（如lock:order:123），日志显示“加锁成功”但业务逻辑并行执行，根源在于redis异步复制与无租约续期机制引发的一致性断裂，单点redis在该场景下天然不可靠。
脑裂导致Redis锁失效的典型现象
跨机房或主从切换后，两个节点同时认为自己持有同一把锁：lock:order:123，日志里能看到“加锁成功”但业务逻辑并行执行。这不是代码写错了，而是Redis异步复制+无租约续期机制共同导致的底层一致性断裂。
必须放弃单Redis集群锁方案
单点Redis在脑裂场景下天然不可靠——主从切换后，旧主上的锁未同步到新主，客户端仍用旧锁值操作，互斥性彻底失效。你不能靠“加重试”或“调大TTL”来修复这个问题，这是CAP权衡下的结构性缺陷。
- 不要用
SET key val EX 30 NX单独部署在跨机房环境 - 不要依赖Redisson的
watchdog自动续期——它无法感知网络分区，续期请求可能发往已隔离的旧主 - Redlock协议已被证明在时钟漂移和网络延迟不可控时不可靠，不推荐用于生产
用Etcd多Region租约仲裁替代Redis
Etcd基于Raft强一致协议，天然支持跨机房多活。关键不是换组件，而是重构锁语义：从“抢占式加锁”转向“租约共识”。
- 部署至少3个Region的Etcd集群（如北京、上海、深圳），每个Region含3节点
- 加锁必须走
client.Txn(ctx).If(...).Then(...)，用Compare检查lease ID是否有效，而非只查key是否存在 - 所有锁操作必须带
WithRequireLeader，避免读到脏数据 - TTL设为15s，续租间隔≤5s，并在
KeepAliveOnce失败时主动Revoke旧lease
本地缓存+singleflight只能缓解，不能根治
singleflight.Group能合并本进程内重复请求，但它对跨节点并发完全无效；本地缓存哪怕加了sync.RWMutex，也拦不住其他Pod的请求。真正的防护边界必须划在外围存储层。
最容易被忽略的是：脑裂问题从来不是“锁没加好”，而是“选错了协调者”。当你还在调试lua script释放逻辑时，应该先确认你的基础设施是否支持强一致——这比任何Go代码都关键。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
