面试官抛出这个问题时，其实是在考察你是否只停留在“会用 Redis”，而是真正理解高并发场景下缓存体系的工程化设计——包括性能边界、热点防护、一致性取舍、高可用、成本等多个维度的权衡。
下面给出一个目前（2026年）互联网中大型/超大型系统里比较主流且能打到“极致”的缓存架构思路，从分层到细节逐步展开。你可以按这个框架去回答，基本能cover 90%+ 的追问点。
1. 整体架构分层（主流极致方案：三级/四级缓存）
客户端 → CDN（静态 + 部分动态边缘缓存） ↓ Nginx / API Gateway（L1 本地缓存 + Lua 热点防护） ↓ 应用层（L2 本地缓存：Caffeine / Guava Cache / EHCache） ↓ Redis 集群（L3 分布式缓存：Cluster / 多主分片 + Proxy） ↓ DB（MySQL / PolarDB / TiDB） + 最终一致性兜底- L0：CDN / 边缘缓存（图片、JS、HTML 片段、甚至部分 JSON 接口结果）
- L1：Nginx 层本地缓存（openresty + shared dict / lua-resty-cache）或进程内缓存
- L2：应用 JVM 内本地缓存（Caffeine 目前最主流）
- L3：Redis（分布式共享缓存）
为什么多级而不是只用 Redis？
单机 Redis 再强（单线程模型下 IO 多路复用）也很难稳定超过 20–30w QPS（考虑大 value、热点、网络抖动后更低）。多级能把 80–95% 的请求挡在本地，Redis 只承接 5–20% 的穿透流量。
2. 读链路（Cache Aside + 多级 + 防穿透/击穿）
- 先查L2 本地缓存（Caffeine，expire + refreshAfterWrite）
- miss → 查L3 Redis
- miss → 查 DB → 回写 Redis → 回写本地缓存
- 热点防护（防止击穿/雪崩）：
- 本地缓存层面：Caffeine loadingCache + 同步加载（只让一个线程去加载，其他线程等待）
- Redis 层面：setnx + 随机过期时间 + 热点 key 提前预热（或用分布式锁 + 看门狗）
- 极端热点：Nginx 层 shared dict 做二级本地缓存或一致性 hash 路由 + 本地缓存（但要配合熔断）
3. 写链路 & 一致性（最常被追问）
主流取舍（2025–2026 年大厂真实偏好）：
| 一致性要求 | 推荐方案 | 延迟 | 复杂度 | 适用场景 |
|---|---|---|---|---|
| 最终一致性（主流） | Cache-Aside +先写 DB → 延迟双删 | 低 | 中 | 商品详情、用户资料、推荐 |
| 强一致性 | 先删缓存 → 写 DB → 读 DB 回写缓存 | 中 | 低 | 库存、余额、积分 |
| 极致高并发 + 可接受短暂不一致 | 只删不写+ 本地缓存短 TTL + Redis 异步更新 | 极低 | 高 | 秒杀读多写少、排行榜 |
| 最高一致性 | Canal / Maxwell / Debezium监听 binlog → 推送到 Redis | 中 | 高 | 金融、对账、核心配置 |
延迟双删最常见写法（伪代码）：
@TransactionalpublicvoidupdateProduct(Productproduct){// 1. 先写 DBproductMapper.update(product);// 2. 立即删 Redis（防读到旧值）redis.delete("product:"+product.getId());// 3. 延迟 100–500ms 再删一次（防读-写-读并发场景下的脏数据）ThreadPool.execute(()->{Thread.sleep(200);redis.delete("product:"+product.getId());});}本地缓存一致性（Caffeine + Redis）：
- Redis 发Pub/Sub或Stream广播失效事件
- 各节点订阅后删除本地缓存（最主流方案）
- 或者用短 TTL + 主动刷新（牺牲一点命中率换简单）
4. 热点 & 大 key & 拆分 & 限流（极致高并发的护城河）
- 热点 key：提前识别（大促前埋点 / Redis 热点检测 / 客户端上报）→ 打散多副本（多 key + 随机后缀）或用本地缓存 + 一致性 hash 路由
- 大 key：拆（Hash/List/Set 分片）、懒删除、scan + hdel
- Redis 自身防护：
- proxy 层（Twemproxy / Codis / Redis-Cluster Proxy / 自研）
- 慢查询监控 + 大 key 拆分 + 内存淘汰策略（allkeys-lru / volatile-lfu）
- 主从 + 哨兵 / Cluster + 多副本读写分离
- 应用层限流：令牌桶 / 漏桶 + Sentinel / Resilience4j 熔断 + 降级读 DB / 读本地快照
5. 高可用 & 容灾（别只说主从）
- Redis Cluster（16384 slot） + 多 master + replica ≥ 2
- 多机房 / 多地域读写分离（主写从读 + Proxy 智能路由）
- 缓存穿透兜底：布隆过滤器（Redis bitmap / 本地 long[]）
- 雪崩防护：随机过期 + 过期时间打散+预热+熔断降级（读本地 / 读降级数据源）
- 冷启动：异步预热（MQ + 定时任务）或热点数据持久化（RDB + AOF 混合）
6. 监控 & 观测（面试官很爱问）
- 核心指标：命中率（分层分别看）、QPS、延迟 p99、慢查询、淘汰 key 数、内存碎片率、连接数
- 热点探测：Redis 慢查询 + INFO commandstats + 客户端上报
- 报警：命中率 < 85%、延迟突增、内存使用率 > 80%、大 key 出现
一句话总结回答框架：
“我不会只用单机 Redis，而是采用 CDN + Nginx/OpenResty + Caffeine本地缓存 + Redis Cluster 多级缓存架构。
读走就近原则（本地 > Redis > DB），写采用先写 DB + 延迟双删 + Pub/Sub 广播本地失效保证最终一致性。
热点通过提前预热 + 打散多副本 + 本地缓存防护，Redis 本身做Cluster + Proxy + 慢查询监控 + 大 key 拆分，整体能稳定支撑单接口百万 QPS级别并发，同时保持99.99% 可用性。”
你现在可以根据项目实际情况补充具体数字、技术选型和踩坑经验，基本就能把面试官问懵～
你项目里目前做到哪一层了？或者最头疼的是哪个点（热点、一致性、成本）？可以继续聊。
（支持资料、图片参考_相关定制）_文章底部可以扫码)
