承接上一篇公平锁、异步锁、读写锁内容，本篇重点讲解 Redisson 联锁（MultiLock） 与 红锁（RedLock） 完整落地实现、底层差异、线上踩坑案例、性能优化方案，同时区分二者使用边界、搭配事务 / 超时 / 异常处理，补齐多节点分布式锁的生产实践要点。
一、前言
在复杂微服务、多资源联动、跨节点数据强一致场景中，单把分布式锁已经无法满足需求。比如同时操作多个独立库存、多表联动扣减、跨服务资源互斥，就需要多锁联动 。 Redisson 提供了两种主流多锁方案：联锁 MultiLock 、红锁 RedLock。很多开发者容易混淆二者，本篇从原理、流程、代码、风险、调优五个维度拆解，并结合线上真实故障做复盘。
二、Redisson 联锁（MultiLock）实战
2.1 核心定义与适用场景
联锁：将多个独立的 Redis 锁绑定为一个整体 ，遵循「全部加锁成功才算成功，任意一把加锁失败则全部回滚」的规则。
- 本质：一把逻辑上的复合锁，所有锁加锁、解锁、等待、续期动作统一执行。
- 典型场景：
- 同时操作多个互斥资源（多商品库存、多账户余额）；
- 微服务中多个独立业务节点需要同时互斥；
- 同一份 Redis 实例下，多个 Key 组合实现资源隔离。
2.2 底层执行流程
3.2 完整执行流程
3.3 适用场景 & 禁用场景
适用场景（数据零丢失要求）
不建议使用场景
- 客户端按顺序依次尝试获取集合内所有锁；
- 必须所有锁全部加锁成功，联锁才算获取成功，执行业务；
- 中途任意一把锁加锁失败，立刻执行反向解锁，释放前面已经拿到的锁，避免死锁；
- 解锁时一次性批量释放所有锁；
- 继承原生锁能力：支持可重入、看门狗续期、阻塞等待、超时控制。
三、Redisson 红锁（RedLock）深度落地
3.1 设计初衷与定位
红锁源自 Redis 官方 RedLock 算法，专门解决主从异步复制、节点宕机导致锁丢失问题。
7. 架构要求：N 个完全独立、无主从关联、互不通信的 Redis 节点（推荐奇数：3/5 个）；
8. 判定规则：超过半数节点加锁成功，红锁才算生效；
9. 核心价值：容忍少数节点宕机，保证分布式锁高可用、数据强一致。
10. 客户端记录当前时间戳，依次向所有独立 Redis 节点发起加锁；
11. 逐个节点执行加锁（Lua 原子脚本 + 短期过期时间）；
12. 统计加锁成功节点数，成功数 > N/2 且整体耗时未超过锁有效期，判定加锁成功；
13. 加锁成功：执行业务，同时启动看门狗统一续期所有节点锁；
14. 加锁失败：立即向所有节点执行解锁，清理残留锁数据；
15. 解锁：统一向全部节点发送解锁脚本，保证全域释放。
16. 金融支付、资金账户、订单核心链路、秒杀库存等强一致性业务；
17. 对锁丢失、超卖、重复执行零容忍的核心模块。
18. 普通查询、非核心运营业务：架构重、网络开销大、性能偏低；
19. 节点混用主从 / 集群：破坏红锁「独立节点」设计，效果失效。