缓存设计体系化知识（结合大厂面试+实战案例+简历包装）

缓存设计体系化知识（结合大厂面试+实战案例+简历包装）

一、缓存基础设计：键、值、更新策略

1. 核心知识

（1）缓存键设计

• 原则：分层命名（业务:模块:ID）、唯一、可读、避免过长（≤1024字节）
• 案例：电商商品缓存键 product:{id}:detail（分层清晰，支持按商品ID快速查询）
• 进阶：动态键（如 user:{id}:orders:{date} 支持时间范围查询）

（2）缓存值设计

• 序列化：优先选 Protobuf（性能比JSON高3倍）、Kyro；大文本用Gzip压缩（体积降70%+）
• 存储结构：
  • String：存简单值（如库存）
  • Hash：存复杂对象（如用户信息，hgetall 按需读取）
  • List/Set：存时序/去重数据（如商品评价列表）

（3）更新策略

策略	原理	适用场景	案例
主动更新	写DB后主动更新/淘汰缓存	数据实时性要求高（如订单）	电商下单后更新库存缓存
被动失效	依赖TTL过期后被动加载	读多写少（如新闻详情）	资讯平台文章缓存
鸵鸟算法	懒更新（不主动淘汰，等失效后重载）	静态数据（如配置表）	系统静态参数缓存

2. 大厂面试高频题

• Q1：如何设计高可用的缓存键？
  → 答：分层命名（如 biz:module:id:version），加入版本号支持灰度；避免用哈希值作键（可读性差）。
• Q2：缓存值过大怎么优化？
  → 答：拆分字段（Hash结构按需读取）、Proto序列化（比JSON快3倍）、Gzip压缩（大文本场景）。
• Q3：主动更新和被动更新怎么选？
  → 答：实时数据（如订单）用主动更新；静态数据（如配置）用被动+鸵鸟算法，降低更新开销。

3. 简历项目体现

案例：电商订单系统缓存优化

• 设计 分层缓存键（order:{user_id}:{date}），支持按用户和时间维度查询，缓存命中率提升 35%；
• 采用 Protobuf序列化 存储订单数据，内存占用降低 40%，响应时间缩短 20ms；
• 对静态配置（如运费模板）采用 鸵鸟算法，更新频率从10分钟降至1小时，系统吞吐量提升 15%。

二、缓存一致性：双写、读写穿、写回

1. 核心知识

（1）双写一致性（写DB+写缓存）

• 问题：网络延迟导致缓存与DB数据不一致（如写DB成功，写缓存失败）。
• 方案：
  • 延时双删：写DB后，先删缓存，延迟1秒再删一次（解决异步更新的脏数据）；
  • 分布式锁：写操作加锁，保证同一时间只有一个节点更新（强一致，适合金融场景）；
  • 最终一致：通过MQ异步更新缓存（高可用，适合电商场景）。

（2）读写穿（Read/Write Through）

• 原理：缓存层自动同步DB（读穿：缓存未命中时自动加载DB；写穿：写缓存时同步DB）。
• 优势：业务无需关心DB交互，降低复杂度（如Redis的 自动加载 特性）。

（3）写回（Write Behind）

• 原理：写缓存时 异步批量更新DB，提升写性能（吞吐量高），但有数据丢失风险（需配合日志落盘）。
• 适用：高写低读场景（如物流轨迹上报、操作日志）。

2. 大厂面试高频题

• Q1：如何保证缓存与DB的双写一致？
  → 答：电商场景用 最终一致（MQ异步更新）+ 延时双删，金融场景用 分布式锁（强一致）。
• Q2：Write Behind和Write Through的区别？
  → 答：Write Through同步写DB（一致性高，性能一般）；Write Behind异步写DB（性能高，容忍数据丢失）。

3. 简历项目体现

案例：金融交易系统缓存设计

• 采用 分布式锁（Redisson） 保证交易数据强一致，锁冲突率降低 80%；
• 对日志类数据（如交易流水）采用 Write Behind 策略，异步批量写DB，写入性能提升 500%；
• 落地 延时双删（Redis过期键监听），解决订单缓存与DB的一致性问题，故障数减少 30%。

三、缓存风险治理：穿透、雪崩、击穿、预热

1. 核心知识

（1）缓存穿透（查不到的数据打穿DB）

• 原因：恶意请求查询不存在的数据（如攻击接口）。
• 方案：
  • 布隆过滤器：拦截无效请求（如电商商品ID预加载到布隆，拦截率99%+）；
  • 空值缓存：缓存空结果（设置短TTL，如5分钟）。

（2）缓存雪崩（大量缓存同时失效，DB被压垮）

• 原因：批量缓存设置相同TTL，过期时并发回源。
• 方案：
  • 随机TTL：给缓存加0~300秒随机偏移，避免同时失效；
  • 多级缓存：CDN+Redis+本地缓存，分层抗冲击。

