📚 课程目录第2章高频面试问题与回答框架

第2章高频面试问题与回答框架

面试官想要看到的不仅是答案，更是你拆解问题的能力。本章梳理3个最高频的分布式缓存故障治理面试题，给出标准回答框架、示例话术和常见追问，帮你快速建立「问题→分析→方案→迁移」的表达习惯。

📌 面试问答卡片

1. 缓存击穿 + 热点 Key 导致数据库被打挂

面试问题	“Redis 热点 Key 击穿后你的处理流程是什么？”
考察点	故障定位速度、互斥锁/热点探测方案、降级策略、对业务的影响控制
回答框架	STAR：①S：业务峰值时某商品 Key 访问量暴涨，缓存过期后查询全部打到 DB，导致 DB CPU 100%；② T：5 分钟内恢复读服务，避免雪崩；③A：临时加锁（SETNX）+ 本地缓存兜底，同时将热点 Key 设为永不过期+异步更新；④R：DB 负载降至 30%，p99 延迟从 2s 降到 50ms。
示例回答	“当时双11大促，商品详情 Key 过期后 10 万 QPS 直冲 MySQL。我先用 SETNX 限流只让一个线程回源，其余线程等待本地缓存；同时将 key 改为永不过期，配合定时任务更新。DB 连接数从 800 降到 120，接口恢复响应。”
可能追问	① 如何自动识别热点 Key？② 本地缓存不一致怎么解决？③ 如果锁也挂了怎么办？
避坑提醒	不要只说加锁，必须说明锁超时时间、自动续期、降级到空数据等兜底。避免空转“死锁”。

2. 缓存雪崩（大量 Key 同时过期）

面试问题	“缓存雪崩是如何发生的？你有什么预防和应急方案？”
考察点	过期策略理解、分层缓存设计、限流熔断能力、监控告警体系
回答框架	STAR：①S：业务统一凌晨 0 点失效缓存，导致 DB 瞬间被 20 万查询淹没；②T：1 分钟恢复核心接口，避免全站不可用；③A：紧急方案：对 DB 做限流+降级返回默认值；长期方案：过期时间加随机偏移（基础 TTL ± 10%），并引入本地缓存做第二层防御；④R：雪崩概率降为 0，DB 峰值平稳。
示例回答	“以前发现凌晨接口超时飙高，查日志发现所有缓存集中在同一秒过期。我先在 Nginx 层直接返回历史缓存副本，后端做 DB 限流；后续把过期时间改为 7200～8800 秒随机分布，再用 Caffeine 本地缓存兜底 30 秒。从此没出现过雪崩。”
可能追问	① 随机范围如何设定？② 本地缓存内存压力怎么控制？③ 如果 Redis 实例挂了怎么处理？
避坑提醒	别只说“加随机过期时间”，要说明随机范围基于业务访问曲线。没有实际数据支撑的方案容易被质疑。

3. Redis 主从切换导致缓存不一致与丢失

面试问题	“主从切换后缓存数据丢失了几秒钟，怎么从业务层面补偿？”
考察点	异步复制机制、数据校验、补偿策略、对最终一致性的理解
回答框架	STAR：①S：Redis 主节点宕机，从节点晋升为新主，但未同步的写操作丢失，导致部分用户看到旧数据；②T：10 分钟内恢复数据一致性，不产生脏数据；③A：每次写操作在 DB 和 Redis 都写入双份，并在读请求中对缓存数据做轻量校验（如最后更新时间戳）；发现不一致则触发异步补偿任务，从 DB 拉取最新值更新缓存；④R：数据不一致窗口从 5 秒缩小到 1 秒内，用户无感知。
示例回答	“那次主从切换丢了一批订单状态。我设计了双写+读校验：每次写 Redis 时在缓存 value 头 8 字节写入 DB 时间戳；读时比较时间戳，若缓存落后则异步回源更新。还加了一个延迟队列做重试补偿，最终丢数据场景全部修复。”
可能追问	① 为什么不直接改用强一致方案？② 时间戳一致但业务逻辑不一致怎么处理？③ 异步补偿队列怎么保证不重复不丢失？
避坑提醒	不要否定 Redis 本身的一致性模型，而是展示如何在上层用业务逻辑兜底。避免说“改用 P99 同步复制”这种不现实的方案。

🏢 不同公司侧重点对比

公司	侧重点	常见追问方向
阿里	高并发下的热点探测、降级限流、组件生态（Tair）	如何实现毫秒级热点发现？自适应缓存策略？
腾讯	海量业务一致性、异地多活、Redis vs 自研缓存	跨机房缓存同步？切换延迟如何控制？
字节跳动	高 QPS 下的内存优化、本地缓存 + Redis 混合架构	本地缓存淘汰策略？如何避免本地缓存与 Redis 长期不一致？
美团	Caffeine + Redis 双层缓存、业务降级可观测性	分层缓存命中率分析？降级开关如何设计？

💡 面试技巧： 回答时先快速说出 STAR 框架，再补细节。“我遇到一个类似的场景（S），当时目标是（T），我采取了（A），最终（R）。” 面试官最反感只背理论没有实战因果的答案。