Redis 缓存问题 → 一致性 → 分布式锁 追问链#

追问路径#

Q: 缓存穿透、击穿、雪崩分别是什么？
→ 穿透=查询不存在的key(绕过缓存直达DB)；击穿=热key过期瞬间大量请求打到DB；雪崩=大批key同时过期
  Q: 缓存穿透怎么解决？
  → 布隆过滤器拦截不存在的key + 空值缓存(短TTL如5分钟)
    Q: 布隆过滤器原理？误判率怎么控制？
    → 位数组+多个hash函数；1%误判率需要约9.6 bit/element、7个hash函数
      Q: 缓存和数据库一致性怎么保证？
      → 先更新DB再删缓存（Cache-Aside）+ 延迟双删兜底 + MQ异步补偿
        ├─ Q: 延迟双删的延迟时间怎么定？
        │  → 略大于一次读请求耗时，通常300-500ms
        │    Q: 还是有不一致怎么办？
        │    → 订阅binlog(Canal)异步更新缓存，保证最终一致
        │      Q: Canal的原理？
        │      → 伪装MySQL从库，解析binlog推送变更事件
        └─ Q: 分布式锁怎么实现？
           → SET key value NX EX timeout + Lua脚本原子释放（判断value再删）
             Q: 锁过期了但业务没执行完怎么办？
             → Redisson看门狗自动续期：默认30s过期，每10s检查一次自动续到30s
               Q: Redis主从切换时锁丢失怎么办？
               → RedLock算法：向N个独立Redis实例加锁，N/2+1成功才算获取
                 Q: RedLock有什么争议？
                 → Martin Kleppmann指出时钟偏移和GC暂停可能导致锁失效；实际生产多用Redisson+业务幂等兜底

涉及知识点#

• 缓存穿透-击穿-雪崩 — 三大缓存问题定义与对策
• 布隆过滤器原理 — 概率型数据结构
• 热Key问题与解决 — 热点key检测与本地缓存
• 大Key问题与解决 — 大value拆分与异步删除
• 缓存与数据库一致性 — Cache-Aside/Read-Through/Write-Behind
• 延迟双删方案 — 双删策略的时序分析
• Redis分布式锁 — SET NX EX + Lua释放
• Redisson分布式锁实现 — 看门狗与可重入锁
• 分布式锁方案对比 — Redis/ZK/MySQL锁对比
• Redis过期与淘汰策略 — 惰性删除+定期删除+8种淘汰策略
• Redis事务与Lua脚本 — 原子操作保证

核心串联逻辑#

1. 缓存穿透：恶意请求查不存在的key → 布隆过滤器前置拦截，误判率可控在1%以内
2. 击穿 vs 雪崩：击穿是单个热key → 用互斥锁或逻辑过期；雪崩是批量key → 随机TTL分散过期
3. 一致性核心矛盾：先更新DB再删缓存仍有短暂不一致窗口（读请求回填旧数据）→ 延迟双删补偿
4. 分布式锁本质：SET NX EX 保证互斥+超时释放；Lua 脚本保证”判断+删除”原子性
5. Redisson看门狗：后台线程每 lockWatchdogTimeout/3（默认10s）续期一次，业务线程完成后取消
6. 代码示例：

   -- Lua脚本原子释放锁
   if redis.call('get', KEYS[1]) == ARGV[1] then
       return redis.call('del', KEYS[1])
   else return 0 end

   lua

面试回答串联#

30秒速答#

“缓存穿透用布隆过滤器+空值缓存，击穿用互斥锁，雪崩用随机TTL。一致性保证采用Cache-Aside+延迟双删，兜底用Canal订阅binlog。分布式锁用Redisson的看门狗自动续期，主从切换丢锁场景靠业务幂等兜底。“

2分钟展开答#

“缓存穿透指查询不存在的key绕过缓存打到数据库，解决方案是布隆过滤器前置拦截——1%误判率只需9.6 bit/element，加上空值缓存设短TTL。击穿是热key过期瞬间并发请求打穿DB，用互斥锁或逻辑过期解决。雪崩是大批key同时过期，在基础TTL上加随机值分散。缓存DB一致性我们用Cache-Aside模式——先更新DB再删缓存，加延迟双删(300-500ms)补偿，最终兜底用Canal订阅binlog异步更新。分布式锁用SET key NX EX加锁，Lua脚本保证释放时判断+删除的原子性。生产中用Redisson，看门狗默认30s过期每10s续期，避免业务未完成锁就过期。Redis主从切换可能丢锁，RedLock需要N/2+1个独立实例确认，但Martin Kleppmann指出时钟偏移问题，实际我们用Redisson+业务幂等双重保障。“

相关追问链#

• Redis持久化-OS-fork-COW追问链 — Redis底层存储与持久化机制
• 分布式锁-事务-一致性方案追问链 — 分布式锁与分布式事务的关联
• 秒杀系统-限流-库存扣减-分布式锁追问链 — 分布式锁在秒杀场景的实际应用