2. 缓存基础与核心理论高频问答
本章导读：面试官常从底层定义切入，考察你对缓存本质、读写模式、命中率与过期策略的掌握深度。重点是能区分“缓存是什么”和“缓存怎么用”，并能结合实际场景分析命中率与TTL/TTI的权衡。
面试问答卡 1：缓存定义与核心作用
面试问题：请解释缓存是什么？它在分布式系统中起什么核心作用？
考察点：对缓存本质的理解（存储层次、数据局部性），能否从性能、可靠性、成本角度阐述。
回答框架：①缓存定义 → ②数据临时存储介质 → ③核心作用（降低延迟/减轻后端压力/提高吞吐）→ ④举例。
示例回答：缓存是将热点数据存储在高速介质（如内存）中，减少对数据库或磁盘的访问。核心作用：①降低平均延迟（从10ms降至1ms以内）；②保护后端系统，防止读放大；③提高系统吞吐能力。
可能追问：①缓存与数据库的最终一致性如何处理？②写缓存和读缓存场景有何不同？
避坑提醒：不要把缓存简单等同于Redis，要先从定义抽象说起，再降落到具体实现。避免只讲数据库兜底忽略了一致性细节。
面试问答卡 2：缓存读写模式
面试问题：常见的缓存读写模式有哪些？请对比Cache Aside、Read/Write Through、Write Behind的优缺点。
考察点：对主流模式的理解深度，能否区分不同场景下的选择，以及一致性保证。
回答框架：①列出三种模式 → ②核心流程对比（读/写时谁管理缓存）→ ③优缺点（一致性/复杂性/延迟）→ ④典型选型建议。
示例回答：Cache Aside：应用负责读写缓存，缓存缺失则查DB再回写，并发时需防缓存击穿。Read/Write Through：缓存层代理DB读写，对应用透明，但复杂度高。Write Behind：异步批量写DB，性能高但数据可能丢失。电商秒杀场景常用Cache Aside+TTL。
可能追问：①Cache Aside中先删缓存还是先更新DB？为什么？②Write Behind的落盘策略如何设计？
避坑提醒：避免只背诵概念，要举例说明不同模式在上万QPS下的实际表现。特别强调Cache Aside中“延迟双删”的适用条件。
面试问答卡 3：命中率、TTL与TTI
面试问题：什么是缓存命中率？如何提升命中率？TTL和TTI有什么区别？
考察点：对缓存有效性指标的理解，能否区分两种过期策略的适用场景。
回答框架：①命中率定义 → ②提升命中率方法（预加载/合理过期/热数据识别）→ ③TTL与TTI区别（固定时间 vs 空闲时间）→ ④实际选择。
示例回答：命中率 = 缓存返回次数 / 总请求次数，理想值 >95%。提升方法：增加缓存容量、设置合理TTL避免频繁失效、使用LRU淘汰算法。TTL（Time To Live）是从写入开始固定生命期；TTI（Time To Idle）是在空闲时间后失效，适合会话缓存。通常结合使用，如Redis的maxmemory-policy。
可能追问：①TTL设置太长发数据不一致，太短命中率低，如何平衡？②TTI模式下大量并发访问如何保证不提前失效？
避坑提醒：不要只抛出数字（如TTL=3600），要说明根据业务访问频率动态调整。避免混淆TTI与TTL的底层实现（Redis的idle时间实际依赖访问更新时间）。
项目案例：电商平台Redis缓存层重构
| 项目名称 | 电商APP首页热点数据缓存层改造 |
|---|---|
| 业务背景 | 促销活动导致首页QPS激增至8万，直接DB查询超时率达12%，用户体验下降。 |
| 规模指标 | 缓存实例12个Redis Cluster（32GB/节点）；每日缓存key数约500万；读写比例7:3。 |
| 技术栈 | Redis 6.2、Twemproxy代理、Sentinel高可用、Hash Tag分片、Lua脚本 |
| 核心难点 | ①热点商品突发导致单分片CPU飙升；②TTL设置不合理导致缓存穿透和雪崩；③写模式使用Cache Aside但更新一致性难以保证。 |
| 面试高频追问 |
|
| 可迁移回答话术 | “该项目让我意识到缓存不是一层盾牌，而是需要根据访问分布、一致性要求、容量成本动态设计的架构组件。核心经验：热点识别+分层缓存+柔性过期。” |