一、面试题简述

能系统地说一下常见的缓存策略吗？在实际项目中你会如何选择？你是怎么权衡一致性和性能的？

二、面试官想听的

这道题不是在考有没有用过 Redis，它实际上在考三个能力层级：

1、你是否理解缓存的本质矛盾：一致性 vs 性能

2、你是否知道缓存策略不是一个点，而是一整套机制

3、你是否具备按业务特性选方案的架构判断力

高分的回答应该是把缓存当成一套完整的高并发风险控制系统。

三、面试回答举例

我理解缓存策略本质不是怎么加缓存，而是围绕数据一致性、系统稳定性和性能目标之间做权衡。

如果系统不需要高并发，理论上可以不加缓存。

由此可见，缓存的存在，本身是一个性能优化手段，而不是一致性保障工具。

1、常见读写模式

第一类：Cache Aside

这是最常见、也最工程化的模式。

读：

• 先查缓存
• 未命中则查数据库
• 回填缓存

写：

• 先更新数据库
• 再删除缓存

这种模式的优势在于：

• 实现简单
• 不侵入业务逻辑
• 容易扩展

但它天然存在一个窗口期，如果DB 更新成功，但缓存还没删或者刚好被读线程回填旧值。

在绝大多数互联网业务场景，这种不一致是可接受的，因为数据更新频率远低于读取频率。

第二类：Read Through / Write Through

由缓存组件负责读写数据库。

优点：

• 一致性边界更清晰
• 应用层代码更干净

缺点：

• 实现复杂
• 强依赖中间件能力
• 对业务控制力弱

通常适用于对一致性要求较高、读写路径需要标准化的系统。

第三类：Write Back

写请求只写缓存，异步刷盘。

优势：

• 写性能极高
• 非常适合高写入场景

风险：

• 崩溃可能丢数据
• 强一致性无法保证

通常用于：

• 日志
• 统计类数据
• 可容忍丢失的指标数据

2、真正拉开层级的：风险控制体系

缓存设计真正复杂的部分，不在读写模式，而在高并发异常场景的处理能力。

缓存穿透：指的是请求的数据在数据库也不存在。

解决：

• 布隆过滤器
• 空值缓存
• 参数校验

缓存击穿：指的是某个热点 Key 过期瞬间，大量请求打到 DB。

解决：

• 互斥锁
• 单飞机制（SingleFlight）
• 逻辑过期 + 异步刷新

缓存雪崩：指的是大量 Key 同时过期。

解决：

• 随机过期时间
• 多级缓存
• 限流降级

3、如何在真实项目中选择？

我会从三个维度做决策：

第一：数据更新频率

• 更新少、读多 → Cache Aside 非常合适
• 写多 → 需要考虑写合并或写回

第二：一致性要求

• 金融交易类 → 不依赖缓存做强一致
• 内容展示类 → 最终一致完全可接受

第三：系统风险承受能力

• 是否能容忍短时间脏数据？
• 是否允许缓存失效时限流或降级？
• 是否有监控与熔断机制？

缓存策略的选择，本质是根据业务风险等级来选择一致性模型。

四、由浅入深分析

缓存设计的根本矛盾是强一致性意味着频繁同步，必然牺牲性能

高性能意味着异步或延迟，必然存在不一致窗口

所以成熟的系统设计不会问如何做到绝对一致，而是会考虑哪些不一致是可以接受的、哪些风险必须兜底。

一个真正完整的缓存方案，至少包含：

• 读写模式
• 失效策略
• 异常场景处理
• 降级与限流
• 监控与报警

缓存不是一个技术点，而是一套系统韧性设计。

五、面试加分点

1、明确指出缓存是性能优化手段，而不是一致性工具

2、主动把问题扩展到穿透 / 击穿 / 雪崩

3、强调按业务风险选择策略

4、提到监控与降级

5、提到最终一致性是可设计的，而不是被动接受的