首页 > 数据库 >Redis如何使用Redisson加锁保障并发安全

Redis如何使用Redisson加锁保障并发安全

来源：互联网 2026-05-01 12:16:17

在分布式锁的选择上，应优先考虑 tryLock()，因为它支持超时控制，能有效避免线程无限等待；而 lock() 方法缺乏超时机制，容易导致线程卡死。此外，使用 Redisson 锁时，必须配合数据库的条件更新作为兜底方案，这是因为 Redis 主从异步复制机制存在锁失效的风险。 lock() 和

在分布式锁的选择上，应优先考虑 tryLock()，因为它支持超时控制，能有效避免线程无限等待；而 lock() 方法缺乏超时机制，容易导致线程卡死。此外，使用 Redisson 锁时，必须配合数据库的条件更新作为兜底方案，这是因为 Redis 主从异步复制机制存在锁失效的风险。

lock() 和 tryLock() 到底该选哪个？

这是一个经典的选择题。lock() 方法会一直阻塞，直到成功获取锁，它适用于那些能快速执行完毕的临界区任务。但在生产环境中，tryLock() 通常是更安全的选择——它支持超时控制，能够有效规避因网络抖动、Redis 响应延迟或看门狗（watchdog）机制失效而导致的线程无限期等待问题。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

lock() 的风险：由于没有设置超时，一旦 Redis 主节点发生阻塞或客户端与服务器失联，等待锁的线程就可能被永久挂起，连 JVM 都束手无策。
tryLock(long waitTime, long leaseTime, TimeUnit unit) 的参数解析：这里有两个关键时间参数需要区分清楚：waitTime 指的是尝试获取锁时最多愿意等待的时间；leaseTime 则是指成功获取锁后，这把锁自动释放的持有时间（默认值为30秒）。
实际用法推荐：tryLock(3, 10, TimeUnit.SECONDS) —— 这个配置意味着最多等待3秒去争抢锁，一旦抢到，最多持有10秒。这种策略既能防止死锁，又能避免锁被长期占用不释放。

为什么不能只靠 Redisson 加锁，还得在数据库里加条件更新？

核心原因在于 Redis 的主从异步复制模型。在这种架构下，lock() 调用成功并不等同于锁绝对可靠。设想一个场景：主节点成功写入锁信息后突然宕机，而从节点被提升为新的主节点。此时，新的客户端完全有可能对同一个 key 再次加锁成功。这并非 Redisson 的缺陷，而是 Redis 作为 AP 系统（保证可用性和分区容错性）的天然限制。

兜底方案：所有关键业务操作，例如扣减库存、修改订单状态，都必须搭配数据库的条件更新。典型的 SQL 语句如：UPDATE order SET status = 'CANCELLED' WHERE id = AND status = 'CREATED'。
校验逻辑：执行上述更新后，务必检查影响的行数。如果结果为0，则说明数据状态已经发生变化（例如订单已被处理），此时应直接拒绝当前操作，而不是依赖 Redis 锁的结果。
角色定位：可以这样理解两者的关系——Redisson 锁是提升并发性能的“快车道”，而数据库条件更新则是保障数据最终一致性的“红绿灯”。前者负责提效，后者负责兜底。

watchdog 自动续期失效的常见原因

Redisson 默认启用的 watchdog（看门狗）机制是个好帮手，它会每隔10秒检查持有锁的线程是否存活，并自动延长锁的有效期。但这个机制并非万无一失，在以下几种情况下可能失效：

线程被中断：如果持有锁的线程被 interrupt() 方法中断，watchdog 会停止续期工作，导致锁到期后自动释放。因此，必须确保临界区内的代码执行不会被意外中断。
显式指定了租约时间：当使用 tryLock(leaseTime > 0) 这种形式（即显式传入一个正的 leaseTime 参数）时，watchdog 机制就不会启动。如果想启用自动续期，leaseTime 参数必须传递 -1 或不传（底层会使用默认的 internalLockLeaseTime 值）。
跨线程操作：在 Spring Boot 等框架中，如果在异步方法（标记了 @Async）中使用锁，锁对象可能会因为跨线程而丢失上下文，导致 watchdog 无法定位到原始的持有线程。因此，锁的获取和释放必须在同一个线程内完成。

读写分离场景下，Redisson 锁操作真的安全吗？

答案是安全的，但有一个至关重要的前提：必须严格区分“读取业务数据”和“读取锁状态”这两件事。

锁操作的路由机制：lock()、unlock()、isLocked() 等所有与锁状态相关的操作，Redisson 都会通过 Lua 脚本强制路由到主节点执行，从节点完全不参与锁逻辑。这一点是安全的。
业务数据的读取风险：问题往往出在业务代码本身。如果在成功加锁后，你的业务逻辑却从从节点去读取数据（比如查询库存），那么很可能读到的是尚未同步的旧值。因此，临界区内的所有数据读写操作，都必须统一走主节点。
如何验证：一个简单的验证方法是抓取网络包或查看日志，确认 Redisson 发出的命令是否都指向了主节点地址。不要被配置中的 readMode = SLA VE 所迷惑，这个设置通常只影响 RMap、RList 这类数据结构的读取，对锁操作的路由逻辑没有影响。