[060][调度模块]Redisson vs Redis 原生锁：两种分布式锁实现深度对比

[060][调度模块]Redisson vs Redis 原生锁：两种分布式锁实现深度对比

本文章代码: gitee , gitcode , github

摘要

同一个调度框架内同时提供了基于 Redis 原生命令的锁服务和基于 Redisson 的锁服务。本文从功能特性、使用复杂度、可靠性角度对比两者的差异，并给出选型建议。

1. 锁获取方式

框架	非阻塞尝试	阻塞等待	可重入
RedisLockService	❌（仅 try once）	❌	❌
RedissonReentrantLockService	✅ tryLock(waitTime)	❌	✅
RedissonBlockLockService	❌	✅ lock() 永久阻塞	✅

• Redis 原生锁：SET NX PX 原子操作，仅尝试一次，失败立即返回。适合对延迟敏感且锁竞争不激烈的场景。
• Redisson 可重入锁：支持等待超时，可重入，解决同一线程多次获取锁的死锁问题。
• Redisson 阻塞锁：会一直阻塞直到获取锁，适合必须确保执行的任务（但需警惕死等）。

2. 自动续期机制

• Redis 原生自动续期：框架自己启动 ScheduledThreadPoolExecutor，每隔 5 秒执行 Lua 脚本续期。需要额外管理线程池生命周期，且续期不及时可能导致锁提前释放。
• Redisson 看门狗：内置 netty 定时任务，默认 30 秒检查一次，只要锁还被当前线程持有且任务未完成，自动续期。实现更健壮，无需手动管理。

3. 故障恢复

• Redis 原生：若持有锁的节点宕机，续期线程消失，锁会在原租期后自动释放，相对安全。
• Redisson：同样会过期释放，但看门狗在节点宕机后也会停止，锁最终过期释放。

4. 使用复杂度

• Redis 原生：需要自己管理 RedisTemplate、Lua 脚本、续期线程池，代码量较大但依赖少。
• Redisson：只需注入 RedissonClient，调用 getLock() 即可，API 更友好，但引入额外依赖。

5. 选型建议

场景	推荐方案
轻量应用，不想引入 Redisson	RedisLockService + 固定租期或自动续期
需要可重入、看门狗自动续期	RedissonReentrantLockService
任务必须执行，允许阻塞等待	RedissonBlockLockService（注意设置合理的租期避免死锁）