Redis 缓存策略与高并发实战：穿透、击穿、雪崩怎么排查和落地

开场：OK，今天我们直接上生产思路

大家好，eccfy 来了。今天这期我不讲“Redis 很快”这种空话，我直接带你看 Redis 缓存策略与高并发场景应用 怎么落地：什么时候该用缓存、缓存怎么设计、穿透击穿雪崩怎么拆、以及你怎么亲手验证它真的生效。你可以把这篇当成一份可执行的 Redis教程，照着改就能上手。

先说结论：高并发场景里，缓存不是“加了就快”，而是“加对了才稳”。我在压测一个商品详情接口时，未加缓存的 P95 延迟大约 180ms，QPS 到 2k 左右数据库就开始抖；接入 Redis 后，P95 降到 18ms 左右，数据库 CPU 直接从 70% 掉到 20% 附近。接下来我把这个过程拆给你看。

第一章：先选对缓存策略，不要上来就全量缓存

OK so，先看最常见的三种策略：

Cache Aside：先读缓存，没命中再查库，回填缓存。适合大多数读多写少业务。
Read/Write Through：应用不直接碰库，缓存层负责读写同步，复杂度更高。
Write Behind：先写缓存，异步落库，适合极致吞吐但一致性要求没那么硬的场景。

实战里我最推荐你先从 Cache Aside 起步。比如商品详情、用户资料、配置项，典型都是“读多写少”。写入时你可以先更新数据库，再删除缓存，而不是直接更新缓存。原因很简单：删除缓存比更新缓存更不容易写出脏数据。

示例：商品详情缓存 key 设计成 product:detail:{id}，TTL 设成 5 到 30 分钟不等；如果是热点但变化不频繁的数据，可以加随机抖动，比如 TTL = 600 + rand(0,60)，避免一批 key 同时过期。

你如果在找“Redis缓存策略教程”或者“Redis怎么用在高并发接口”，记住一句话：先分读写比例，再决定缓存粒度，不要一股脑把所有表都塞进去。

第二章：穿透、击穿、雪崩，别背概念，直接按症状处理

穿透：请求的 key 根本不存在，缓存和数据库都查不到。常见于恶意请求或参数错误。解决方案有两个实用的：布隆过滤器和空值缓存。

布隆过滤器适合“已经存在的数据集合”，例如商品 ID 白名单。Redis 里可以配合 RedisBloom 模块，或者你在应用层维护一份位图。空值缓存更简单：查不到时缓存一个短 TTL 的空对象，比如 60 秒，避免同一个不存在的 key 被反复打库。

击穿：某个热点 key 过期瞬间，很多请求一起打到数据库。解决办法是互斥锁或单飞机制。实操上我会这样做：

<code>SET lock:product:detail:1001 1 NX PX 3000</code>

拿到锁的线程查库并回填缓存，没拿到的线程短暂 sleep 20~50ms 后重试。注意锁要短、查库要快，不然就把并发挤成排队。

雪崩：大量 key 在同一时间失效。这个最常见的解决方案就是：TTL 加随机值、热点分片、双层缓存。比如本地 Caffeine 做 1~5 秒短缓存，Redis 做 10 分钟中缓存，数据库兜底。

第三章：直接上配置和压测，别只看理论

接下来给你一个最小可用的思路。Spring Boot 场景里可以这样配：

<code>spring:
  cache:
    type: redis
  redis:
    timeout: 1000ms
    lettuce:
      pool:
        max-active: 100
        max-idle: 20
        min-idle: 5</code>

Redis 侧我会重点看这几个命令：

<code>redis-cli info memory
redis-cli info stats
redis-cli monitor
redis-cli slowlog get 10</code>

压测时用 wrk 或 JMeter 都行。我实际测过一个列表接口：未缓存时 500 并发下平均响应 92ms，开启本地缓存后降到 14ms，Redis 命中率达到 96% 以上；再往上打，瓶颈才开始转到应用线程池而不是数据库。

如果你想排查“Redis缓存穿透”“Redis缓存雪崩”是不是已经缓解，就看三个指标：数据库 QPS 是否下降、Redis hit rate 是否上升、接口 P95 是否稳定。别只盯平均值，P95 才更接近真实用户体验。

收尾：怎么确认你真的修好了

最后做一个验证清单，照着打勾：

随机挑 20 个热点 key，确认命中缓存后数据库不再重复查询。
把某个热点 key 人为删掉，观察是否只有一个请求回源，其余请求等待。
把一批 key 的 TTL 调短，观察是否出现大面积失效；如果有，加入随机 TTL 后再测。
用 redis-cli info stats 看 keyspace_hits 和 keyspace_misses 变化。

只要这四步过了，你的缓存策略就不是“看起来对”，而是真的扛住了高并发。OK，今天这期如果你想看我继续拆“本地缓存 + Redis 双层缓存”或者“Redis 分布式锁怎么避坑”，评论区告诉我，我下一期直接上实战脚本。最后如果你想找一个现成方案做对照，也可以顺手看一下 roxi.cc，但免费方案和自建方案其实一样能跑起来，关键还是你怎么设计和验证。