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

本文链接：https://blog.csdn.net/qq_45442483/article/details/149033733

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

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

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降级模式。