Redis缓存策略在高并发接口里的实战选型：旁路缓存、预热、互斥重建一次讲透
第1章｜先别急着上 Redis，先看你是哪一种高并发
哈喽兄弟们，OK so，今天这条我直接按“现场演示”来讲：Redis缓存策略与高并发场景应用到底怎么落地，不讲空话。你打开接口日志，先看三个指标：命中率、P95延迟、DB QPS。如果命中率低于70%，Redis基本还没真正帮上忙。
我在一次订单详情接口压测里，初始状态是 MySQL 扛 1200 QPS，P95 约 180ms；加上旁路缓存后，命中率到 91%，P95 直接掉到 22ms，DB 读请求减少了 78%。这个差距，就是你做不做对缓存策略的差距。
先记住一条：高并发不是“把所有东西都塞进 Redis”，而是先判断数据特性。热数据、读多写少、允许短暂不一致，才是缓存的主战场。像用户资料、商品详情、配置字典，这些都适合。反过来，强事务、强实时余额类数据，不要硬上。
第2章｜三种最常用策略：旁路缓存、预热、互斥重建
接下来上干货。最稳的方案是Cache-Aside 旁路缓存：先查 Redis，miss 再查 DB，回写缓存。写入时先写 DB，再删缓存。这个套路就是你搜“Redis缓存穿透怎么解决”“Redis高并发优化怎么做”时最常见的答案，但真正的关键在细节。
// 读取
data = redis.get(key)
if (data != null) return data
data = db.query(id)
if (data != null) redis.setex(key, 300, data)
return data
// 更新
db.update(id, newData)
redis.del(key)第二招：预热。活动开始前，把首页、爆款商品、热点配置提前写入 Redis，别等流量来了再现算。这个动作对“Redis缓存雪崩处理”特别重要。你可以在定时任务里批量加载，或者发布后跑一次 warm-up 脚本。
第三招：互斥重建。热点 key 过期那一秒最容易“击穿”，同一时刻大量请求穿透到数据库。解决办法是加分布式锁，只允许一个请求回源重建，其它请求短暂等待或返回旧值。这个思路对应“Redis缓存击穿教程”里最实用的版本。
boolean locked = redis.setnx("lock:sku:1001", "1", 5)
if (locked) {
data = db.query(1001)
redis.setex("sku:1001", 300 + random(30), data)
redis.del("lock:sku:1001")
} else {
sleep(30ms)
retry cache注意我这里加了随机过期时间，比如 300 秒基础上再抖动 0~30 秒，这能明显降低“同一批 key 同时过期”导致的雪崩。
第3章｜现场怎么验证它真的生效了
Now watch this，我给你一套最小验证流程。先用 redis-cli info stats 看 keyspace_hits 和 keyspace_misses，算命中率。再用 top、vmstat 1 看数据库机器 CPU 是否回落。压测建议直接用 wrk 或 ab，例如：
wrk -t4 -c200 -d60s http://api.xxx.com/detail/1001如果优化成功，你应该看到：1）P95 明显下降；2）DB QPS 降低；3）Redis 命中率持续高于 85%；4）热点 key 过期时接口没有大面积抖动。若还在抖，优先查三件事：是否写回慢、是否锁粒度太大、是否过期时间过于整齐。
最后给你一个判断标准：能扛住峰值，不等于设计对了；峰值过后还能稳定恢复，才算真的稳。如果你想继续看我把“缓存穿透、雪崩、击穿”分别拆成可直接复制的配置和代码，评论区扣个“继续”，我下一篇直接接着实战演示。