Redisson和Redis实现分布式锁的对比

最新推荐文章于 2025-09-01 19:49:43 发布

原创最新推荐文章于 2025-09-01 19:49:43 发布 · 648 阅读

7 ·

CC 4.0 BY-SA版权

文章标签：

#redis #分布式 #数据库 #Redisson #java

八股文专栏收录该内容

3 篇文章

订阅专栏

一、原子性保障

特性

SETNX 实现

Redisson 实现

加锁操作

需组合 SETNX

+ EXPIRE

命令，需通过 Lua 脚本保证原子性（否则存在竞态条件）。

内置原子性 Lua 脚本，封装加锁、续期、释放锁的全流程，避免非原子操作风险。

锁释放

需手动校验锁标识（如 UUID），否则可能误删其他线程的锁。

自动校验锁持有者身份，仅允许持有者释放锁，避免误删。

示例对比：

SETNX 手动实现：





// 非原子操作，需分步执行
String uuid = UUID.randomUUID().toString();
jedis.setnx(lockKey, uuid);  // 加锁
jedis.expire(lockKey, 30);   // 设置超时（非原子）

Redisson 实现：





RLock lock = redisson.getLock(lockKey);
lock.lock();  // 原子性操作，内置 Lua 脚本

二、自动续期（看门狗机制）

特性	SETNX 实现	Redisson 实现
续期逻辑	需手动实现后台线程定期续期，代码复杂度高，易遗漏。	内置看门狗线程，自动续期（默认 30 秒续期至 30 秒），动态调整续期间隔。
适用场景	短时操作（如秒杀库存），长事务需自行优化。	长事务（>30 秒）场景，自动续期保障锁有效性。

原理：
Redisson 通过后台线程定期检查锁的剩余存活时间，若小于阈值（如 10 秒），则通过 EXPIRE 命令续期，避免业务未完成导致锁提前失效。

三、可重入性支持

特性	SETNX 实现	Redisson 实现
可重入性	需自行维护线程标识和计数器，实现复杂。	默认支持可重入锁，通过 Hash 结构记录线程 ID 和重入次数，支持递归调用。
代码复杂度	需手动处理重入逻辑，易出错。	透明化处理，开发者无需关注底层细节。

数据结构对比：

SETNX：需自行维护类似 lockKey -> {threadId: count} 的 Hash 结构。
Redisson：自动通过 Lua 脚本管理 Hash 结构，重入时直接增加计数器。

四、高可用与容灾

特性	SETNX 实现	Redisson 实现
单点故障	单节点 Redis 存在单点故障风险。	支持 RedLock 算法（多节点集群）和哨兵模式，提升容灾能力。
集群支持	需自行实现多节点锁同步（如 RedLock），代码复杂度高。	原生支持 RedLock 和哨兵模式，简化集群部署。

RedLock 原理：
在多个独立 Redis 实例上尝试加锁，需超过半数节点成功才视为加锁成功，避免单点故障。

五、开发体验与功能扩展

特性

SETNX 实现

Redisson 实现

API 丰富度

需手动实现阻塞锁、尝试锁、公平锁等逻辑，开发成本高。

提供 RLock

接口和丰富 API（如 tryLock

、lockInterruptibly

、公平锁）。

功能扩展

需自行实现联锁（MultiLock）、读写锁等复杂场景。

原生支持联锁、红锁（RedLock）、公平锁等企业级功能。

示例：
Redisson 的公平锁通过有序集合（Sorted Set）维护等待队列，按请求顺序分配锁，避免饥饿现象。

六、性能对比

场景	SETNX 实现	Redisson 实现
单节点模式	TPS 约 35,000 次/秒（轻量级操作）。	TPS 约 28,000 次/秒（因 Hash 操作和后台线程开销）。
集群模式	需自行实现高可用逻辑，性能波动大。	原生支持集群模式，动态扩缩容，性能更稳定。