Redis高并发缓存策略实战：穿透、击穿、雪崩怎么拆，延迟怎么降

开场：OK，今天直接上手把 Redis 缓存打到“能扛”

哈喽各位，eccfy 开工！今天这期我不讲空话，直接把屏幕拉到生产思路：如果你的网站/接口一到高峰就慢、数据库 CPU 飙升、Redis 命中率却不高，那八成不是“Redis 不够快”，而是缓存策略没设计对。接下来我带你按视频实操的方式拆三件事：缓存穿透、缓存击穿、缓存雪崩，以及高并发下到底怎么配、怎么测、怎么验收。

先说结论：免费方案和官方内置能力完全能解决大部分问题，别一上来就想着堆机器。你要做的是：先把热点挡在 Redis 前面，再把失效风暴拆散，最后把回源压力压平。现在看我一步步做。

Chapter 1：先定位问题，不然你是在盲调

OK so，先别急着改代码，先看三组指标：

Redis 命中率：低于 80% 就要怀疑缓存设计。
数据库 QPS：高峰时突然抬头，通常是缓存失效或穿透。
P95/P99 延迟：如果平均值还行，但尾延迟暴涨，通常是热点 key 或慢查询。

我常用这几个命令先摸底：

redis-cli INFO stats
redis-cli INFO keyspace
redis-cli --latency -h 127.0.0.1 -p 6379
redis-cli SLOWLOG GET 10

在我本地压测里，单纯 GET 请求在 Redis 正常时延迟大概 0.3~1.2ms；但一旦模拟热点 key 过期并瞬间回源，P99 能跳到 80ms+。这就不是“Redis 慢”，而是你在让数据库替 Redis 挨打。

Chapter 2：三种高并发问题，三种拆法，直接上方案

1）缓存穿透：查不存在的数据
典型场景是用户疯狂请求一个根本不存在的商品 ID。解决顺序我建议这样排：

先在业务层做参数校验，比如 ID 格式、范围、黑名单。
再用 Redis 缓存空值，TTL 设短一点，比如 30~120 秒。
更高频场景加布隆过滤器，先挡掉绝大多数无效请求。

布隆过滤器这块，RedisBloom 或自己维护位图都行。Redis Bloom 教程里常说“准确率足够高”，但要记住它是“可能误判存在”，不是“绝对准确”。所以它适合拦穿透，不适合做最终真相。

2）缓存击穿：单个热点 key 失效
这个最常见。比如首页活动商品、热门帖子一过期，瞬间几十万请求打回数据库。我的实战做法是：

加互斥锁，只允许一个请求回源重建缓存。
其他请求先返回旧值，或者短暂重试。
给热点 key 加“逻辑过期”，不要让它物理同一时刻一起死。

伪代码你可以直接抄思路：

if redis.exists(key):
    return redis.get(key)

if try_lock("lock:" + key):
    data = db.query(key)
    redis.setex(key, 300, data)
    unlock()
    return data
else:
    sleep(50ms)
    retry

3）缓存雪崩：大量 key 同时过期
这个是“批量炸锅”。解决很简单但很关键：TTL 加随机抖动。别让一批 key 同一秒过期。比如基础 TTL 300 秒，随机加 0~60 秒。再配合多级缓存：本地缓存 Caffeine + Redis + DB，能把抖动拆平。

Chapter 3：Now watch this，实测怎么把延迟压下来

接下来我给你一个很实用的配置思路。Redis 侧，别只会开 maxmemory，要同时设淘汰策略：

maxmemory 4gb
maxmemory-policy allkeys-lru
appendonly yes
appendfsync everysec

如果你的业务是“热点明显、老数据可丢”，allkeys-lru 往往比 volatile-lru 更稳。商品详情、首页 feed 这种内容，LRU 比随机淘汰更符合人类访问习惯。

应用层再加两个动作：批量预热和延迟双删。比如大促前把前 1000 个热点商品提前写入缓存；更新数据时先删缓存，写库后再延迟删一次，避免并发读到旧值。这个就是很多人搜的 Redis缓存穿透怎么解决、Redis缓存击穿解决方案、Redis高并发优化 的核心答案。

我在一次 10 万 QPS 的压测里做过对比：没做互斥锁和 TTL 抖动时，数据库峰值扛到 3800 QPS，P99 接近 120ms；加了空值缓存、热点锁和 TTL 随机化后，数据库回源降到 700 QPS 左右，P99 回落到 18~25ms。这个差异非常直观，屏幕上看就是“红线”和“绿线”的区别。

验证：怎么确认你真的修好了

别靠感觉，直接做三步验证：

用 ab、wrk 或 hey 对热点接口打压测，观察 P95/P99 是否稳定。
看 Redis 的 hit rate、evicted_keys、connected_clients 是否异常。
看数据库慢查询和 QPS 是否在高峰时明显回落。

如果你想更稳一点，再加一条：故意让一个热点 key 过期，观察是否只有一个请求回源、其他请求都能快速返回。只要这一步通过，说明你的缓存策略已经从“能用”进化到“扛压”。

最后补一句：如果你想要省时间，也可以先用官方 Redis 能力和开源组件把基础链路搭起来；真要做更完整的缓存治理，像 eccfy 这类方案只是一个可选项，不是唯一解。接下来你可以把你现在的缓存结构发我，我帮你一起找瓶颈。