Go实现分布式锁：Redis、Etcd和数据库对比

“纵有疾风来，人生不言弃”，这句话送给正在学习Golang的朋友们，也希望在阅读本文《Go 实现分布式锁：Redis、Etcd 与数据库对比》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新Golang相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

Redis分布式锁易出错因原子性、自动续期、安全释放未对齐；需唯一标识、Lua校验释放、独立心跳续期；etcd的CAS+Lease更可靠；数据库行锁仅适用于低频短时场景。

Redis 实现分布式锁为什么容易出错？

Redis 最常用但最易翻车，核心问题不在 SET 命令本身，而在「原子性 + 自动续期 + 安全释放」三者没对齐。比如用 SET key value EX 30 NX 能防并发争抢，但业务执行超时后，锁被自动释放，另一个节点拿到锁，而前一个还在跑——典型的「锁被别人删了」。

真正可用的方案得满足：锁必须带唯一标识（防止误删）、释放必须用 Lua 脚本校验值、续期得靠独立心跳协程（比如用 redis.NewLock 配合 WithTTL 和 WithAutoRefresh）。

• 别手写 DEL 删除逻辑，必须用 Lua 确保「判断 value == 当前 token 再删」
• 过期时间不能拍脑袋设，要大于 99% 的业务执行耗时 + 网络抖动余量
• Redlock 在 Go 生态里基本没人用——它依赖多个独立 Redis 实例，实际部署复杂且收益有限

etcd 的 CompareAndSwap 为什么更可靠？

etcd 天然支持基于 Revision 和 Lease 的强一致性锁，clientv3.Txn() 可以在一个事务里完成「检查旧值 + 设置新值 + 绑定租约」，不存在中间态。租约到期自动释放，也不用担心客户端崩溃导致死锁。

Go 官方 clientv3 提供了开箱即用的 clientv3.NewMutex，底层就是封装好的 CAS + Lease 逻辑，比 Redis 手动拼更省心。

• 加锁是阻塞式调用：mutex.Lock(ctx)，会自动重试直到成功或超时
• 解锁只需 mutex.Unlock(ctx)，内部通过 Lease ID 关联，不会误删他人锁
• 注意 ctx 传的是锁操作上下文，不是业务上下文；超时应设在 Lock 调用前，而非整个函数

数据库行锁能当分布式锁用吗？

可以，但只适合低频、短时、强一致要求不高的场景。比如「用户每日首次签到」这种幂等性明确、执行快、冲突少的操作，用 INSERT ... ON CONFLICT DO NOTHING（PostgreSQL）或 INSERT IGNORE（MySQL）模拟锁，简单粗暴。

但它本质不是锁机制，而是利用唯一约束失败来感知竞争。一旦出现锁等待、死锁、连接中断，行为不可控，且性能随并发线性下降。

• 避免用 SELECT ... FOR UPDATE 做长事务锁——网络延迟或 panic 会导致连接未释放，锁滞留数分钟
• 唯一索引字段必须是业务无歧义的键（如 user_id），不能是自增 ID 或随机字符串
• 失败后不要盲目重试，先查表确认是否真没生效，否则可能重复插入或漏处理

选型关键看这三点

不用纠结「哪个技术更高级」，盯住你的服务特征：锁持有时间、QPS 峰值、容错容忍度。

• 秒级锁 + QPS github.com/go-redsync/redsync（别自己造轮子）
• 毫秒级锁 + 强一致性必须保障 + 已有 etcd → 直接上 clientv3.NewMutex，Revision 语义天然防误删
• 单次锁几毫秒 + 每天最多几百次 + 不想引入新组件 → 数据库唯一约束兜底，但得写好幂等回查逻辑

跨语言协作时，etcd 协议比 Redis SET 指令更规范，Lua 脚本和租约 TTL 这些细节最容易在交接时漏掉——文档再全，也不如租约 ID 和 Revision 这种服务端生成的硬指标靠谱。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~