Redisson解决并发击穿方法详解

Redisson 的 RLock 本身并不能解决缓存击穿问题，它仅提供分布式锁能力，而击穿的本质是缓存未命中时大量请求直接涌向数据库；真正有效的防护需结合双检锁（二次缓存校验）、空值缓存（带短 TTL 的 null 值兜底）、精准锁粒度（key 与业务强绑定）、合理超时控制（推荐使用 tryLock 配置等待与持有时间）以及及时降级策略——这四者协同才能在保证一致性的同时避免 DB 压力激增、线程阻塞和空缓存污染，让系统在高并发场景下既稳定又灵敏。

Redisson 的 RLock 能防击穿吗？不能，得换思路

直接说结论：RLock 本身不解决缓存击穿，它只管「加锁」，而击穿的关键是「缓存未命中 + 大量请求穿透到 DB」。你用 RLock 锁住 DB 查询，但第一个线程查完写回缓存前，其余线程还在等锁——它们没被拦在缓存层，只是卡在锁上，DB 压力仍存在，且响应延迟拉高。

真正要防击穿，得让「未命中时的查询行为」变成串行+自动回填，同时避免锁粒度太粗或漏掉空值场景。

用 Redisson.getLock() + 双检 + 空值缓存组合才靠谱

这是生产中验证过的最小可行方案：先查缓存 → 空则抢锁 → 拿到锁再查一次缓存（防重复加载）→ 查 DB → 写缓存（含空值兜底）→ 释放锁。

• getLock("lock:goods:" + id) 的 key 必须和业务数据强绑定，比如 "lock:goods:123"，别用固定 key，否则所有商品查都串行了
• 第二次查缓存（双检）不能省，否则多个线程抢到锁后都会去查 DB
• 空结果必须写缓存，比如 set("goods:123", null, 2, TimeUnit.MINUTES)，否则下次请求又击穿；注意 Redisson 的 RMapCache 或原生命令都支持设 TTL
• 锁超时时间要大于 DB 查询+写缓存的最坏耗时，建议设为 3–5 倍，避免锁提前释放导致重复加载

tryLock() 和 lock() 别乱选，超时控制很关键

用 lock() 会阻塞直到获取成功，线上服务容易线程积压；tryLock(long waitTime, long leaseTime, TimeUnit) 更可控，推荐设 waitTime=100ms、leaseTime=3000ms：

• 等待太久没意义——击穿本就是突发流量，等 1 秒不如直接返回旧缓存或降级
• leaseTime 是锁自动释放时间，不是获取锁的超时，必须覆盖完整业务流程
• 如果 tryLock() 返回 false，别重试，应走降级逻辑（如返回默认值、或稍后重试提示）

空值缓存的 TTL 设置不当，反而放大雪崩风险

很多人设空值 TTL 和正常数据一样长（比如 30 分钟），结果 DB 故障期间大量空缓存堆积，故障恢复后这些空值还卡着，新请求全打 DB。

• 空值 TTL 应显著短于有效数据 TTL，比如有效数据 30 分钟，空值设 2–5 分钟
• 不要用永久空值（setex 不带 TTL），Redis 内存会涨，且无法自动刷新
• 如果业务允许，空值可加随机偏移，比如 2 + ThreadLocalRandom.current().nextInt(60) 秒，分散集中过期

击穿真正的难点不在加锁，而在「什么时候该放弃等待」「空值怎么不污染后续请求」「锁释放和缓存写入怎么原子化」——这几个点没对齐，再多的 RLock 都只是把问题从 DB 搬到了线程池。

今天关于《Redisson解决并发击穿方法详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！