【30 秒读完 · 核心结论】 缓存不是越多越好，分层才是关键。
4 层缓存模型：浏览器 → CDN → Redis → 本地缓存。
核心原则：靠近用户、命中率优先、一致性兜底。

电商系统的缓存设计 4 层模型

一、为什么需要缓存？

电商系统的流量特征：

• 读多写少：浏览/查询是下单的 100 倍
• 数据热点：80% 流量集中在 20% 商品（头部商品）
• 实时性要求分层：商品详情可以缓存 5 分钟，库存必须实时

缓存的作用：

• 降低数据库压力（80% 查询被缓存吸收）
• 提升响应速度（缓存读取比 DB 快 100 倍）
• 应对高并发（秒杀场景必须用缓存）

二、4 层缓存模型

第 1 层：浏览器缓存（最靠近用户）

缓存内容：静态资源（图片 / CSS / JS / 字体）

缓存方式：

• HTTP 缓存头（Cache-Control / ETag）
• Service Worker（高级缓存）

优势：用户本地缓存，零延迟

局限：浏览器策略不可控，缓存失效需要主动清理

第 2 层：CDN 缓存（边缘节点）

缓存内容：静态资源 + 缓存 HTML 页面

缓存方式：

• 边缘节点缓存（阿里云 CDN / 腾讯云 CDN / Cloudflare）
• 边缘计算（CloudFlare Workers）

优势：就近访问，全国 2000+ 节点

局限：无法缓存个性化内容（如用户登录态数据）

第 3 层：Redis 缓存（应用层核心）

缓存内容：

• 商品详情 / 库存数据
• 用户会话（Session）
• 热点排行榜
• 防重放令牌
• 分布式锁

优势：

• 毫秒级响应
• 支持丰富数据结构（String / Hash / List / Set / Sorted Set）
• 集群可水平扩展

局限：

• 数据丢失风险（需要持久化）
• 容量有限（不适合存大文件）
• 一致性需要业务兜底

第 4 层：本地缓存（进程内）

缓存内容：配置信息、字典数据、热点 key

缓存方式：

• Caffeine（Java）
• Guava Cache
• Ehcache

优势：

• 进程内访问，纳秒级
• 无需网络 IO

局限：

• 应用重启缓存清空
• 多节点缓存不一致（需要广播更新）

三、4 层缓存的协同

用户请求经过的链路：

用户请求
  ↓
浏览器缓存（命中？直接返回）
  ↓ 否
CDN 节点（命中？返回）
  ↓ 否
应用服务器本地缓存（命中？返回）
  ↓ 否
Redis 集群（命中？返回并回填本地缓存）
  ↓ 否
数据库（返回并回填 Redis）
  ↓
返回给用户

四、3 个核心原则

原则 1：靠近用户

缓存层级越靠近用户，访问越快。优先使用浏览器缓存 → CDN → Redis → 本地。

原则 2：命中率优先

目标命中率：

• 浏览器缓存：60-80%
• CDN：85-95%
• Redis：90-99%
• 本地缓存：50-70%

命中率不达标？

• 缓存粒度太细（拆 key）
• 过期时间太短
• 热点数据没识别

原则 3：一致性兜底

缓存不一致问题：缓存和数据库数据不一致（如库存更新后缓存未更新）。

解决方案：

• Cache Aside：先更新 DB，再删除缓存（最常用）
• Read Through：缓存作为数据源，DB 同步写入
• Write Behind：先写缓存，异步写 DB（性能最好但有风险）

五、3 个常见坑

坑 1：缓存雪崩

场景：大量 key 同时过期，所有请求打到数据库。

解决：

• 过期时间加随机偏移（5 分钟 ± 1 分钟）
• 热点 key 永不过期（异步更新）
• 熔断降级（数据库压力大时直接返回缓存）

坑 2：缓存击穿

场景：单个热点 key 过期，并发查询全部打到 DB。

解决：分布式锁（只允许一个请求查 DB，其他等）。

坑 3：缓存穿透

场景：查询不存在的 key，每次都打到 DB。

解决：

• 空值缓存（不存在的 key 也缓存，TTL 短）
• 布隆过滤器（提前判断 key 是否存在）