欢迎来到布式锁地图：Redis、Redlock、Advisory Lock、CAS
版权声明
我们非常重视原创文章，为尊重知识产权并避免潜在的版权问题，我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容，访问作者的公众号页面获取完整文章。
查看原文：
文章来源： 文章主旨： 分布式锁是协调多节点共享资源访问的关键机制，主要方案包括 Redis SET NX EX、Redlock 和心跳续期，每种方案都有适用场景和边界，工程上需根据业务风险进行取舍。
关键要点：
- 分布式锁的核心是将单进程互斥语义扩展到跨进程、跨节点环境，解决支付重试、库存超卖等并发冲突。
- 基于 Redis 的 SET NX EX 模式是最易落地的方案，通过原子写入 + Lua 安全释放 + 唯一 ownerId 实现，但存在单点故障和主从切换数据丢失风险。
- Redlock 算法依赖多个独立 Redis 节点的多数派同意，提高容错性，但不能完全避免时钟漂移和 TTL 过期导致的慢请求问题，建议使用成熟库而非自实现。
- 心跳续期机制（后台续期线程）可动态延长锁持有时间，避免 TTL 设置的两难（过长导致死锁等待、过短导致业务未完成），常用每 1/3 TTL 续期一次。
内容结构：
1. 分布式锁为什么存在
以支付服务和售票系统为例说明并发冲突场景，根源是多进程在无共享内存时协调访问同一资源。分布式锁本质是将互斥语义扩展到跨进程、跨节点，保证同一时刻只有一个持有者进入关键区。
2. 基于 Redis 的锁：SET NX EX 模式
介绍最常用的方案：使用 Redis 原子 SET 命令（NX + PX）加锁，用 Lua 脚本校验 owner 后释放。提供 TypeScript 和 Go 实现示例。关键点包括：NX 保原子性、PX 设过期防死锁、Lua 脚本防误删、唯一 ownerId。短板：单 Redis 节点是单点，主从切换可能丢失锁状态。
3. Redlock 算法
在单节点 Redis 可靠性不足时，Redlock 将锁分散到多个独立实例，只当多数节点返回成功（且剩余 TTL 足够）时才认为加锁成功。提供 TypeScript 实现示例。价值：多数派机制容忍少量节点故障、有效窗口计算、需更高实现复杂度。注意：不是银弹，没有围栏令牌能力，更推荐使用成熟库（如 redlock、redsync）。
4. 心跳续期
解决固定 TTL 两难：设短业务未完成、设长死锁等待。方案是后台续期线程（每 1/3 TTL 续一次），提供 Go 实现示例。本质是通过动态延长锁持有时间来平衡安全性与可用性。
文章总结： 分布式锁没有万能方案，工程上需根据业务场景（如金融交易、一般资源竞争）仔细评估锁的可靠性要求与实现复杂度，优先选用成熟库以避免细节陷阱。
FunTester
文章来源： 
1425
还在用多套工具管项目？
一个平台搞定产品、项目、质量与效能，告别整合之苦，实现全流程闭环。
白皮书上线
-
联系我们
电话：4006 8899 23 邮箱：beining@chandao.com -
融实践库
关于我们 加入我们立即学习
微信号：rongpmcom
-
微信公众号
-
微信视频号
-
社区微信群
