Redisson 分布式对象

• 锁超时导致锁提前释放
• GC 停顿对锁持有的影响
• 看门狗（WatchDog）续期

基于 Redis 的分布式锁存在"锁超时"与"GC 停顿"两个安全性隐患。当客户端持有锁但业务执行超过锁的 TTL 时，锁被 Redis 自动释放，其他客户端便可获得锁，原客户端仍在执行临界区，造成两个客户端同时进入临界区，破坏互斥。GC 停顿（STW）期间，客户端暂停无法续期，也会导致锁过期被释放。Redisson 通过看门狗（WatchDog）缓解：默认锁 watchdog 续期时间内，后台定时任务每 1/3 锁过期时间自动续期，只要客户端进程存活，锁就不会过期。但看门狗无法完全解决 GC 停顿问题——若停顿超过续期周期，锁仍可能过期。因此 Redisson 锁的安全性依赖"锁持有时间不超过 TTL 且续期及时"，对强一致场景需配合 Fencing Token 或采用 etcd/ZK 锁。

看门狗把"业务执行时间"与"锁 TTL"解耦，通过自动续期避免"业务没做完锁先释放"。但 GC 停顿是看门狗也无法完全规避的物理极限，因此 Redisson 锁是"足够好"而非"绝对安全"，对极端安全要求需用带 Fencing 机制或强一致协调器的锁。

• Redisson 的连接池配置
• Netty 的 EventLoop 线程模型
• 命令的异步与响应式处理

Redisson 基于 Netty 构建客户端，使用 Netty 的 EventLoop 线程模型处理网络 IO。Redisson 默认每个 Redis 节点使用一定数量的 EventLoop 线程（默认系统核心数*2），命令通过 Netty 异步发送与回调，避免阻塞业务线程。连接池方面，Redisson 通过 connectionPoolSize 等配置管理连接：主从/哨兵/集群模式下每个节点维护连接池，支持连接池大小、最小空闲、连接超时等参数。命令执行采用异步（Future）与响应式（RxJava/Reactive）风格，客户端线程池与 Netty 线程池配合实现高并发。性能调优要点：合理设置连接池大小（避免过大抢占资源、过小导致排队）、调整 Netty 线程数与网络超时、使用异步 API 减少阻塞等待、批量操作减少 RTT。

Redisson 的 Netty 事件驱动模型天然支持异步高并发，连接池管理 Redis 连接复用。理解"Netty 线程负责 IO、业务线程负责计算"的分工，能让异步 API 真正发挥性能优势，避免阻塞浪费。

• Lua 脚本的原子执行
• EVAL/EVALSHA
• 集群模式的 slot 限制

Redisson 的分布式对象（锁、信号量、队列等）底层通过 Lua 脚本实现复合操作。Redis 的 EVAL 命令保证脚本在服务器端原子执行，脚本执行期间不会插入其他命令，从而保证"检查+操作"的原子性（如判断锁是否持有并删除）。Redisson 通过 Lua 脚本把多个 Redis 命令组合成原子操作，避免竞态。但集群模式下，Redis Cluster 的 key 按 CRC16 哈希到 slot，一个 Lua 脚本中涉及多个 key 时，这些 key 必须位于同一 slot（通过 hash tag {} 实现），否则报错（CROSSSLOT）。因此 Redisson 的复合操作（如锁、信号量）通常只使用单一 key 或通过 hash tag 将相关 key 归入同一 slot，避免跨 slot 的 Lua 脚本。

Lua 原子性是 Redisson 分布式语义正确的根基，slot 限制是集群模式下使用 Lua 的约束。理解"原子性靠 Lua、跨 slot 靠 hash tag"是掌握 Redisson 并发与集群正确性的关键。

• RLock 可重入实现
• 看门狗续期机制
• 锁超时与释放

