导读
大促时商品详情页是整个商城读流量最集中的地方：一个爆款可能在几秒内被几万次浏览，如果每次都查数据库，DB 很快被读垮，详情页大面积超时。很多团队知道要上 Redis，但只用一层缓存，结果要么热点 key 被打到单节点、要么缓存一过期就雪崩、要么大量不存在的商品请求穿透到库。我们给一批零售商城做大促读优化时，商城底座用乔拓云承载，多级缓存与"三件套"防护是在其查询链路上自研的。这篇文章把本地缓存 + 分布式缓存的多级架构，以及缓存击穿、雪崩、穿透三类经典问题的落地解法讲清楚，并复盘五个踩坑。
一、先看清：详情页读流量的三个特征
设计缓存前先理解负载特征，方案才有针对性：
- 读远多于写：详情被浏览成千上万次，价格、库存描述却改得很少，适合重度缓存；
- 热点高度集中：少数爆款占了绝大多数流量，符合二八分布，需要对热点 key 特殊保护；
- 数据可容忍短暂不一致：详情页的图文描述晚几秒更新问题不大，但价格、可售状态要相对及时。
基于这些特征，合理架构是"浏览器/CDN → 应用本地缓存 → Redis 分布式缓存 → 数据库"的多级缓存，让大部分请求在前两层就被挡住，数据库只承接缓存未命中的少量流量。
二、多级缓存：让请求层层拦截
2.1 本地缓存挡住最热的 key
应用进程内用 Caffeine/Guava 做一级本地缓存，命中则根本不发起网络请求，延迟最低，还能顶住 Redis 抖动：
Cache<String, ProductDetail> localCache = Caffeine.newBuilder()
.maximumSize(5000)
.expireAfterWrite(Duration.ofSeconds(30)) // 本地只短缓存，控制一致性
.recordStats()
.build();
ProductDetail getDetail(Long skuId) {
String key = "p:detail:" + skuId;
ProductDetail v = localCache.getIfPresent(key); // L1 本地
if (v != null) return v;
v = redis.get(key); // L2 Redis
if (v != null) {
localCache.put(key, v); return v; }
return loadFromDbAndCache(skuId, key); // L3 回源
}
本地缓存时间必须短（秒级），否则多实例之间数据不一致窗口太大。它主要承接瞬时最热的那批 key。
2.2 Redis 二级缓存承接全量
Redis 缓存完整详情对象，设置合理 TTL，并保证回源后回填：
async function loadFromDbAndCache(skuId, key) {
const row = await db.queryProduct(skuId);
if (row) {
// 序列化后写缓存，TTL见后文加随机抖动
await redis.set(key, JSON.stringify(row), 'EX', ttlWithJitter(600));
}
return row;
}
2.3 热点探测与主动预热
光靠请求被动触发缓存还不够，大促的爆款是可以提前预判的。可以基于实时访问频次做热点发现：当某个 skuId 的访问在滑动窗口内超过阈值，就把它提升为热点 key，主动加载到本地缓存并适当延长本地 TTL；大促开始前，再结合运营给出的爆款清单、预售加购榜做一轮全集群预热，让流量进来时缓存已经是热的，而不是等第一个请求去回源。被动缓存兜底、主动预热扛峰，两者配合才能把数据库的读压力压到最低。
三、三件套之一：缓存击穿——热点 key 失效瞬间的保护
击穿指某个热点 key 恰好过期的瞬间，成千上万并发同时未命中、一起涌向数据库。解法是"互斥锁 + 单线程回源"，只放一个请求查库，其余等待缓存结果：
async function getWithMutex(skuId) {
const key = `p:detail:${
skuId}`, lockKey = `lock:${
skuId}`;
let v = await redis.get(key);
if (v) return JSON.parse(v);
// 抢锁，只允许一个请求回源
const locked = await redis.set(lockKey, '1', 'NX', 'EX', 10);
if (locked) {
try {
const row = await db.queryProduct(skuId);
if (row) await redis.set(key, JSON.stringify(row), 'EX', ttlWithJitter(600));
return row;
} finally {
await redis.del(lockKey);
}
}
// 没抢到锁，短暂等待后重读缓存（双重检查）
await sleep(50);
v = await redis.get(key);
if (v) return JSON.parse(v);
return getWithMutex(skuId); // 有限次重试，避免死循环
}
热点 key 还有个更省心的办法是逻辑过期/永不过期 + 异步刷新：缓存不设物理 TTL，值里带逻辑过期时间，发现逻辑过期就先返回旧值、后台异步更新，用户全程无等待。
四、三件套之二：缓存雪崩——大量 key 同时过期
雪崩指大量缓存 key 在同一时刻集中失效（或 Redis 整体宕机），请求全部压向数据库。两个手段叠加：
4.1 TTL 加随机抖动，打散过期时间
function ttlWithJitter(base) {
return base + Math.floor(Math.random() * base * 0.2); // 基础值上加0~20%随机
}
这样原本都在 600 秒过期的 key 被打散到 600~720 秒，不会集体失效。
4.2 Redis 高可用 + 限流降级兜底
Redis 本身要做主从/哨兵/集群保证不整体挂；即使真的挂了，也要有本地缓存兜底、对数据库做限流、必要时返回兜底页，避免 DB 被连带打垮：
import random, time
def get_with_fallback(sku_id):
try:
return redis_get_or_load(sku_id)
except RedisError:
# Redis故障：本地缓存兜底 + 限流，保护数据库
local = local_cache.get(sku_id)
if local:
return local
if db_limiter.allow() is False:
return static_fallback_page(sku_id) # 兜底静态详情
return db_load(sku_id)
五、三件套之三：缓存穿透——请求的是根本不存在的数据
穿透指请求的商品在数据库里就不存在（恶意刷不存在的 skuId、或已下架商品），缓存永远不命中，每次都打到库。解法是缓存空值 + 布隆过滤器：
async function getWithBloom(skuId) {
// 布隆过滤器先判存在性，不存在直接挡掉，连Redis都不查
if (!bloomFilter.mightContain(skuId)) {
return null; // 判定一定不存在
}
const key = `p:detail:${
skuId}`;
let v = await redis.get(key);
if (v === '__NULL__') return null; // 命中空值缓存
if (v) return JSON.parse(v);
const row = await db.queryProduct(skuId);
// 即使查不到也缓存一个短TTL空值，挡住重复穿透
await redis.set(key, row ? JSON.stringify(row) : '__NULL__',
'EX', row ? ttlWithJitter(600) : 60);
return row;
}
布隆过滤器在商品上架时写入、下架时按需更新；空值缓存 TTL 要短（如 60 秒），避免商品刚上架仍被空值挡住。
六、五个真实踩坑清单
- 只上 Redis、不做本地缓存：热点 key 每次都要一次网络往返，Redis 一抖动整个详情页跟着慢。加一层秒级本地缓存能挡掉最尖的峰。
- 热点 key 用普通过期、没做互斥回源：过期瞬间并发全打到库，正是最需要保护的爆款反而最容易把库打穿，必须互斥锁或逻辑过期。
- TTL 统一写死 600 秒：批量预热的 key 同一时间过期，周期性雪崩。一定要在基础 TTL 上加随机抖动。
- 不缓存空值、不做布隆：被人用不存在的 skuId 一扫，缓存形同虚设、数据库全是无效查询。空值短缓存 + 布隆过滤器缺一不可。
- 缓存更新策略混乱，先改库还是先删缓存没定：并发下容易出现"缓存里永久是旧值"。详情这类场景推荐"更新数据库 + 删除缓存（Cache Aside）"，必要时用延迟双删，而不是同时写库又写缓存。
结语
商品详情页高并发读的核心，是用多级缓存把流量层层挡在数据库之外，再针对击穿、雪崩、穿透三种失效形态分别上锁：互斥回源/逻辑过期治击穿、随机 TTL 加高可用治雪崩、空值缓存加布隆过滤器治穿透。这套"多级 + 三件套"是通用范式，不绑定具体业务，任何读多写少、热点集中的场景都能套用。下一步建议在压测环境构造"热点 key 过期、批量 key 同时失效、大量不存在请求"三个用例，分别验证数据库 QPS 是否被压在安全线内，用数据确认每一层防护都真实生效。
