Redisson分布式锁如何有效解决Redis缓存击穿问题

缓存击穿，一个让不少开发者头疼的问题。很多人第一反应是：“加个分布式锁不就解决了？” 但实际情况往往更复杂。单纯加锁，尤其是用不对姿势，不仅防不住击穿，还可能引发新的性能瓶颈甚至数据错乱。真正的防御，是一套组合策略：锁是核心，但必须配合过期时间随机化和空值缓存，三者缺一不可。而用锁的关键，在于明确四个问题：谁来触发加锁？锁住什么？锁多久？以及锁失败了怎么办？

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

缓存击穿不是靠加锁就能自动解决的，Redisson 分布式锁只是其中一环；关键在于“谁来触发加锁”“锁住什么”“锁多久”，以及“锁失败后怎么兜底”。

缓存击穿场景下，为什么直接用 RLock.lock() 会失效

想象一下这个场景：一个热点 key 刚好过期，瞬间涌来成千上万的并发请求。它们发现缓存是空的，于是齐刷刷地冲向数据库。这时候，如果每个请求都自顾自地调用 RLock.lock() 去抢一把锁，会出什么问题？

• 锁的粒度错了：你本想锁住的是“加载数据并回填缓存”这个动作，但代码里锁的却是业务资源 ID（比如 "user:1001"）。这个动作本身没有唯一的标识，很容易导致多个线程误以为自己拿到了“加载权”，结果就是重复执行查库和写缓存。
• 等待策略成了瓶颈：lock() 默认是阻塞等待，高并发下，大量线程会卡在锁外面排队。响应时间被无限拉长，搞不好还会触发连锁超时，引发雪崩。
• 没分清“建设者”和“使用者”：锁应该只在缓存确实为空、且需要去加载数据时才启用。对于那些缓存命中后的普通读取请求，它们根本不应该参与抢锁。

正确姿势：用 tryLock() + 双重检查 + 回填原子性

所以，正确的思路是把“查缓存 → 发现没有 → 加锁 → 查库 → 写缓存 → 解锁”这条链路理清楚，避免锁被滥用。具体可以这么走：

• 第一步，先正常 redis.get("user:1001")。只要数据存在，立刻返回，跟锁没有任何关系。
• 第二步，只有当缓存确实为空时，才尝试获取锁。这里要用 lock.tryLock(3, 10, TimeUnit.SECONDS)：最多等待3秒，拿不到就撤；锁持有时间设为10秒（Watchdog会自动续期，防止任务执行超时导致锁意外释放）。
• 第三步，拿到锁后，千万别急着去查数据库。先再做一次缓存检查（这就是双重检查）。因为在你等待锁的那几毫秒里，可能已经有其他线程完成了数据加载并写入了缓存。
• 第四步，如果第二次检查缓存还是空的，这才执行查库、写缓存的操作，最后解锁。
• 第五步，如果一开始就没拿到锁怎么办？这说明已经有其他线程在加载数据了。这时，你可以选择睡眠几十毫秒后重试查询缓存，或者直接返回一个预设的降级值（fallback），避免无谓的等待。

必须设置 leaseTime 和 waitTime，不能依赖默认值

这里有个大坑：Redisson 的 RLock 默认锁有效期是30秒，而且不会自动续期。对于缓存加载这种可能耗时不确定的操作来说，这非常危险——万一数据库查询慢了点，超过30秒，锁就自动释放了。其他线程一看锁没了，又会发起一轮新的查询，击穿依旧发生。

• 务必显式传参：像 lock.tryLock(2, 60, TimeUnit.SECONDS) 这样，明确指定最多等待2秒，锁持有时间为60秒（此时Watchdog会生效，自动续期）。
• 慎用无参 lock()：这个方法不设过期时间，完全依赖Watchdog机制。而Watchdog只在持有锁的线程存活时才会续期。如果线程发生GC停顿或卡死，续期失败，锁就可能被误释放。
• 合理规划等待时间：waitTime 设得太长（比如10秒），前端响应延迟会变得不可控；设得太短（比如100毫秒），又容易导致大量请求快速尝试后失败，增加系统负担。这个值需要根据接口的实际SLA来调整。

解锁必须用 unlock()，严禁 del 或脚本硬删

Redisson的锁在Redis里存储的value是一个复合结构，包含了UUID、线程ID和重入次数等信息。如果你图省事，直接用 redis.del("lock:user:1001") 去删除，很可能误删了其他线程持有的锁，或者破坏了自己锁的重入状态。

• 唯一安全的方式是 lock.unlock()：这个方法内部通过Lua脚本比对value值，确认无误后才执行删除，保证了原子性和安全性。
• finally块里不能无条件unlock：如果 tryLock 失败了，lock对象可能是null或者并未真正持有锁。此时调用 unlock() 会抛出 IllegalMonitorStateException。
• 更稳妥的写法：加一层判断：if (lock != null && lock.isHeldByCurrentThread()) { lock.unlock(); }。

最后再强调一个容易被忽略的核心点：防御缓存击穿，不能只靠锁这一道关卡。它应该是“锁 + 过期时间随机化 + 空值缓存”这套组合拳的一部分。例如，在回填缓存时，不要固定设置60秒过期，可以加上一个随机偏移：set("user:1001", user, 58 + ThreadLocalRandom.current().nextInt(5), TimeUnit.SECONDS)。这样，大量热点key的失效时间就被打散了，从源头上降低了瞬间集体失效的概率。锁，更多是作为一种最终的兜底手段，而不应该成为第一道防线。