第2章 分布式缓存核心原理与高频面试题
本章聚焦面试实战中最高频的缓存原理问题，覆盖三大经典场景及一套完整项目模板。每个问题均按“考察点—框架—示例—追问—避坑”结构化组织，配合回答路径图强化记忆。
高频面试问答卡（3题）
Q1：请阐述缓存穿透、击穿、雪崩的区别及应对策略。
面试官考察点
- 是否真正理解三者的本质差异（数据不存在 / 热点key过期 / 大面积key同时过期）
- 能否给出可落地的方案，而非背诵理论
- 对高并发下系统保护意识的考察
回答框架
- 穿透：请求不存在数据 → 布隆过滤器 / 空值缓存
- 击穿：热点key突然失效 → 互斥锁 / 逻辑过期 + 异步刷新
- 雪崩：大量key同时过期 → 过期时间加随机值 / 多级缓存 / 限流降级
- 底层共性：熔断限流、缓存预热、集群高可用
示例回答（80字）
“穿透是查不存在的数据，我会用布隆过滤器拦截空key；击穿是热点key失效导致并发打DB，我会加互斥锁或逻辑过期配合后台线程；雪崩是大面积同时过期，我习惯在设置过期时间时加一个随机偏移量，同时部署多级缓存兜底。”
可能追问
- 布隆过滤器误判率怎么算？空间估算公式？
- 互斥锁和逻辑过期哪种更优？适用场景？
- 如果缓存层本身挂了怎么办？
避坑：不要只说“加锁”而没说加什么锁（Redis SETNX vs Zookeeper），也不要把穿透和击穿搞混。雪崩方案必须包含过期时间随机化，仅提集群不够。
Q2：如何保证数据库与Redis缓存的数据一致性（更新策略）？
面试官考察点
- 对“先更新库还是先删缓存”两种典型顺序的利弊理解
- 是否能区分强一致性与最终一致性场景
- 工程上的妥协方案（Cache Aside Pattern / 延迟双删）
回答框架
- Cache Aside Pattern：读时先查缓存→查DB→设缓存；写时先更新DB→删除缓存
- 先删缓存后更新DB：高并发下会出现脏数据，一般不推荐
- 延迟双删：先删缓存→更新DB→延迟再删一次缓存，配合消息队列保证最终一致性
- 强一致性：使用分布式锁或Redisson读写锁，但性能下降明显，仅用于关键场景
示例回答（96字）
“业务通常接受最终一致性，我采用Cache Aside Pattern：先更新数据库，成功后删除缓存。若需要更高一致性，我会加延迟双删——更新DB后通过MQ异步再删一次缓存，并设置短暂过期时间兜底。强一致性场景很少，仅在账户类数据用Redis分布式锁。”
可能追问
- 延迟双删的“延迟”时间怎么定？
- 如果删除缓存失败如何处理（重试机制）？
- binlog监听（Canal）方式与主动删除的区别？
加分项：主动提到“订阅binlog异步删除”方案，体现对业务解耦的思考。
Q3：Redis主从、哨兵、Cluster三种模式的区别与选型依据？
面试官考察点
- 是否熟悉每种模式的架构、数据分片、高可用机制
- 能否根据业务规模、QPS、数据量给出合理推荐
- 对CAP理论在Redis中的权衡理解
回答框架
- 主从：一主多从，读写分离；主宕机需手动升级，不具备自动故障转移。
- 哨兵：在主从上加哨兵节点，自动监控和切换；数据仍全量存储。
- Cluster：数据分片（16384槽），无中心，自动故障迁移；支持水平扩展。
- 选型建议：QPS<10万、数据量<16GB用哨兵；更高并发/更大数据量用Cluster。
示例回答（82字）
“我根据容量和QPS选型：数据量<20G、qps<5万用哨兵，自动切换主从保证高可用；当数据量超过单机内存或QPS>10万时，我会果断选Cluster，用槽位分片和智能客户端路由。Cluster的缺点是跨slot操作受限，架构复杂度也更高。”
可能追问
- Cluster的节点间通信机制（Gossip）详细原理？
- 集群扩容时数据迁移如何做到平滑？
- 为什么Redis Cluster的官方推荐至少3主3从？
避坑：不要只说“Cluster牛逼”，要指出其限制（不支持多key事务、批量操作需hash tag），并对比哨兵在简单场景下的优势。
项目案例模板
| 项目名称 | 电商大促秒杀活动——Redis缓存稳定性优化 |
| 业务背景 | 某电商平台每逢618/双11，热点商品详情页及库存数据QPS暴涨10倍，原有单Redis集群频繁出现热点key、大key、缓存雪崩，导致首页超时率>15% |
| 规模指标 | QPS峰值80万/s，缓存总数据量约120G，商品SKU数500万+，缓存命中率要求>98% |
| 技术栈 | Redis Cluster（12分片）、Codis代理层、Twemproxy、Nginx+Lua、Kafka、HBase（冷数据） |
| 核心难点 | ①热点商品key被秒杀流量打爆，单节点CPU飙升；②大key（某店铺库存hash）拖慢集群；③秒杀前缓存雪崩导致DB被打垮 |
| 面试高频追问 | • 热点key如何自动发现并做本地缓存？ • 大key拆分成小key后一致性怎么保证？ • 缓存预热的具体实现（定时任务还是监听MQ）？ • 降级方案是返回兜底数据还是直接熔断？ |
| 可迁移回答话术 | “我们通过热点key自动探测组件（基于每秒访问频次计数）将热点抓取后，在Nginx层面用Lua脚本做本地缓存脱壳，同时将大key按field拆散到不同槽位，配合多级缓存架构（Nginx local→Redis→HBase）兜底，最终缓存命中率稳定在99.2%，系统可用性达到4个9。” |
💡 项目模板使用建议：面试时将项目背景、难点、方案串联讲述，优先突出“热点自动发现+本地缓存+多级降级”的组合策略，这是大厂面试官最认可的工程思维。