第4章 缓存设计与Redis面试实战
缓存是抵御高并发压力的第一道防线，也是面试中区分"会用Redis"和"懂缓存体系"的核心分水岭。本章围绕穿透/击穿/雪崩、分布式锁、集群选型三个高频板块展开，每道题都配有回答框架、示例话术和追问预判，帮你在面试中呈现出"实战型架构视野"。
本章知识结构
| 核心主题 | 面试考点 | 推荐方案 | 避坑要点 |
|---|---|---|---|
| 缓存穿透 / 击穿 / 雪崩 | 异常场景识别、分层防御策略 | 布隆过滤器 + 互斥锁 + 过期随机化 | 不可只答理论；空值缓存需区分业务语义 |
| Redis 分布式锁 | Redisson 原理、RedLock 缺陷、CAP 权衡 | SETNX + 看门狗 / RedLock 奇数节点 | 禁止 SETNX+EXPIRE 两条命令；注意 GC 停顿影响 |
| Redis 集群模式 | Cluster 槽位分配、选型对比、扩缩容 | Redis Cluster 3主3从 + hash tag | 跨节点事务受限；hash tag 需防数据倾斜 |
| 缓存策略与一致性 | 旁路缓存、延迟双删、最终一致性 | Cache Aside + 异步对账 | 更新顺序：先写 DB 再删缓存；避免并发脏读 |
复习建议：先掌握知识结构表格中的四类考点，再通过问答卡片深化细节，最后用项目案例串联完整方案。
核心考点图解：缓存问题诊断与解决路径
面试官常让你"从现象讲到底层方案"，下图展示从问题识别到技术选型的标准回答路径：
面试加分点：回答时先说"三种问题的核心区别在于请求是否真实存在、key是否为热点、失效范围是否集中"，再逐个给出对应方案，最后用项目数据佐证效果。
面试问答卡片
Q1：请详细讲解缓存穿透、缓存击穿、缓存雪崩的区别及你的项目解决方案。
🎯 面试官考察点
· 是否准确理解三种异常的本质区别（请求是否存在 / key是否热点 / 失效是否集中）
· 有没有真实项目经验，方案是否考虑过资源开销和边界情况
· 能否给出可落地的分层防御架构，而非堆砌术语
📐 回答框架
- 定义对比：一句话说清每个问题的核心特征
- 原因分析：从请求流和数据分布两个角度解释成因
- 分层方案：按"入口→缓存→存储"三层给出具体技术选型
- 项目印证：举一个你实际解决的案例，带上数据指标
✏️ 示例回答：穿透是查询不存在数据，我用布隆过滤器拦截非法key并缓存空值（短TTL）。击穿是热点key失效，采用互斥锁 + 永不过期 + 异步更新。雪崩是大规模key同时过期，将TTL加随机值分散失效，并引入Caffeine本地缓存兜底。三管齐下后，缓存命中率从70%恢复至99.2%。
🔍 可能追问
- 布隆过滤器的误判率如何估算？容量和哈希函数数量怎么定？
- 空值缓存会导致内存泄漏吗？你是如何清理的？
- 互斥锁在超高并发下对性能有多大影响？有没有无锁方案？
- 本地缓存与Redis缓存的数据一致性怎么保证？
⚠️ 避坑提醒：① 不要只背定义，必须结合项目谈"你做了什么"；② 布隆过滤器不支持删除，需定期重建，面试时要主动说明；③ 空值缓存要区分"业务空结果"和"异常空结果"，避免掩盖真实问题。
Q2：Redis分布式锁是如何实现的？RedLock算法的原理和局限性是什么？
🎯 面试官考察点
· 是否真正理解分布式锁的本质（互斥、安全、高可用）
· 对Redisson源码的熟悉程度，以及能否辩证评价RedLock
· 在CAP权衡中做选择的依据
📐 回答框架
- 基础实现：SETNX + 过期时间 + Lua脚本保证原子性
- Redisson增强：看门狗自动续期、可重入、信号量
- RedLock原理：在3/5个奇数节点获取多数锁，容忍少数节点故障
- 局限性：GC暂停可能打破安全性；性能开销较大；时钟跳跃问题
✏️ 示例回答：项目中基于Redisson实现，用SETNX + 过期时间 + 看门狗自动续期。在秒杀库存扣减场景，使用RLock等待3秒、锁超时30秒，保证同一用户同一商品只有一个请求操作库存。RedLock在3个奇数节点获取多数锁，可容忍1节点故障，但GC暂停时所有锁可能同时失效，我们通过缩短GC停顿和监控补偿来缓解。
🔍 可能追问
- RedLock在Full GC时为什么可能失效？你能画个时间线解释吗？
- 你们项目为什么选Redisson而不是自己写？遇到过什么坑？
- 如果要求强一致性（CP），你会换用ZooKeeper吗？为什么？
- 锁超时时间怎么设置？业务执行时间超过锁超时怎么办？
⚠️ 避坑提醒：① 不要用 SETNX + EXPIRE 两条命令，必须用 Lua 或 SET 的 NX/EX 选项；② RedLock 不是银弹，在CP场景下优先考虑 ZooKeeper；③ 锁超时时间应根据业务 p99 耗时设置，并配合看门狗动态续期，避免死锁或锁提前释放。
Q3：你们为什么选择Redis Cluster？数据分片如何实现？与Codis、主从+Sentinel相比的优势？
🎯 面试官考察点
· 对 Redis 集群演进路线和各自原理的掌握程度
· 选型时是否考虑过运维复杂度、扩展性、事务支持等维度
· 对 Cluster 槽位迁移、resharding 等运维细节是否了解
📐 回答框架
- 选型理由：无中心化、原生支持分片、社区活跃
- 分片原理：16384个槽位，CRC16(key) & 16383 计算槽位
- 对比优势：vs Codis — 无中心化，运维简单；vs 主从+Sentinel — 天然水平扩展
- 项目实践：3主3从架构，使用hash tag路由关联数据，支持在线扩缩容
✏️ 示例回答：选择Redis Cluster因为无中心化，16384个槽位通过CRC16哈希分布，支持在线水平扩展。相比Codis运维简单，相比主从+Sentinel天然支持分片。我们使用hash tag将用户维度数据路由到同一节点，支持批量操作。3主3从架构，主节点故障自动failover，大促期间扩从节点提升读能力。
🔍 可能追问
- 槽位迁移过程中对读写请求有什么影响？客户端如何处理MOVED和ASK？
- Cluster模式下事务和Lua脚本有什么限制？你是如何绕过的？
- hash tag使用不当会导致数据倾斜，你们怎么监控和避免？
- 集群规模超过100节点时，gossip协议有什么问题？怎么优化？
⚠️ 避坑提醒：① Cluster 模式下不支持跨节点事务和 Lua 脚本操作多 key，必须用 hash tag 将这些 key 路由到同一节点；② hash tag 不能滥用，避免所有 key 都使用相同 tag 导致数据倾斜；③ 不要忽略 MOVED 和 ASK 重定向的处理逻辑，面试中能说出细节是加分项。
项目案例：电商平台缓存体系重构
| 项目名称 | 电商平台缓存体系重构 |
| 业务背景 | 日活3000万，大促期间缓存命中率从95%骤降至70%，数据库CPU持续100%，多次出现雪崩预警。核心链路包括商品详情、秒杀库存、推荐页。 |
| 规模指标 | 日活 3000万 | QPS峰值 10万 | 缓存key 5亿+ | Redis集群 50台物理机 (256G内存) | 日请求量 80亿 |
| 技术栈 | 缓存层：Redis Cluster 6.2.7 + Redisson 3.17 + Caffeine 本地缓存 防御层：Guava BloomFilter (误判率1%) + 空值缓存 (TTL 30s) 监控层：Prometheus + Grafana + 自定义Redis Exporter 一致性：Cache Aside + 延迟双删 + 异步对账 |
| 核心难点 |
|
| 面试高频追问 |
|