（3）缓存击穿（热点Key突然失效，高并发打向DB）

• 原因：热点Key（如大促商品）过期，瞬间高并发查询。
• 方案：
  • 永不过期：热点Key设为永不过期，通过主动更新保证新鲜度；
  • 互斥锁：并发请求时，只允许一个线程回源DB，其余等待（如Redis的SETNX锁）。

（4）缓存预热

• 原理：大促前主动加载热点数据到缓存（如TOP1000商品）。
• 方案：脚本预加载（如Python脚本批量读DB写缓存）、分段预热（按业务维度拆分数据）。

2. 大厂面试高频题

• Q1：缓存穿透、雪崩、击穿的区别？
  → 答：
  • 穿透：查不存在的数据；
  • 雪崩：批量缓存失效；
  • 击穿：热点Key失效。
• Q2：如何治理缓存雪崩？
  → 答：随机TTL+多级缓存+限流降级（如Sentinel熔断）。

3. 简历项目体现

案例：电商大促缓存风险治理

• 引入 布隆过滤器，拦截无效商品查询，DB压力降低 50%；
• 对大促商品缓存设置 随机TTL（1~3小时），配合多级缓存，雪崩概率降至 0.1%；
• 采用 永不过期+主动更新 治理热点Key，秒杀场景响应时间缩短 60%；
• 大促前通过 分段预热脚本 加载TOP5000商品，缓存命中率提升至 98%。

四、多级缓存架构：客户端、CDN、服务端、数据库

1. 核心知识

缓存层级	存储内容	优势	案例
客户端缓存	浏览器LocalStorage、APP内存	减少网络请求（如Token）	社交APP的用户信息缓存
CDN缓存	静态资源（图片、JS、CSS）	降低源站带宽（命中率90%+）	电商商品图片CDN
服务端缓存	业务数据（如订单、库存）	支撑高并发（Redis/QPS万级）	大促库存预扣
数据库缓存	高频查询结果（如MySQL查询缓存）	减少DB计算（如聚合查询）	报表系统的统计数据

2. 大厂面试高频题

• Q1：多级缓存如何分工？
  → 答：CDN存静态资源，服务端存业务数据，客户端存临时数据（如Token），数据库存冷数据。
• Q2：CDN缓存怎么配置？
  → 答：设置长TTL（如7天），配合版本号（如img.v1.jpg）实现缓存更新；回源策略优先选304协商缓存。

3. 简历项目体现

案例：电商全链路缓存优化

• 设计 “CDN+Redis+本地缓存” 三级架构，静态资源CDN命中率 95%，业务数据Redis命中率 98%；
• 客户端采用 LocalStorage缓存常用商品（如用户收藏），页面首屏加载时间缩短 400ms；
• 数据库开启 查询缓存，高频报表查询响应时间从500ms降至50ms，DB负载降低 60%。

五、实战场景：电商下单、大促、金融交易

1. 电商下单场景

• 痛点：高并发下单（如秒杀）导致库存超卖、DB压力大。
• 缓存方案：
  • 库存预扣：Redis缓存库存，下单时先扣缓存，异步落DB（配合MQ保证最终一致）；
  • 订单快照：缓存订单详情（商品、价格、地址），避免实时查DB；
  • 限流降级：Sentinel限制并发，防止缓存击穿。
• 成果：支撑10万QPS，库存超卖率<0.1%，DB压力降低70%。

2. 大促场景

• 痛点：流量突增（日常100倍），缓存雪崩、击穿风险高。
• 缓存方案：
  • 热点隔离：TOP1000商品缓存设为永不过期，单独集群部署；
  • 动态调整TTL：根据流量实时调整缓存过期时间（如峰值时延长TTL）；
  • 熔断降级：Redis宕机时，自动切换到本地缓存+DB降级模式。

3. 金融交易场景

• 痛点：数据强一致要求高，写操作频繁。
• 缓存方案：
  • 强一致：分布式锁（Redisson）保证写操作原子性；
  • 读写分离：读请求走缓存，写请求走DB+异步更新缓存；
  • 灾备：主从Redis集群，配合哨兵自动切换。

六、简历包装公式

“技术点 + 场景 + 方案 + 数据”

示例：
在 电商大促项目 中，针对 热点商品缓存击穿风险，采用 “永不过期+主动更新” 策略，结合 分段预热脚本，使缓存命中率提升至 98%，秒杀场景响应时间缩短 60%，支撑10万QPS下库存超卖率<0.1%。

通过以上体系化梳理，既能覆盖缓存设计的核心知识，又能对接大厂面试考点，还能将技术点落地到项目经历中，帮助简历和面试双重加分！