🧠 Redis 缓存设计与应用场景面试题

✅ 好处

• 减轻数据库压力。
• 降低响应延迟。
• 提升系统吞吐量。

⚠️ 风险

• 数据一致性问题。
• 缓存雪崩、击穿、穿透。
• 引入更多组件，系统复杂度上升。

📖 三种典型缓存策略

• Cache Aside（旁路缓存，最常用）：应用读：先读缓存，缓存 miss 再读 DB 并回填；应用写：更新 DB，然后删除缓存。
• Read/Write Through：所有读写都通过缓存层，由缓存层负责读写 DB。
• Write Back：写只写缓存，由缓存异步刷盘到 DB。

❄️ 缓存雪崩

大量缓存同一时间失效，大量请求直接打到 DB，可能导致数据库被打垮。

防护措施

• 缓存过期时间随机化，避免同时失效。
• 对热点数据做预热和互斥锁保护。
• 限流、降级措施。

🔨 缓存击穿

某个非常热点的 Key 在某一时刻失效，大量并发请求同时打到 DB。

解决方案

• 热点 Key 永不过期，后台异步更新。
• 加本地互斥锁或分布式锁，只有一个线程回源 DB。

🕳️ 缓存穿透

请求的数据在 DB 中也不存在，缓存 miss 后每次都访问 DB，可能被恶意构造。

防护方案

• 对不存在的数据缓存一个短期空值。
• 使用布隆过滤器（Bloom Filter）预判 Key 是否存在。
• 对参数做基础校验与限流。

🔗 常见策略

• 写 DB 成功后删除缓存（Cache Aside）。
• 对重要数据使用消息队列异步修复。
• 弱一致场景接受短暂不一致。

⚠️ 经典问题

线程A：更新 DB → 删除缓存；线程B：先读缓存 miss → 读旧 DB → 回填缓存，覆盖了新值。

缓解思路

• 对同一 Key 加分布式锁，串行化更新。
• 延迟双删策略：更新 DB → 删除缓存 → 延迟少量时间再删一次。
• 对写入操作做队列串行化处理。

👤 用户缓存设计示例

• Key：user:profile:{userId}，Hash 存储多字段。
• 读：先读缓存，miss 再查 DB 并回填，设置合理 TTL。
• 写：更新 DB 成功后删除缓存。
• 重要变更通过 MQ 下发通知，其他节点删除本地缓存。

🔥 大 Key / 热 Key

• 大 Key：体积过大的 value，序列化/反序列化和网络传输开销大。
• 热 Key：被大量线程频繁访问的单个 Key。

解决方案

• 大 Key 拆分成多个小 Key，或只缓存热点字段。
• 热 Key 使用本地缓存 + 多级缓存，或副本分摊压力。

🧾 订单缓存思路

• 缓存用户最近 N 条订单列表。
• 订单详情缓存 + TTL。
• 配合消息队列异步更新状态。

🚦 限流示例

• 基于计数器：INCR + 过期时间实现固定窗口限流。
• 基于滑动窗口：记录时间戳列表，定期清理。
• Lua 脚本封装保证原子性。

🛒 商品详情缓存

• 静态资源使用 CDN。
• 接口层使用 Redis 缓存商品详情、库存、评价摘要。
• 库存等强一致数据与数据库通过消息队列/事件流同步。

🧯 容灾与降级

• 多节点集群 + 哨兵/Cluster 保证 Redis 高可用。
• 本地缓存（Guava/Caffeine）兜底。
• 当缓存不可用时，接口自动降级，限制对 DB 的访问频率。

📈 评估指标

• 命中率（hit ratio）。
• DB QPS 降低比例。
• 主要接口的 P95/P99 延迟。
• 缓存节点 CPU、内存、网络负载。

✅ 核心原则

• 命中率优先：找准热点。
• 简化一致性：优先使用“更新 DB，删除缓存”。
• 防护完善：雪崩/击穿/穿透必须有对策。
• 容灾与监控：缓存也要监控、也要高可用。