WangQuan's Blog

Appearance

Redisson 详解 ​

很多人第一次听到 Redisson，容易把它简单理解成：一个 Redis 客户端。

这个说法不算错，但还是太薄。

实际写项目时，更多是这样，Redisson 是：一个基于 Redis 的 Java 客户端框架，它不只是负责执行 Redis 命令，还把很多常见的分布式能力封装成了更接近 Java 并发工具的 API。

这篇文章重点讲 5 个问题：

  1. Redisson 到底是什么
  2. 它解决什么问题
  3. 它和 Jedis、Lettuce 的区别是什么
  4. 它的分布式锁为什么更常被直接拿来用
  5. 它适合什么场景，又不适合什么场景

1. Redisson 到底是什么 ​

Redisson 可以看成 运行在 Java 应用里的一个 Redis 客户端框架。

这里有两个关键词要分开看。

1.1 它是“Redis 客户端” ​

这说明：

  1. 它自己不是 Redis 服务
  2. 它需要连接真正的 Redis 实例
  3. 底层能力仍然建立在 Redis 之上

也就是说：没有 Redis 服务，Redisson 也无从工作。

1.2 它是“更高层的客户端框架” ​

这说明它不只是帮你发 GET、SET、HGETALL 这种基础命令。

它更重要的价值在于：把很多分布式场景里常见的能力，包装成更符合 Java 使用习惯的对象和接口。

例如：

  1. 分布式锁
  2. 分布式读写锁
  3. 分布式限流器
  4. 延迟队列
  5. 分布式集合
  6. 分布式同步器

所以更稳妥的理解是：Redisson 不是“另一个 Redis”，而是“基于 Redis 的 Java 分布式工具箱”。

2. Redisson 主要解决什么问题 ​

如果只做最基础的缓存读写，很多时候你直接用普通 Redis 客户端就够了。

Redisson 真正想解决的，通常不是：我怎么发一条 Redis 命令。

而是：我怎么在 Java 工程里更省心地使用 Redis 提供的分布式能力。

它主要在解决下面这些问题：

  1. 分布式锁细节太多，容易自己写错
  2. 用 Redis 做队列、同步器、集合时，底层命令不好直接组织
  3. 业务开发更希望拿到 Java 风格 API，而不是到处手写 Lua 和底层命令
  4. 分布式场景的边界处理很烦，例如续期、重入、超时、安全释放

所以 Redisson 的价值不只是“方便”，更是：把很多本来容易写漏边界的 Redis 分布式逻辑做成现成能力。

3. Redisson 和 Jedis、Lettuce 到底有什么区别 ​

这三个名字经常一起出现，但它们定位并不完全一样。

3.1 Jedis ​

Jedis 可以理解成 更偏直接操作 Redis 命令的 Java 客户端。

它解决的是 Java 程序如何连接 Redis，并执行常见 Redis 命令。

它的特点通常是：

  1. 上手直观
  2. 命令感更强
  3. 更接近原始 Redis 操作方式

3.2 Lettuce ​

Lettuce 也是常见 Redis Java 客户端。

它相比更早期客户端，一个重要特点是：更现代，支持同步、异步和响应式调用模型。

它解决的是 在更现代的 Java 工程里，如何以线程安全、异步化的方式操作 Redis。

3.3 Redisson ​

Redisson 和前两者的关键差异在于：它不只是一个“命令客户端”，而是一个“分布式对象与分布式工具客户端”。

把这层区别摊开看：

  1. Jedis / Lettuce 更像“你自己发 Redis 命令”
  2. Redisson 更像“它把很多常用分布式能力先封装成 Java API”

例如分布式锁：

如果用 Jedis 或 Lettuce，你往往要自己处理：

  1. set nx ex
  2. 唯一值
  3. 解锁 Lua
  4. 续期
  5. 重入

而用 Redisson 时，通常可以直接写成：

java
RLock lock = redissonClient.getLock("order:lock");
lock.lock();
try {
    // 业务逻辑
} finally {
    lock.unlock();
}

所以可以把三者关系压缩成一句话：

Jedis / Lettuce 更偏 Redis 命令操作；Redisson 更偏 Redis 分布式能力封装。

4. 为什么很多项目更愿意用 Redisson 做分布式锁 ​

因为分布式锁真正难的地方，从来不是：怎么在 Redis 里放一个键。

真正难的是：在超时、重试、并发争抢和异常退出时，怎么把锁的边界处理完整。

例如你自己手写 Redis 锁时，最容易漏掉这些问题：

  1. 没设置过期时间，导致死锁
  2. 锁过期后，别的线程拿到了新锁，你却把它删掉了
  3. 业务执行太久，锁提前过期
  4. 线程重入时处理不对
  5. 阻塞等待、超时等待这些能力都要自己补

Redisson 的价值就在于：它把这些常见锁能力做成了更稳定的默认实现。

5. Redisson 分布式锁底层大致怎么实现 ​

先说结论：

Redisson 的分布式锁底层依然是基于 Redis 键值和 Lua 脚本，只不过它把很多工程细节封装起来了。

可以按这条主线理解。

5.1 加锁 ​

加锁时，核心目标是：只有一个线程或实例能成功拿到锁。

底层通常会做类似下面的事情：

  1. 用原子命令尝试设置锁键
  2. 给锁写入唯一标识
  3. 同时设置过期时间

你可以把它理解成和下面这个思路接近：

text
SET lock_key unique_value NX PX 30000

这里每个部分都在解决具体问题：

  1. NX：只有锁不存在时才设置成功
  2. PX 30000：给锁设置过期时间，避免死锁
  3. unique_value：标记这把锁到底是谁拿到的

