Redisson 分布式锁全解析：从单锁到 MultiLock
一、Redisson基础分布式锁：从流程图看核心原理
Redisson的基础分布式锁RLock，是业界实现Redis分布式锁的标杆方案，它解决了原生SETNX锁的原子性、续期、重入等问题。我们先从经典的锁流程图，拆解其获取与释放的完整逻辑。
1.1 锁的获取流程
Redisson的加锁逻辑通过原子Lua脚本保证操作的原子性，避免并发场景下的竞态问题，整个流程可分为「加锁成功」和「加锁失败等待」两个分支：
分支1：加锁成功（TTL为null）
当客户端尝试获取锁时，Lua脚本会检查锁对应的Redis Key：
- 若Key不存在：直接创建锁（采用Hash结构存储，Key为锁名，Field为「客户端ID:线程ID」，Value为重入次数），并设置初始过期时间；
- 若Key存在且为当前线程持有：重入次数+1，返回
null表示加锁成功。
此时会根据用户设置的leaseTime（锁持有超时时间）做分支判断：
- 若
leaseTime != -1：表示用户手动指定了锁超时时间，直接返回true，锁会在超时后自动释放； - 若
leaseTime == -1（Redisson默认场景）：开启WatchDog看门狗机制，由后台定时线程为锁续期，避免业务未执行完锁就提前过期。
分支2：加锁失败（TTL不为null）
若锁已被其他线程持有，Lua脚本会返回锁的剩余存活时间（TTL），此时进入等待流程：
- 判断剩余等待时间是否大于0：若用户设置的
waitTime（最大等待时间）已耗尽，直接返回false，加锁失败； - 订阅锁释放信号：客户端通过Redis的Pub/Sub机制订阅锁对应的释放消息通道，避免无效轮询；
- 等待信号或超时：若收到锁释放信号且未超时，回到「尝试获取锁」步骤重新竞争；若等待超时仍未收到信号，返回
false。
1.2 锁的释放流程
锁的释放同样通过原子Lua脚本保证原子性，流程清晰且兼顾异常场景：
- 尝试释放锁：检查锁是否存在、是否为当前线程持有，若不匹配则抛出异常；
- 处理重入次数：若锁为当前线程持有，重入次数-1，减为0则删除锁；
- 通知等待线程：释放成功后，向锁对应的Pub/Sub通道发送「锁释放消息」，通知等待的线程重新竞争；
- 取消看门狗：若开启了WatchDog续期，终止定时任务，避免无效续期；
- 异常处理：若释放失败（如锁已过期、不属于当前线程），记录异常并结束流程。
1.3 三大核心机制拆解
Redisson锁的可靠性，离不开这三个关键设计：
| 机制 | 核心作用 |
|---|---|
| 可重入锁 | 基于Hash结构实现，同一线程可多次加锁，重入次数匹配后才会真正释放锁，避免死锁 |
| WatchDog看门狗 | 默认每10秒（锁过期时间的1/3）续期一次，只要客户端存活就持续重置锁过期时间；客户端宕机则锁会在30秒后自动过期，兼顾业务连续性与死锁避免 |
| Pub/Sub等待 | 避免等待线程轮询Redis，锁释放时主动通知，大幅降低Redis压力，减少无效等待 |
二、Redisson MultiLock：多资源原子锁的解决方案
基础RLock仅支持单个资源的加锁，当业务需要同时操作多个独立资源（如订单、库存、支付），且必须保证「要么所有资源都锁住，要么都不锁」时，就需要用到Redisson提供的MultiLock。
2.1 MultiLock是什么？解决什么问题？
MultiLock是Redisson提供的多锁聚合器，它可以将多个独立的RLock合并为一个逻辑上的锁，实现「所有子锁都获取成功，才算加锁成功；释放时必须释放所有子锁」的原子性语义。
它主要服务于两类场景：
- 多资源原子性加锁：避免部分资源加锁成功、部分失败导致的数据不一致；
- 跨多Redis节点锁聚合：可将不同Redis实例/集群上的锁合并为一个逻辑锁，是RedissonRedLock的基础组件。
⚠️ 关键区分：MultiLock本身不是RedLock算法，它不具备节点故障容错性，必须所有子锁都获取成功才算成功；而RedissonRedLock基于RedLock算法，只要超过半数节点加锁成功，整体就算成功。
2.2 核心特性一览
- 原子性加锁/回滚：加锁时按顺序获取子锁，任意子锁失败则立刻释放所有已获取的锁，避免「孤儿锁」；
- 顺序性约束：加锁/释放时按固定顺序操作，需保证所有客户端加锁顺序一致，否则可能引发死锁；
- 可重入性：每个子锁支持重入，
MultiLock整体也支持同一线程多次加锁； - WatchDog支持：默认模式下会为所有子锁开启看门狗续期，与业务执行生命周期绑定；
- 跨实例兼容：子锁可来自同一个或不同的RedissonClient实例。
2.3 基础使用示例
import org.redisson.Redisson;
import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
import org.redisson.api.RedissonMultiLock;
public class MultiLockExample {
public static void main(String[] args) {
// 1. 初始化多个Redisson客户端（可同实例/跨实例）
Config config1 = new Config();
config1.useSingleServerConfig().setAddress("redis://127.0.0.1:6379");
RedissonClient client1 = Redisson.create(config1);
Config config2 = new Config();
config2.useSingleServerConfig().setAddress("redis://127.0.0.1:6380");
RedissonClient client2 = Redisson.create(config2);
// 2. 获取多个独立锁对象
RLock orderLock = client1.getLock("resource:order:1001");
RLock stockLock = client2.getLock("resource:stock:2001");
// 3. 构建MultiLock
RedissonMultiLock multiLock = new RedissonMultiLock(orderLock, stockLock);
try {
// 4. 加锁：设置总等待时间10秒，锁持有时间30秒
boolean locked = multiLock.tryLock(10, 30, java.util.concurrent.TimeUnit.SECONDS);
if (locked) {
// 业务逻辑：同时操作订单+库存资源
System.out.println("MultiLock获取成功，执行业务逻辑");
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
} finally {
// 5. 释放锁：逆序释放所有子锁，即使部分失败也会继续执行
multiLock.unlock();
}
client1.shutdown();
client2.shutdown();
}
}
2.4 加锁与释放流程
加锁流程：串行获取+失败自动回滚
- 初始化总等待时间：根据用户设置的
waitTime，计算每个子锁的剩余等待时间，确保整体耗时不超过限制； - 按顺序获取子锁：遍历所有子锁，按传入顺序依次调用
tryLock，每个子锁的加锁逻辑与普通RLock一致； - 结果处理：
- 所有子锁获取成功：
MultiLock加锁成功，开启所有子锁的看门狗续期； - 任意子锁获取失败：立刻终止后续加锁流程，逆序释放所有已获取的子锁，返回加锁失败。
- 所有子锁获取成功：
释放流程：逆序释放+异常兼容
- 逆序释放子锁：按与加锁相反的顺序释放子锁，降低死锁概率；
- 原子性释放每个子锁：通过Lua脚本判断锁归属、处理重入次数，成功则发送Pub/Sub信号；
- 异常兼容：即使某个子锁释放失败，也会继续释放其他子锁，最终抛出异常提醒用户；
- 取消看门狗：终止所有子锁的续期任务，避免无效续期。
2.5 关键注意事项与踩坑指南
- 加锁顺序必须全局一致：若不同客户端对同一批子锁使用不同的加锁顺序（如A按
lock1→lock2，B按lock2→lock1），会出现循环等待导致死锁； - 不适合节点故障容错场景：只要有一个Redis节点故障，
MultiLock就会加锁失败，这类场景应使用RedissonRedLock； - 性能开销需关注：
MultiLock需要与多个Redis节点通信，延迟比单锁高，跨机房场景需合理设置超时时间； - 看门狗的局限性：若包含跨节点子锁，当其中一个Redis节点故障时，看门狗无法为该节点的锁续期，锁会自动过期导致
MultiLock失效。
三、三种锁方案对比：RLock vs MultiLock vs RedissonRedLock
| 对比项 | 普通RLock | MultiLock | RedissonRedLock |
|---|---|---|---|
| 加锁成功条件 | 单个锁获取成功 | 所有子锁都获取成功 | 超过半数（N/2+1）子锁获取成功 |
| 容错性 | 无（依赖单个节点） | 低（任意节点故障即失败） | 高（允许少数节点故障） |
| 适用场景 | 单Redis节点/主从集群的分布式锁 | 多资源原子加锁、跨节点强一致场景 | Redis节点故障容错的高可用分布式锁 |
| 性能 | 高（单节点通信） | 中（多节点串行通信） | 中（多节点通信） |
| 看门狗支持 | 支持 | 支持（所有子锁续期） | 支持 |
四、Redisson锁的最佳实践
- 优先使用普通RLock：单资源场景下，
RLock性能最优，且机制成熟稳定； - MultiLock仅用于多资源原子场景：不要为了跨节点容错使用
MultiLock，这类场景应选择RedissonRedLock； - 加锁顺序全局统一：所有客户端对同一批子锁的加锁顺序必须一致，避免死锁；
- 合理设置超时时间：
waitTime避免设置过长导致业务阻塞，leaseTime需大于业务执行时间，或依赖看门狗续期； - 释放锁必须在finally中执行：避免业务异常导致锁无法释放，造成死锁。
五、总结
Redisson的分布式锁并非银弹，不同的锁实现对应不同的业务场景：普通RLock解决单资源的分布式互斥问题，MultiLock解决多资源加锁的原子性问题，而RedissonRedLock则解决Redis节点故障的容错问题。
理解底层的Lua脚本、看门狗、Pub/Sub机制，以及MultiLock的加锁回滚逻辑，才能在实际业务中避免死锁、锁泄漏等问题，让分布式锁真正可靠。
后续会更新RedissonRedLock的原理与实现，以及分布式锁的常见面试题解析，欢迎关注~
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Bird的个人博客！
相关推荐
2026-05-18
从单点到集群：Redis 分布式缓存的演进之路
在分布式系统的架构中，缓存几乎是绕不开的一环。而Redis，凭借其高性能、丰富的数据结构和多样的部署模式，成为了缓存领域的绝对王者。但很多同学刚接触Redis时，可能只停留在set/get的使用层面，对它从“单点单机”到“分布式集群”的演进过程一知半解。 今天，我就带着大家顺着「单点Redis → 持久化 → 主从复制 → 哨兵模式 → 分片集群」这条线，聊聊Redis是如何一步步解决高可用、高性能、可扩展三大难题的，也算是对自己这段时间学习Redis的一个总结。 一、单点Redis：看似简单，却隐患重重刚接触Redis时，我们最先接触的就是“单点部署”——一个Redis实例，服务直接连接它读写数据。这种模式开发简单、部署方便，但在生产环境中却隐患重重： 性能瓶颈Redis核心逻辑是单线程的，单节点的处理能力有明确上限，面对高并发的读/写请求，很容易成为系统的瓶颈；同时单节点的内存也有限，无法存储海量的缓存数据。 可靠性灾难这是更致命的问题。如果这个唯一的Redis节点挂了（比如进程崩溃、服务器宕机），会直接导致缓存失效，请求全部打到数据库，引发“缓存雪...
2026-05-26
深入理解 Redis 网络模型：从用户 / 内核空间到 IO 多路复用
面试的时候，被问到“Redis为什么快”，很多人第一反应都是“因为它是单线程的，没有锁竞争，而且数据存在内存里”。 但如果面试官接着问：“单线程的Redis，怎么同时处理上万条客户端连接？为什么它的网络模型这么高效？” 很多人就答不上来了。 Redis的高性能，绝不仅仅是“单线程+内存”这么简单，它的网络IO模型，才是支撑它高并发的核心。今天，我就从最基础的“用户空间/内核空间”讲起，一步步拆解五种IO模型，最后落到Redis的网络模型上，彻底搞懂它为什么这么快。 一、基础铺垫：用户空间 & 内核空间要理解IO模型，首先得搞懂操作系统的两个核心概念：用户空间（User Space） 和 内核空间（Kernel Space）。 1. 为什么要划分这两个空间？操作系统为了保护内核的安全，把内存分成了两部分： 用户空间：我们写的应用程序（比如Redis、Java程序）运行的地方，权限低，不能直接操作硬件资源（比如网卡、磁盘）。 内核空间：操作系统内核运行的地方，权限高，负责管理硬件资源、调度进程、处理IO等核心操作。 举个例子：当Redis要从客户端读取数据时，...
2026-06-10
Hermes+飞书搭建专属Java求职AI助手
手把手搭建专属Java求职AI助手｜Hermes+飞书全流程（避坑实战版）作为一名备战Java求职的开发者，我踩了无数坑后终于用Hermes+飞书搭建出一套分工明确、自动复盘、长效记忆、可监督的专属求职助手体系。整套体系包含6个AI角色，覆盖Java学习、算法刷题、面试八股、AI开发、模拟面试、学习进度管理全场景。本文为完整落地经验贴，跟着步骤即可一键部署属于自己的求职AI团队。 一、方案价值与核心优势1. 解决求职备考痛点 学习记录零散，无法清晰梳理已掌握/薄弱知识点； 通用AI角色不固定，回答风格混乱，不贴合面试场景； 大模型存在上下文长度限制，长期对话容易丢失历史学习记录； 缺少专人监督与计划制定，备考节奏混乱，模拟面试无专业对手。 2. 本套方案核心亮点 角色专业化分工：6个机器人独立人设，回答风格、输出规则固定，适配不同学习场景； 外置记忆中枢：通过「学习监督官」统一托管学习数据，规避大模型上下文限制； 飞书生态集成：私聊/群聊直接使用，无需额外客户端，上手零门槛； 一键后台启动：批处理脚本静默运行，无需手动逐个启动服务； 灵活模型切换：支持主流大...
2026-06-05
RabbitMQ 三大核心实战：消息回退、死信队列、延迟队列
摘要：RabbitMQ除基础消息收发外，消息回退（备份交换机）、死信队列、延迟队列是项目生产环境最常用的三大高级特性。本文结合SpringBoot完整拆解原理、踩坑点与两种延迟实现方案，从理论到实战落地，适配日常订单超时、异常消息兜底、路由失败防丢等业务场景。 前言在分布式系统中，RabbitMQ常用来实现异步解耦、削峰填谷，但原生默认配置下容易出现消息丢失、异常消息堆积、定时延时处理困难等问题。 消息找不到队列被丢弃？→ 消息回退 + 备份交换机兜底 消费失败消息无限重试占用队列？→ 死信队列DLQ隔离异常数据 订单超时未支付自动关单？→ 延迟队列两种实现方案 本文基于SpringBoot版本进行全部代码演示，贴合项目实际开发规范。 一、发布确认高级：消息回退与备份交换机 生产者发送消息到Broker分两个阶段：Confirm确认（消息成功抵达交换机） + Return回退（交换机无法路由到队列），Confirm保证消息到交换机，而回退消息+备份交换机用来解决「交换机收到消息，但没有匹配队列导致消息丢失」的问题。 1.1 回退消息（Return机制）原理 开启生产者r...
2026-04-10
Synchronized 与 ReentrantLock
Java 并发：synchronized 与 ReentrantLock 全面解析一、前言在 Java 多线程编程中，线程安全是核心问题。synchronized 与 ReentrantLock 是最常用的两种同步方案，都能实现可重入独占锁，保证临界区代码的原子性、可见性与有序性。 本文从底层原理、使用方式、核心特性、对比选型四个维度，帮你彻底搞懂二者的区别与适用场景。 二、synchronized 详解2.1 基本介绍synchronized 是 JVM 内置的隐式锁，由 JVM 自动管理加锁与释放，无需手动编码，使用简单、安全。 2.2 底层原理 字节码：通过 monitorenter/monitorexit 指令实现 运行时：依赖对象头 Mark Word 与 Monitor（监视器锁） JDK 1.6+ 优化：偏向锁 → 轻量级锁 → 重量级锁 自动升级 2.3 三种使用方式// 1. 修饰实例方法（锁当前对象 this） public synchronized void method() { // 临界区 } // 2. 修饰静态方法（锁当前类 C...
2026-04-20
拒绝策略的实现思路
自定义线程池：拒绝策略的实现思路在手写线程池的过程中，拒绝策略是保障线程池稳定运行的关键兜底机制。它解决了任务过载时的处理问题，本文从设计初衷、核心思想到代码实现，完整梳理拒绝策略的设计与落地思路。 一、设计初衷：为什么需要拒绝策略？线程池在运行时存在两个硬性限制： 核心线程数量固定，不能无限制创建新线程 阻塞队列容量有限，不能无限缓存待执行任务 当新任务提交时，若出现 核心线程已满 + 阻塞队列已满 的情况，任务既无法立即执行，也无法暂存队列。为了避免程序阻塞、任务丢失或系统资源耗尽，必须提供一套灵活的兜底处理方案，这便是拒绝策略的设计意义。 二、核心设计思想拒绝策略采用 策略模式 进行设计，遵循两个核心原则： 职责分离，解耦实现 线程池：只负责判断任务是否达到拒绝条件 阻塞队列：只负责判断自身容量是否已满 拒绝逻辑：由外部自定义，不硬编码在线程池内部 灵活可扩展切换或新增拒绝策略时，无需修改线程池与队列源码，只需替换外部实现逻辑即可。 这套设计思路，与 JDK 原生 ThreadPoolExecutor 的拒绝策略设计完全一致，理解后可以无缝对接原生线程池学习。...