RLock 是 Redisson 的可重入分布式锁，底层基于 Lua 脚本实现。加锁时，脚本检查锁 key 是否存在：若不存在则通过 hset 设置锁并记录持有者（UUID+线程ID）与计数；若已存在且持有者是当前线程则计数递增（可重入）；否则返回失败。锁的 value 是"持有者标识+计数"的哈希，支持同一线程在同一锁内重复加锁。看门狗续期：默认锁的 leaseTime 为 30 秒，若未显式指定 leaseTime，Redisson 会启动后台看门狗线程，每 10 秒（leaseTime/3）自动续期锁，使锁在持有期间不因超时释放。解锁时脚本递减计数，归零则删除锁。使用注意：显式指定 leaseTime 后看门狗不再续期，需保证业务在 leaseTime 内完成，否则锁过期。

可重入性通过"持有者哈希+计数"实现，看门狗通过定时续期解决"业务执行超时锁提前释放"。理解"可重入=计数、续期=看门狗"能正确使用 RLock 并理解其超时语义。

• RTopic 的 publish/subscribe
• Redis Pub/Sub 的 fire-and-forget
• 消息丢失风险

RTopic 基于 Redis 的 Pub/Sub 实现发布订阅：publisher 通过 publish 向 channel 发消息，subscriber 通过 addListener 订阅 channel 并接收。但 Redis Pub/Sub 是"fire-and-forget"（即发即忘）机制：消息不持久化，只有在订阅者在线时才能收到，中途断线或消息发送时订阅者不在线会丢失，且没有 ACK 与重投机制，无法保证消息可靠送达。因此 RTopic 适合"实时通知、可容忍丢失"的场景（如缓存失效通知、轻量广播），不适合"必须可靠投递"的异步消息。若需要可靠消息，应使用 Redis Stream + RStream（支持持久化、消费者组、ACK）或引入 MQ（Kafka/RocketMQ）。工程上要明确 RTopic 的"尽力而为"边界，避免把关键业务消息建立在不可靠的 Pub/Sub 上。

RTopic 的语义是"推送即完成"，不提供持久化与重投，可靠性边界清晰。理解"Pub/Sub 不可靠、Stream 可靠"能正确选型，避免把关键消息丢失的风险引入系统。

• 分布式对象的 Lua 脚本实现
• 锁的看门狗续期
• 信号量与队列的原子操作

Redisson 的分布式对象（锁、信号量、队列、读写锁等）底层统一基于 Lua 脚本实现原子操作。分布式锁（RLock）用 Lua 脚本完成"检查-设置-计数"与"释放-递减-删除"；信号量（RSemaphore）用 Lua 脚本原子地尝试获取许可（检查可用数并递减）与释放许可（递增）；队列（RQueue/RDeque）用 Lua 脚本原子地完成入队出队。这些 Lua 脚本由 EVAL 执行，保证复合操作原子性。看门狗续期主要作用于带 TTL 的锁（RLock、ReadWriteLock、FairLock 等）：未显式指定 leaseTime 时，后台看门狗定期续期，防止锁超时释放。信号量、队列等无 TTL 语义的对象不依赖看门狗，其一致性由 Lua 脚本的原子性保证。

Redisson 的共性设计是"一切复合操作都走 Lua 脚本 + 原子执行"，看门狗是"带 TTL 的锁"的续期扩展。理解这套统一模式，就能理解各分布式对象的一致性保证与使用边界。

• RTopic 的 API（publish/addListener）
• fire-and-forget 语义
• 消息丢失与不可靠

RTopic 是 Redis Pub/Sub 的 Java 封装，提供 publish（发布消息）和 addListener（订阅并监听）两个核心 API。RTopic 本身不改变 Redis Pub/Sub 的 fire-and-forget 语义：消息通过 publish 发送到 channel，addListener 注册的订阅者通过 Redis 的 SUBSCRIBE 接收，但消息不持久化、无 ACK、无重投，发送时订阅者不在线则丢失。RTopic 与原生 Pub/Sub 的差异主要是"封装"而非"语义"：RTopic 提供类型化消息、异步监听、自动重连、序列化（Codec）等便利，但底层仍是 Pub/Sub 的即时广播。因此，RTopic 适合实时通知、缓存刷新、心跳等可容忍丢失的场景，不适合要求可靠投递的消息场景。