5.2 解锁 ​

解锁真正要解决的是：只能删掉自己持有的锁，不能误删别人的锁。

所以 Redisson 不会简单粗暴地直接 DEL lock_key。

更安全的思路通常是：

  1. 先校验锁里的唯一值是不是自己
  2. 只有一致时才删除
  3. 整个过程放进 Lua 脚本里原子执行

这样做是为了避免这种情况：

  1. 线程 A 的锁过期了
  2. 线程 B 拿到了新锁
  3. 线程 A 业务刚执行完，直接删键
  4. 结果把线程 B 的锁删掉了

5.3 续期 ​

这是 Redisson 很有代表性的一个能力。

如果业务执行时间比较长，固定过期时间就可能不够。

例如：

  1. 锁默认过期 30 秒
  2. 业务执行了 45 秒
  3. 锁在第 30 秒提前失效
  4. 别的线程就可能抢到锁

这时 Redisson 会通过看门狗机制自动续期。

它的目标是：只要持锁线程还活着、业务还没结束，就把锁续上，避免锁过早过期。

6. 什么是看门狗机制 ​

看门狗 可以理解成 Redisson 在后台帮你定期检查锁是否还该继续持有，如果该继续，就自动延长过期时间。

它解决的是 业务执行时间不确定时，固定锁超时时间容易设得过短或过长。

如果设得太短，锁会提前失效。 如果设得太长，异常退出时又会让别的线程等太久。

看门狗的好处就在于：

  1. 默认先给一个过期时间
  2. 如果业务还没结束，就自动往后续
  3. 一旦线程真正释放锁或进程异常结束，续期也会停掉

所以它本质上是在平衡两件事：

  1. 不要让锁过早失效
  2. 也不要让异常锁无限挂死

7. Redisson 里除了锁，还有哪些常见能力 ​

很多人知道 Redisson，往往是从分布式锁开始的，但它不只有锁。

比较常见的能力还包括：

  1. RMap、RSet、RList 这类分布式集合
  2. RBlockingQueue、延迟队列这类分布式队列
  3. RSemaphore、RCountDownLatch 这类分布式同步器
  4. RRateLimiter 这类限流能力
  5. 发布订阅与一些对象封装

这也是为什么它更像“分布式工具箱”，而不只是一个普通命令客户端。

不过要注意：它们本质上仍然是建立在 Redis 语义上的封装，不等于真的拥有 JVM 本地对象那样的零成本行为。

8. Redisson 适合什么场景 ​

比较适合的场景通常包括：

  1. 需要比较稳妥的分布式锁
  2. 不想自己手写 Redis 锁和续期逻辑
  3. 需要 Redis 风格的分布式队列、同步器、集合
  4. 业务主要是 Java 技术栈，希望直接使用 Java 风格 API

如果系统已经明确大量依赖 Redis 做分布式协调，Redisson 往往会比自己从底层命令拼装更省心。

9. Redisson 不适合什么场景 ​

这部分同样重要。

Redisson 很有用，但它不是所有场景都必须上。

不太适合或不一定划算的情况通常包括：

  1. 你只是做非常简单的缓存读写
  2. 项目只需要少量基础 Redis 命令
  3. 团队并不需要锁、同步器、延迟队列这些高级封装
  4. 系统对 Redis 之外的一致性收敛没有额外设计，却误以为用了 Redisson 就万事大吉

这里真正该看清的是：

Redisson 解决的是“如何更方便使用 Redis 分布式能力”，不是“替代数据库事务或解决所有跨系统一致性问题”。

10. 最容易混淆的几个点 ​

10.1 Redisson 不是 Redis 服务 ​

它是客户端框架，不是 Redis 服务器本身。

10.2 Redisson 不是数据库事务 ​

它能帮你做锁、同步器、协调，但它不等于关系型数据库里的事务机制。

10.3 Redisson 能降低出错概率，但不能替你兜底所有业务边界 ​

例如：

  1. 库存最终一致性
  2. 订单补偿
  3. 消息重复消费
  4. 跨系统状态收敛

这些问题依然要靠业务设计、数据库约束、消息幂等和补偿机制一起解决。

10.4 有了 Redisson，也不代表锁就一定该用 ​

真正要先问的是：这个场景到底需不需要分布式锁，还是应该用幂等、乐观更新、消息串行化等方式解决。

11. 一份更实用的判断清单 ​

如果你在考虑要不要用 Redisson，可以优先检查这些问题：

  1. 项目是否主要是 Java 技术栈
  2. 是否确实需要分布式锁、同步器、延迟队列等能力
  3. 团队是否不想长期维护底层 Redis 锁细节
  4. 是否能接受 Redis 作为这些分布式能力的底层依赖
  5. 是否已经清楚区分“协调能力”和“最终一致性能力”

12. 总结 ​

把 Redisson 压缩成最核心的几句话，就是：

  1. Redisson 是基于 Redis 的 Java 客户端框架，但更贴近它定位的说法是，它是一个分布式工具客户端
  2. 它最大的价值不是执行基础命令，而是把分布式锁、同步器、队列、集合等能力封装成更好用的 Java API
  3. 它和 Jedis、Lettuce 的关键差异，在于前两者更偏命令客户端，Redisson 更偏分布式能力封装
  4. 它的分布式锁底层依然依赖 Redis 键、过期时间和 Lua，但通过唯一标识、原子解锁和看门狗续期把边界处理得更完整
  5. 它适合 Java 项目里常见的 Redis 分布式协调场景，但不能替代数据库事务和跨系统一致性设计

基于 VitePress 构建的个人技术笔记。

Copyright © 2026 WangQuan's Blog