Redis 缓存已经是后端面试高频题，但很多项目真正上线后，会继续引入本地缓存、热点缓存、配置缓存甚至 CDN。面试官如果追问多级缓存，并不是想听“本地缓存更快，Redis 更通用”这么简单，而是看你能不能讲清每一层的边界。
多级缓存的难点不在多，而在失效和一致性。缓存层越多，命中路径越复杂，出错时越难判断用户看到的是哪一层旧数据。
本地缓存解决的是极热和低延迟
本地缓存适合非常高频、体积较小、更新不频繁的数据，比如配置、字典、权限片段、热点规则。它的优点是访问快，不依赖网络；缺点也明显：每个实例都有一份，更新传播慢，容量不受中心化控制。
所以本地缓存不要轻易放强一致数据。价格、库存、支付状态这类字段，如果多个实例各自持有旧值，后果会很难收拾。本地缓存更适合可以短时间容忍延迟的数据，并且要有容量上限和过期策略。
Redis 解决共享缓存和回源保护
Redis 更适合多实例共享的热点数据、会话信息、计数、限流和分布式协调。它能减少数据库读压力，也能作为回源保护的一层。但 Redis 不是数据库的替代品，不能默认它永远可用，也不能把所有业务状态都放进去当权威数据。
如果 Redis 挂了，系统要决定哪些接口降级，哪些接口回源数据库，哪些接口直接失败。不同业务答案不一样。配置读取可以用本地旧值兜底，订单状态查询可能要回源，核心写入不能因为缓存不可用就绕过数据库校验。
失效传播比命中率更难
多级缓存最容易出问题的是更新。数据库变了，Redis 删了，本地缓存还在；或者 Redis 更新了，本地缓存没有失效。用户请求落到不同实例，就可能看到不同结果。
常见做法是给本地缓存设置较短过期时间，或者通过消息通知实例失效。即使用消息通知，也要考虑通知丢失，所以本地缓存不能无限期有效。过期时间、版本号、主动失效和后台刷新可以组合使用，但核心原则是：任何一层缓存都不能永久阻止新数据生效。
热点保护要避免击穿下游
多级缓存常用于热点保护。最热的数据可以先命中本地，再命中 Redis，最后才回数据库。热点过期时，如果所有实例同时回源，数据库仍然可能被打穿。可以用逻辑过期、异步刷新、单飞请求或热点预热降低风险。
这里要注意，逻辑过期意味着用户可能读到短时间旧值。它适合配置、展示、推荐等场景，不适合强一致状态。面试里能主动说出这个取舍，会比单纯说“加本地缓存提高性能”更成熟。
一个完整表达
可以这样回答：多级缓存不是简单叠层，而是分工。本地缓存负责极热、低延迟、可容忍短暂旧值的数据；Redis 负责多实例共享缓存和回源保护；数据库仍然是权威数据源。更新时要考虑失效传播、版本和兜底，故障时要按业务决定回源、降级还是失败。这样讲，缓存方案才像能上线的系统。