理解 RTopic 的"封装不改语义"是关键：它只是让 Pub/Sub 更好用，不能把不可靠变成可靠。需要可靠消息时，应改用 RStream（Redis Stream）或外部 MQ。

• RMap 分布式哈希
• RBucket 分布式对象
• 缓存一致性

RBucket 是 Redisson 的分布式对象封装，对应 Redis 的单个 key，可存储任意对象（通过 Codec 序列化），提供 get/set 等操作。RMap 是分布式哈希表，对应 Redis 的 Hash，通过 map 的 key-value 操作分布式管理多个字段，支持原子操作（如 putIfAbsent、compute）。与本地缓存结合时，RMap 可配置本地缓存（local cache），将热数据缓存在应用本地内存，同时通过 Redis 的失效通知（Keyspace notifications）或 RMapCache 的本地缓存失效机制保持一致性。RMapCache 支持每个 key 的 TTL 与 LRU 淘汰。一致性取舍：本地缓存提升读性能，但引入"本地与 Redis 之间的短暂不一致"，需设置合适的过期时间或使用失效通知尽量同步。

RBucket/RMap 是分布式对象的基础封装，本地缓存是"性能与一致性"的权衡。RMap 适合分布式共享字段，RMapCache 增加 TTL/淘汰，本地缓存则牺牲一致性换性能。

• RScoredSortedSet 的有序集合
• RDelayedQueue 的延迟消息
• 底层实现（ZSet + 轮询）

RScoredSortedSet 对应 Redis 的 Sorted Set（ZSet），元素带 score 分数，按分数排序，支持按分数范围查询、排名、区间操作，适合排行榜、优先级队列等场景。RDelayedQueue 是 Redisson 的延迟队列：基于 RScoredSortedSet（ZSet）实现，将"到期时间"作为 score，通过后台任务轮询 ZSet 中 score 最小（最早到期）的元素，到期后将其移动到延迟队列，消费者从队列取到即表示延迟到期。RDelayedQueue 常配合 RBlockingQueue 使用，实现"延迟到期的消息/任务"。应用场景：订单超时取消、延迟任务调度、定时重试等。注意延迟队列的可靠性受 Redis 持久化影响，且后台轮询精度有限。

RDelayedQueue 用 ZSet 的 score 表示到期时间，靠轮询头元素实现延迟，是典型的"排序+轮询"方案。相比专门的消息队列，它实现简单但精度与可靠性有限，适合中等规模的延迟场景。

• Redis Stream 的数据结构
• 消费者组（Consumer Group）
• RStream 的 Java API

Redis Stream 是 Redis 5.0 引入的追加式日志数据结构，支持消息持久化、消费者组、ACK 与重投，弥补了 Pub/Sub 不可靠的缺陷。Redisson 的 RStream 封装了 Redis Stream 的 Java API，提供 add（追加消息）、read（读取）、createGroup（创建消费者组）、readGroup（消费者组读取）、ack（确认）、pending（待处理消息）等操作。消费者组允许多个消费者协作消费同一 stream，消息被读取后需显式 ACK，未 ACK 的消息进入 pending 列表，可重投（XCLAIM）给其他消费者，实现"至少一次"的可靠消费。RStream 适合需要可靠消息、离线消费、消费进度管理的场景，比 RTopic 更可靠。

Stream 的"持久化 + 消费者组 + ACK + 重投"提供了接近 MQ 的可靠消息语义。RStream 把这些能力封装为 Java API，是对"Pub/Sub 不可靠"的有力补充，适合业务内的可靠消息。

• RSemaphore 的许可并发控制
• RRateLimiter 的令牌桶限流
• 并发控制 vs 限流

RSemaphore（信号量）用于并发控制：维护一个许可总数，acquire 获取许可（许可数为 0 时阻塞等待），release 释放许可，控制"同时进行的操作数"（并发度），如限制同时访问某资源的线程数。RRateLimiter（限流器）用于速率控制：基于令牌桶算法，维护一个令牌速率（如每秒 N 个），acquire 时消耗令牌，令牌不足则等待或拒绝，控制"单位时间内的请求速率"，如限流每秒最多 N 次调用。差异：信号量限制"并发数"（同时执行数），限流器限制"速率"（单位时间次数）。信号量适合资源并发度控制，限流器适合请求流量控制与防抖。两者可结合：信号量限并发、限流器限速率。

