聊一个在分布式系统里绕不开的话题分布式锁。很多团队最初都会选择用 Redis 的 SETNX 指令自己封装一个锁理由很简单——快、简单、不引入额外依赖。但等我真正在一个订单支付项目里踩过几次锁失效的坑之后我的结论是如果是跨节点的业务并发控制直接用 Redisson 的分布式锁比自己用 SETNX 拼运气靠谱得多。这篇文章不聊空泛的概念就聊 Redisson 在分布式锁里到底做了什么、代码怎么写、参数怎么调、踩过的坑怎么填。适合正在做微服务改造、需要控制并发访问共享资源的团队参考也适合打算自己封装 Redis 锁但还没动手的同学先看看省得走弯路。1. 为什么不用 SETNX 硬写一个分布式锁1.1 原生命令的四大隐患先说清楚我不是全盘否定 SETNX。在单点 Redis、业务锁持有时间极短、并发量有限的场景里SETNX 加过期时间的确能跑。但真实的微服务环境通常不是这样。第一个隐患是锁没法自动续期。假设你用SET key value NX PX 30000加锁业务执行时间超过 30 秒锁自己就释放了。这时候第二个请求拿到锁进来两个节点在同时处理同一笔订单数据的一致性直接破功。第二个隐患是解锁可能误删别人的锁。线程 A 持锁超过 30 秒锁自动过期。线程 B 加锁成功开始处理业务。结果 A 终于执行完了它执行 DEL 命令把锁删掉——注意它删的是 B 的锁。这个问题的根源在于原生 SETNX 加的锁没有“持有者身份”的概念谁都能删。第三个隐患是可重入性。同一个线程在递归调用或者同一个方法里再次获取同一把锁时SETNX 会直接返回失败因为 key 已经存在了。这就导致同一个业务链路里如果方法 A 内部又调用了一个同样需要加锁的方法 B直接死锁。很多团队在压测时才发现这个问题然后方案是引入 ThreadLocal 计数自己维护重入次数代码越来越复杂。第四个隐患是主从切换导致的锁丢失。比如锁的数据写在主节点上还没有同步到从节点主节点挂了。哨兵把从节点提升为主节点这个从节点上没有原来的锁数据新来的线程就能拿到锁。原来的持有者还在跑两个节点同时进临界区锁就形同虚设。这个隐患在单机 SETNX 方案里几乎是无法根治的。1.2 Redisson 为什么能把这些坑填上Redisson 不是一个简单的 Redis 客户端它把分布式锁实现成了一个完整的高可用组件。它的核心设计思路是把锁的状态、持有者信息、过期时间、重入计数都维护在一个 Redis Hash 结构里而不是单纯靠一个 String Key。这样它可以在一次 Lua 脚本执行里完成复杂的判断和操作保证原子性。它的看门狗机制Watchdog会默认帮你把锁的持有时间续期。客户端加锁成功后Redisson 会启动一个后台定时任务在锁的剩余时间快要到期时自动续期。这样就解决了业务执行时间超过锁超时时间的问题。它还在 Hash 结构里存了线程标识解锁时先用 Lua 脚本校验“当前线程是否是锁的持有者”是才删除不是就直接返回不会误删别人的锁。重入功能也是内置的。同一个线程重复获取同一把锁时Hash 里的计数加一释放锁时计数减一减到零才真正删除 key。整个过程对业务代码完全透明。市面上大部分基于 SETNX 的手写方案本质上都是在重新造 Redisson 已经造好的轮子而且往往造得还没它稳。1.3 Redisson 到底锁住了什么很多人第一次用 Redisson 时有个误区以为锁住了某个方法或者某段代码。实际上Redisson 锁的是一段业务操作的唯一标识。比如在支付场景里锁的 Key 应该是订单号lock:order:123456而不是一个全局固定的myLock。锁粒度控制在实际项目中非常关键如果所有订单都用同一把锁那整个系统的并发能力会被锁限制成串行。Redisson 加锁时会在 Redis 里创建一个 Hash 结构。这个 Hash 里存的是锁持有者的信息里面包含线程 ID 和重入计数。默认情况下锁的持有者是“客户端 ID 线程 ID”的组合用来区分不同节点上的不同线程。理解了这个结构你就能理解为什么 Redisson 能做可重入、能防误删因为这些信息都是显式存在 Redis 里的。锁粒度设计时我会优先考虑“业务对象维度”。比如商品减库存用lock:stock:skuId订单支付用lock:pay:orderId用户积分变更用lock:points:userId。这种维度能天然分散锁竞争提升吞吐。如果锁的 Key 设计得比业务对象还粗就会出现大量线程等同一把锁的局面排查问题时也很难定位是哪一类业务导致的锁冲突。2. Redisson 分布式锁的核心原理拆解2.1 看门狗机制到底在守护什么看门狗是 Redisson 分布式锁最常被提到的机制但真正理解它的人不多。它解决的核心问题是锁的超时时间不好估。给锁设置太短的过期时间业务还没跑完锁就没了设置太长节点宕机后锁迟迟不释放后面的请求全堵在那里。Redisson 的默认策略是如果加锁时没有手动指定锁的持有时间leaseTime那么 Redisson 会使用默认的 30 秒持有时间并启动一个看门狗定时任务。这个任务会每 10 秒执行一次持有时间的三分之一如果锁还在、还是当前线程持有就把锁的过期时间重新设置为 30 秒。只要业务线程还活着、还在持锁锁就永远不会因为超时被自动释放。要注意的是如果你在代码里手动传入了 leaseTime比如lock.lock(10, TimeUnit.SECONDS)看门狗就不会启动。此时锁会在 10 秒后强制过期无论业务是否执行完成。这是一个非常容易踩的坑很多人手动设置了时长之后就以为高枕无忧结果业务一慢就出问题。2.2 可重入的实现细节可重入从使用上看很简单就是一个线程能反复加同一把锁但底层是靠 Hash 结构实现的。假设线程 A 获取锁lock:order:123Redis 里就会有一个 Hash字段是 A 的线程标识值是 1。这个线程再次获取同一把锁时Redisson 的 Lua 脚本会检查线程标识是否一致一致就把值加一变成 2。释放锁的时候也是同样的逻辑。每次 unlock 都会让计数减一只有当计数减到零时才会真正删除这个 Hash Key。这意味着如果你在业务里嵌套加锁必须保证每层都执行 unlock否则锁永远释放不了。我在代码审查时经常看到有人写出lock.lock()和lock.unlock()数量对不上的代码这种 Bug 在并发压测时才会暴露排查成本非常高。重入计数还有一个作用它能帮你判断当前代码是否存在重复加锁。如果计数异常飙升那说明代码逻辑里可能有多余的加锁调用值得去排查。我习惯在关键业务里把锁的获取次数打印到日志里平时不显眼但出问题时能省很多时间。2.3 解锁流程与 Lua 脚本的原子性Redisson 加锁和解锁都不是简单的 SET 和 DEL而是通过 Lua 脚本执行。比如解锁脚本的核心逻辑是先判断 Hash 里是否存在当前线程的字段不存在说明锁已经过期或者被其他线程持有直接返回存在则将计数减一如果减一后计数为零删除整个 Key并通过 Redis 的发布订阅机制通知其他等待该锁的线程锁已经释放了可以重新竞争了。这个“判断持有者 删除”的过程必须保证原子性。如果拆成两步中间就可能插入其他命令导致误删。Lua 脚本在 Redis 里是原子执行的整个过程不会被其他客户端命令打断。这也是我坚决反对手写 SETNX 锁的原因之一——很多手写方案在“解锁前校验持有者”这一步都是先 GET 再 DEL中间的时间窗足以酿成事故。等待队列同样值得关注。当多个线程同时争抢一把锁时未获得锁的线程不会死等而是会订阅一个 channel进入阻塞状态。锁被释放后持有者发布一条消息等待线程被唤醒、重新尝试加锁。这个机制避免了无意义的轮询空转但也带来一个问题锁争抢激烈时线程唤醒和重新抢锁有一定的延迟。具体的延迟大小受 Redis 网络环境影响压测时需要重点关注这个指标。3. 实操Spring Boot 集成 Redisson3.1 依赖引入与配置Spring Boot 项目集成 Redisson 很简单引入一个依赖就行。下面是用 Maven 引入 Redisson Spring Boot Starter 的配置dependency groupIdorg.redisson/groupId artifactIdredisson-spring-boot-starter/artifactId version3.27.2/version /dependency然后在application.yml里配置 Redis 连接信息spring: data: redis: host: 127.0.0.1 port: 6379 password: database: 0如果用的是 Redisson 独立客户端也可以直接通过代码配置RedissonClientConfiguration public class RedissonConfig { Bean(destroyMethod shutdown) public RedissonClient redissonClient() { Config config new Config(); config.useSingleServer() .setAddress(redis://127.0.0.1:6379) .setConnectionPoolSize(64) .setConnectionMinimumIdleSize(32); return Redisson.create(config); } }我建议用 Spring Boot Starter 方式它能自动配置RedissonClient直接用Autowired注入即可省去手工管理 Bean 生命周期的麻烦。连接池参数需要根据实际并发量调整默认参数在高并发场景下可能会出现连接等待。3.2 业务代码怎么写才正确先看一段典型的正确用法。以订单支付场景为例防止同一个订单被重复支付Autowired private RedissonClient redissonClient; public void payOrder(Long orderId) { String lockKey lock:pay: orderId; RLock lock redissonClient.getLock(lockKey); boolean acquired false; try { acquired lock.tryLock(3, 10, TimeUnit.SECONDS); if (!acquired) { throw new BizException(系统繁忙请稍后重试); } // 核心支付逻辑 doPay(orderId); } finally { if (acquired) { lock.unlock(); } } }tryLock(3, 10, TimeUnit.SECONDS)的语义是最多等待 3 秒获取锁获取成功后锁的持有时间为 10 秒。这里有个关键点手动指定了 leaseTime10 秒后看门狗不会启动所以 10 秒后锁一定会释放。如果你的支付流程在极端情况下超过 10 秒锁就会提前失效。更稳妥的做法是调大 leaseTime或者不传 leaseTime 让看门狗自动续期。解锁必须放在 finally 里这是铁律。即使业务抛异常锁也要释放否则只能等锁超时。这里还要注意一个细节lock.unlock()不能直接调用必须在加锁成功后才解锁。如果加锁失败了还去 unlock会抛异常。上面代码里的acquired标志位就是用来做这个判断的。3.3 两个容易忽略的细节第一个细节是序列化问题。Redisson 默认使用 FST 序列化器如果你的锁 Key 或者业务对象没有实现Serializable接口或者序列化方式不兼容加锁时会直接报错。我遇到过客户现场因为使用自定义序列化器导致锁 Key 异常的情况排查时发现 Redis 里存的 key 是一串乱码。建议在 Redisson 全局配置中统一指定 Kryo 或者 Jackson 序列化器避免默认 FST 在不同版本间产生兼容问题。第二个细节是锁内不能做耗时操作。锁的查询、扣减、写库这些都应该控制在几十毫秒内完成。如果你在锁里调外部接口、发短信、同步远程调用锁的持有时间会被无限拉长其他线程全部排队等待系统的吞吐量断崖式下降。我见过一个项目在锁里做用户画像计算耗时 2 秒多导致 QPS 从几千掉到几十。分布式锁是为了保护短小精悍的临界区不是让你把整个业务链路都塞进去。如果要保护的操作确实很长需要好好评估用不用分布式锁。或者换一个思路把长任务拆成多个短任务每个短任务各持一把锁粒度更细锁的持有时间更短系统的并发度会好很多。4. 高级用法公平锁、读写锁与信号量4.1 公平锁的使用场景Redisson 的getFairLock()能创建一把公平锁。普通锁是“随机唤醒”等待线程公平锁则严格按照线程请求锁的顺序分配。这个特性在某些业务场景里非常重要比如使用优惠券秒杀时先来的人应该先获得资格。RLock fairLock redissonClient.getFairLock(lock:seckill:coupon); boolean acquired fairLock.tryLock(5, 15, TimeUnit.SECONDS);公平锁的实现原理是使用 Redis 的有序集合ZSet来维护等待队列每个线程在尝试获取锁时会先入队携带一个有序的排队分数。锁释放时从队列头部取出最早等待的线程进行分配。这个机制带来的代价是额外的一次 ZSet 操作性能上比非公平锁略低。并发量非常大的系统我通常不建议用公平锁因为锁等待队列会占用额外的 Redis 内存而且入队操作本身会增加锁获取的延迟。公平锁也可以配合看门狗机制使用同样要注意手动指定 leaseTime 后会取消自动续期。这里有一个小技巧在使用公平锁时建议把等待时间设长一些比如 5 秒配合短持有时间来保证整体队列的吞吐。4.2 读写锁怎么解决缓存刷新的一致性问题读写锁是 Redisson 提供的另一种重要锁类型适合“读多写少”的场景。它允许读锁和读锁之间并发获取但写锁和任何其他锁都互斥。这说明读操作可以并行执行写操作则必须独占。RReadWriteLock rwLock redissonClient.getReadWriteLock(lock:hotGoods); RLock readLock rwLock.readLock(); RLock writeLock rwLock.writeLock();在缓存刷新的场景里这个特性非常有用。比如商品详情页多个线程同时读取同一份缓存可以并发获取读锁但当某个线程需要刷新缓存时它要先获取写锁等待所有读锁释放后才能执行更新。这个设计能避免“读到一个写完一半的脏数据”问题。不过我实际项目中不太建议过度使用读写锁。因为读锁获取与释放的成本比普通锁略高读多写少的场景用 Redis 缓存本身就能解决大部分并发读问题不一定需要加锁。如果写操作的频率超过 10%读写锁的优势就不明显了反而会给 Redis 增加额外的负载。先想清楚业务痛点再决定要不要用读写锁。4.3 信号量与闭锁的实用模式信号量Semaphore在 Redisson 里的使用场景是“限制某个资源的并发访问数量”。比如限制某个接口的最大并发数RSemaphore semaphore redissonClient.getSemaphore(limit:api:123); boolean acquired semaphore.tryAcquire(); if (acquired) { try { // 业务逻辑 } finally { semaphore.release(); } }信号量和分布式锁的区别在于锁是互斥的只有一个人能进入信号量则是多个名额可以允许多个线程同时进入。它适合做简单的限流比如限制某台机器的连接数、限制某个下游服务的瞬时并发数。但注意信号量不能保证同一时间只有一个线程修改数据它不是一个数据一致性的解决方案只是一个并发控制工具。闭锁CountDownLatch在 Redisson 里对应RCountDownLatch适合“等 N 个任务都完成后再继续”的场景。比如批量任务执行完毕后汇总统计。闭锁本质上是一个计数器各个子任务结束后递减计数主线程等待计数归零后继续执行。需要注意的是闭锁的计数不能为负递减之前要对数值做校验否则会抛出异常。5. 常见问题与排查实录5.1 主从切换导致锁丢失怎么应对Redisson 单机模式的分布式锁在 Redis 主从切换时依然存在丢失风险。虽然 Redisson 的 Hash 结构设计比 SETNX 稳得多但只要锁数据只存在于一个节点主节点宕机时数据就可能丢失。如果业务对锁的可靠性要求特别高Redisson 提供了 RedLock 多节点锁模式。RedLock 的核心理念是在 N 个独立的 Redis 节点上尝试获取同一把锁只有获取成功超过半数节点时才算真正获取到锁。这样做的好处是即使一个节点发生故障只要至少 N/21 个节点还有锁数据锁就不会丢。缺点是性能开销大而且对每个节点的时钟一致性有较高要求实际维护成本不低。我个人的看法是绝大多数业务系统用单机 Redisson 锁已经足够。只有当你在做分布式数据基础设施、资金类高一致性场景时才考虑 RedLock。而且 RedLock 用起来复杂出了问题更复杂团队里如果没有对分布式系统有深刻理解的人不建议贸然引入。5.2 看门狗续期失效导致的锁提前释放看门狗续期失效有几种典型原因。最常见的是业务线程阻塞。看门狗的后台线程负责续期但它会先判断锁的持有线程是否存活。如果持有锁的业务线程因 GC 停顿、IO 等待、线程池饥饿等原因长时间阻塞看门狗就认为锁已经不需要续期不执行延长操作。锁到期后其他线程立即抢到锁原来的线程处理完业务再提交数据就会产生双写冲突。排查这类问题时可以先打开 Redisson 的日志级别为 DEBUG观察看门狗是否执行了续期。然后检查业务代码里是否存在长时间阻塞的操作比如同步等待外部接口返回、等待某个资源锁、执行了超耗时的 SQL。锁内的操作必须设计成“快速失败”的模式能设超时的调用务必设超时能异步的尽量异步。5.3 锁不释放、一直卡住排查思路锁一直不释放最典型的场景就是业务代码异常后没有执行 unlock。比如上面提到的tryLock返回了false但代码里没有用标志位保护仍然执行了unlock()或者在if (acquired)判断之外写了 unlock导致根本没获得锁的线程也尝试释放锁。这类问题不用看 Redis 也猜得出来。另一个常见问题是锁 Key 的前缀设计不合理。比如同一个业务用了多个不同的锁 Key但业务数据边界没对齐导致同一个订单既能被lock:pay:123锁住又能在另一个服务里用lock:refund:123绕过锁。这种“锁对不上业务”的问题比锁本身的 Bug 更难发现。排查时要从业务建模层面去审视锁的 Key 必须严格覆盖所有需要互斥的操作入口。我排查锁问题时通常会看 Redis 的慢日志、监控 Hash 里的计数和剩余过期时间。如果锁的 TTL 一直不变且持有者是一个已经结束的线程基本可以断定是线程没有正常释放锁。这时候要优先考虑在 Redis 控制台手动解除锁保证业务先恢复再回头修代码。5.4 常见问题速查表现象可能原因排查方法解决建议锁提前失效出现并发重复操作手动设置 leaseTime 过短且业务执行超时查看 Redis 中锁的 TTL检查业务执行耗时调大 leaseTime或去掉手动 leaseTime 使用看门狗解锁抛异常 IllegalMonitorStateExceptionunlock 时锁已过期或被其他线程持有打印异常堆栈确认持有者线程 ID加锁后用标志位保护只在获取成功时解锁多个线程同时进入临界区主从切换导致锁数据丢失查看哨兵切换记录检查锁是否存在考虑 RedLock 多节点模式锁长时间不释放业务阻塞业务线程未执行 unlock或看门狗失效检查代码是否有 unlock 遗漏观察线程状态补上 finally 解锁优化锁内代码耗时Redis 的 QPS 突然飙升锁争抢激烈等待线程频繁被唤醒查看监控面板统计锁接口的等待时长拆分锁粒度缩短锁持有时间6. 结合实践经验的几点体会分布式锁这块我经历过三个阶段的转变。最初是手写 SETNX 锁用着简单但一到高并发和故障场景就露馅后来换成 Redisson 默认锁稳定性提升一大截最后我意识到锁本身用对只是底线锁 Key 的设计、锁内操作的耗时、锁和业务边界的高度对齐这些才是真正决定系统可靠性的核心。如果你还没把锁换到 Redisson 上我的建议是越早越好。最大的挑战不是 Redisson 的 API而是历史代码里已经用 SETNX 锁写的业务逻辑能不能彻底切过来。切的时候要重点验证可重入行为和锁过期时间。给新同学讲 Redisson 时我经常说锁不是一个锦上添花的组件它是保障你系统数据一致性的最后一道防线。对这道防线值得多花一点时间把它做扎实。