[060][调度模块]Redisson vs Redis 原生锁：两种分布式锁实现深度对比
摘要
同一个调度框架内同时提供了基于 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（注意设置合理的租期避免死锁） |