并发控制与限流是两种不同的节流语义：信号量管"多少同时"，限流器管"多快发生"。理解目标（并发数 or 速率）才能正确选择 RSemaphore 或 RRateLimiter。

• RedLock 算法原理
• RedLock 的争议
• 可靠性权衡

RedLock 是 Redisson 提供的多节点分布式锁算法：客户端对 N 个相互独立的 Redis 节点（通常 5 个）依次尝试加锁，只有当"成功加锁的节点数超过 N/2+1"且"总耗时小于锁有效期"时才认为加锁成功，解锁时对全部节点释放。目的在于通过多数节点提高锁的可靠性，避免单节点故障。但 RedLock 存在争议：Martin Kleppmann 指出在 GC 停顿、时钟漂移、网络分区等场景下 RedLock 仍可能失效，无法提供真正的强互斥；而 Redisson 作者（antirez）则辩护其工程可行性。核心争议是"异步分布式系统的锁无法保证绝对安全"，RedLock 相比单节点锁提升了可用性，但未从根本上解决一致性问题。因此对强一致要求，用 etcd/ZK 的锁更可靠。

RedLock 的争议本质是"分布式锁能否在异步系统里做到绝对安全"的哲学之争。工程上 RedLock 比单节点锁更抗单点故障，但仍是"尽力而为"，对绝对安全要求应转向强一致协调器。

• RReadWriteLock 的读写互斥
• 读锁可共享、写锁互斥
• RFairLock 的公平排队

RReadWriteLock 是 Redisson 的分布式读写锁：读锁（readLock）可被多个线程同时持有（共享），写锁（writeLock）需独占。读写锁遵循"读读共享、读写互斥、写写互斥"原则，适合"读多写少"的场景，在保证写一致性的同时提升读并发。底层通过 Lua 脚本记录读锁计数与写锁持有者，判断读写互斥。RFairLock 是公平锁：保证线程按请求顺序获取锁（FIFO），通过 ZSet 记录等待队列，加锁时按序号排序，先到先得，避免"饥饿"。公平锁通过 ZSet + 客户端序号实现，比非公平锁（RLock）多一次排队开销。适用场景：RReadWriteLock 适合读多写少、可接受写时阻塞读的场景；RFairLock 适合需要严格先后顺序的场景。

读写锁利用"读共享"提升读并发，公平锁用"排队"保证顺序。两者都是对 RLock 的语义扩展，适用于不同并发需求，使用时要结合业务读写比例与顺序要求。

• Redisson 的分布式对象封装
• Jedis 的底层客户端定位
• API 风格差异

Redisson 和 Jedis 定位不同：Jedis 是轻量级的底层 Redis 客户端，直接封装 Redis 命令（get/set/hset 等），API 简单贴近 Redis 原生命令，适合需要直接操作 Redis 命令、低层控制、轻量使用的场景，编程式、命令式。Redisson 是高层分布式对象框架，提供分布式锁、信号量、队列、Map、Topic 等抽象对象，自动处理连接池、序列化、Lua 脚本、看门狗等，适合"以分布式对象思维"使用 Redis 的场景（分布式锁、分布式集合、可靠队列），面向对象、声明式。选择上：需要分布式锁/队列/并发原语用 Redisson；只需要简单 GET/SET 或业务自定义命令用 Jedis（或 Lettuce）。两者也可共存，Redisson 内部也基于 Netty。

定位差异是"命令级客户端 vs 对象级框架"。Jedis 给底层命令，Redisson 给分布式抽象，选择取决于"用 Redis 的目的"——是命令操作还是分布式能力。

• RMap/RMapCache 的分布式缓存
• 本地缓存机制
• 一致性与失效

