redission原理解读

作者：袖梨 2026-06-06

解析Redisson核心原理与设计思想

Redisson 是 Redis 官方推荐的 Java 分布式协调组件，它将 Redis 的丰富数据结构扩展为 Java 熟悉的并发对象（如分布式锁、Map、队列、信号量），并提供了完整的集群、哨兵、主从支持。本文将深入剖析 Redisson 的架构基石、分布式锁的完整链路、看门狗机制、异步编程模型以及如何通过 Lua 保证原子性，以“好看懂、能落地”的方式展示其原理。

放一张核心加锁逻辑总图

1. 架构全景：异步 · 原子 · 高可用

Redisson 的底层通信完全基于 Netty，所有 Redis 命令执行都是异步非阻塞的，通过 RFuture 抽象将回调转换为 Java 的 CompletionStage 或直接的异步接口。这种设计让它天然支持高吞吐。

整体架构可概括为三个核心支柱：

异步引擎：Netty + 线程池 + 连接池，命令执行零阻塞，支持发布/订阅事件流。
原子脚本：所有复合操作（如加锁、续期、解锁）均通过 Lua 脚本 在 Redis 服务端一次性执行，杜绝并发竞争。
对象映射：将 Redis 的 String、Hash、List、ZSet 等数据结构，封装为 Java 友好的 RMap、RLock、RQueue 等接口，提供本地缓存、监听回调等增强。

2. 分布式锁的完整解剖

RLock 是 Redisson 中最广泛使用的特性，其实现远非简单的 SETNX 可比，它要解决可重入、自动续期、非阻塞等待、集群安全四大难题。

2.1 加锁：一个 Lua 脚本定乾坤

加锁的核心是一段精心设计的 Lua 脚本（简化版如下）：

-- KEYS[1] 锁名 ， ARGV[1] 客户端标识(UUID:线程ID) ， ARGV[2] 锁租约时间(ms)
if (redis.call('exists', KEYS[1]) == 0) then
    redis.call('hincrby', KEYS[1], ARGV[1], 1);
    redis.call('pexpire', KEYS[1], ARGV[2]);
    return nil;
end;
if (redis.call('hexists', KEYS[1], ARGV[1]) == 1) then
    redis.call('hincrby', KEYS[1], ARGV[1], 1);
    redis.call('pexpire', KEYS[1], ARGV[2]);
    return nil;
end;
return redis.call('pttl', KEYS[1]);

原理拆解：

锁在 Redis 中存储为一个 Hash，键为锁名，字段为 客户端UUID:线程ID，值为重入次数。
首次加锁：Hash 不存在，直接创建并设置租约时间（默认30秒）。
重入加锁：判断当前客户端是否已持有锁（hexists），是则重入次数+1并刷新租约。
如果锁被其他客户端持有，返回剩余过期时间（pttl），客户端据此进行等待。

这种方式天然支持了可重入和强一致性——由 Redis 单线程串行化执行脚本。

2.2 看门狗：锁的自动续命

如果业务执行时间超过锁的租约（30秒），锁会被自动释放，造成并发问题。Redisson 提供了经典的 Watch Dog 机制：

加锁成功后，客户端会启动一个 后台定时任务（基于 Netty 的 HashedWheelTimer 时间轮），每隔 租约/3 （默认 10 秒）触发一次续期。

续期执行一条简单的 Lua 脚本：

if (redis.call('hexists', KEYS[1], ARGV[1]) == 1) then
    redis.call('pexpire', KEYS[1], ARGV[2]);
    return 1;
end;
return 0;

该脚本判断锁是否仍被同一客户端持有，是则将过期时间重置为租约值。

当锁被主动释放或客户端宕机，续期任务会因锁不存在而自动失效，不会无谓续期。

2.3 解锁与等待唤醒：Pub/Sub 而非轮询

解锁同样使用 Lua 脚本保证原子性：

if (redis.call('hexists', KEYS[1], ARGV[1]) == 0) then return nil; end;
local count = redis.call('hincrby', KEYS[1], ARGV[1], -1);
if (count > 0) then
    redis.call('pexpire', KEYS[1], ARGV[2]);
    return 0;
else
    redis.call('del', KEYS[1]);
    redis.call('publish', KEYS[2], ARGV[3]);  -- 通知等待线程
    return 1;
end;