分布式锁实现选 etcd 还是 redis 配合 Go 并发更稳？

在 Go 并发场景下，若业务对数据一致性要求严格，选 etcd 实现分布式锁更稳；若追求极致吞吐且能容忍极端情况下的锁失效，选 Redis 更合适。etcd 基于 Raft 协议保证强一致性，Redis 主从切换期间可能存在锁丢失风险。

先说结论：核心业务锁推荐 etcd，缓存类锁可用 Redis，需根据一致性等级决策

适合：强一致性场景选 etcd，高吞吐弱一致性场景选 Redis
重点看：etcd 的 Lease 机制与 Redis 的 Lua 脚本原子性
别忽略：网络分区时的锁安全性与客户端时钟漂移问题

快速处理思路

架构选型阶段直接依据业务容忍度决定，代码实现阶段需处理锁续期与异常释放。Go 语言中推荐使用官方维护的客户端库，避免自行实现底层协议。若已上线 Redis 锁且出现不一致，优先检查主从切换日志与锁过期时间设置。

为什么会这样

etcd 的稳定性源于 Raft 共识算法，Redis 的性能优势源于单线程内存操作。etcd 作为 CP 系统，写入需多数节点确认，确保锁状态在所有节点一致；Redis 作为 AP 系统，主从异步复制可能导致主节点挂掉时锁信息未同步到从节点。Go 并发协程切换频繁，若锁服务本身不一致，业务层无法通过本地代码弥补。

分步处理

第一步评估业务场景，第二步选择客户端库，第三步实现锁逻辑并添加监控。若选 etcd，使用 go.etcd.io/etcd/client/v3 包，利用 Lease 保持锁存活；若选 Redis，使用 go-redis/redis 包，配合 Lua 脚本保证加锁解锁原子性。代码中必须设置 context 超时，防止协程泄漏导致锁无法释放。

// etcd 锁示例片段
resp, err := client.Lease.Grant(ctx, ttl)
if err != nil { return err }
// 绑定 lease 到 key
_, err = client.Put(ctx, key, val, clientv3.WithLease(resp.ID))

配置完成后，需在测试环境模拟节点故障，观察锁是否正确转移或释放。生产环境部署时，etcd 集群建议至少 3 节点，Redis 建议开启持久化并评估 RDB/AOF 对性能影响。

怎么验证是否生效

通过并发压测工具模拟多协程竞争同一锁资源，检查临界区代码是否串行执行。查看 etcd 或 Redis 服务端日志，确认无频繁超时或连接重置错误。在 Go 程序中添加锁等待时长监控指标，若出现异常尖峰需排查网络或服务负载。故障演练时手动 Kill 锁服务主节点，观察业务是否出现重复执行或死锁。

常见坑

第一，Redis 锁过期时间设置过短，业务未执行完锁已释放，导致并发穿透。第二，etcd Lease 续期失败未处理，协程持有无效锁继续执行。第三，Go 程序发生 GC 停顿时间过长，导致锁心跳中断被服务端回收。第四，时钟同步问题，分布式系统依赖时间判断锁过期，节点间时间偏差会导致锁状态误判。

常见问题

etcd 锁性能比 Redis 差多少？

公开资料中没有看到可靠的量化数据，但 etcd 因共识机制延迟通常高于 Redis。若业务对毫秒级延迟敏感且能接受极低概率不一致，Redis 更优。

Go 程序崩溃后锁会自动释放吗？

取决于锁实现机制，etcd Lease 随会话结束自动失效，Redis 需依赖过期时间。未设置过期时间的 Redis 锁在客户端崩溃后会永久占用。

是否需要实现锁续期机制？

长耗时业务必须实现续期，防止锁过期导致并发冲突。续期逻辑需独立协程运行，并处理上下文取消信号以避免泄漏。

参考来源

etcd 官方文档，Lease API 说明，https://etcd.io/docs/
Redis 官方文档，Distributed locks with Redis，https://redis.io/
Martin Kleppmann 博客，How to do distributed locking，https://martin.kleppmann.com/