RMap 是分布式哈希，RMapCache 在 RMap 基础上支持每 key 的 TTL 与 LRU 淘汰，是分布式缓存的核心。为提升读性能，Redisson 支持为 RMapCache 配置本地缓存（local cache）：热数据缓存在应用本地内存，读操作优先命中本地，通过 Redis 的失效通知（Keyspace notifications）或本地缓存失效机制（LRU/TTL）保持一致性。但本地缓存与 Redis 之间存在短暂不一致窗口：本地缓存失效后需重新从 Redis 拉取，且多实例间本地缓存不同步。解决策略：设置合理的本地缓存 TTL，开启失效通知及时刷新，或通过 RMapCache 的 update 事件广播其他实例失效本地缓存。适用读多写少、容忍短暂不一致的场景。

分布式缓存的一致性本质是"本地副本与 Redis 主数据"的同步问题。TTL 与失效通知是两种一致性逼近手段，工程上要权衡"性能提升"与"短暂不一致"的接受度，避免读到过期数据。

• 令牌桶算法
• 速率与容量配置
• Lua 脚本实现原子限流

RRateLimiter 是基于令牌桶算法的分布式限流器。令牌桶模型：桶的容量为 burst（突发容量），令牌按固定速率（rate）每秒补充，请求到来时需从桶中获取令牌，令牌不足则等待或拒绝。RRateLimiter 通过 setRate 设置速率（如每秒 5 次），通过 acquire 获取许可，底层用 Lua 脚本原子地计算"应补充的令牌数、当前可用令牌、是否足够"并更新桶状态，保证分布式环境下限流判断的原子性与一致性。令牌桶比固定窗口更平滑，允许突发。RRateLimiter 适合分布式 API 限流、接口防刷等速率控制。相比本地 Guava RateLimiter，Redisson 的限流是跨实例共享的，真正做到全局限流。

令牌桶用"补充速率 + 桶容量"实现"平滑限流 + 允许突发"，Lua 脚本保证分布式原子性。RRateLimiter 的价值在于把限流从单机提升到全局，适合多实例服务的统一限流。

• RFairLock 的 FIFO 排队
• RReadWriteLock 的读写互斥
• 底层 Lua 与 ZSet

RFairLock（公平锁）通过 ZSet 实现 FIFO 排队：每个加锁的客户端在 ZSet 中记录一个序号（score），加锁时按序号最小者优先，只有序号最小的等待者能获得锁，保证"先到先得"，避免饥饿。读写锁（RReadWriteLock）实现读共享、写互斥：读锁可被多个线程同时持有（读锁计数），写锁需独占（无读锁且无写锁时才能获取）。底层 Lua 脚本判断：尝试获取写锁时，若存在读锁或写锁则失败；获取读锁时，若存在写锁则失败，否则递增读锁计数。排队与互斥结合：公平锁解决"顺序"，读写锁解决"读写并发"。公平锁用 ZSet 排队，读写锁用计数+标记实现互斥。

公平锁的排队依赖 ZSet 序号，读写锁的互斥依赖计数与标记。两者是 Redisson 锁的语义扩展，分别应对"顺序敏感"与"读写并发"的需求。

• Codec 的作用
• 各序列化方案（Jackson/Kryo/Fst）
• 性能与兼容性

Codec 是 Redisson 的序列化器，负责把 Java 对象序列化为二进制存储到 Redis（RBucket、RMap、Topic 等），决定分布式对象的数据格式与性能。常见 Codec：Jackson（JSON 序列化，可读性好、跨语言兼容、性能中等）、Kryo（二进制序列化，性能高、体积小、但需注册类、兼容性依赖类结构）、Fst（快速二进制序列化，性能高体积小）、Protobuf（高效紧凑）。影响：性能上二进制（Kryo/Fst）比 JSON（Jackson）快、体积小，适合高吞吐场景；兼容性上 JSON 跨语言、便于调试，二进制对类结构变更敏感。选型建议：对性能要求高、纯 Java 场景用 Kryo/Fst；需要跨语言、可读可调试用 Jackson；需注意序列化版本兼容与类结构稳定，避免反序列化失败。

Codec 是"性能与可读性"的权衡。二进制序列化快但脆弱，JSON 慢但通用。选型要结合性能要求、跨语言需求与类演进的稳定性，并在类结构变化时处理兼容性。