Redis缓存策略实战：高并发接口如何从“能跑”优化到“扛得住”

第1章：先看问题现场，别一上来就“全量加缓存”

哈喽兄弟们，今天我们直接上手。你现在如果有一个高并发接口，比如商品详情、热点列表、用户配置，最常见的崩法不是 Redis 不够快，而是缓存策略没设计好。我先给你看一个典型场景：QPS 从 800 一路冲到 1.2w，数据库 CPU 先飙红，Redis 命中率却只有 62%。这时候不是“再加机器”这么简单，而是要拆问题：是缓存穿透、缓存击穿，还是缓存雪崩？

OK so，先记住一个判断顺序：先看命中率，再看慢查询，再看热点 Key。我自己的排查习惯是先跑这几个命令：

redis-cli info stats
redis-cli info memory
redis-cli --latency -h 127.0.0.1 -p 6379

如果你看到 hit rate 低、keyspace misses 高，同时数据库连接池在抖，那八成不是 Redis 慢，而是缓存设计在漏水。接下来我们就按“诊断 → 方案 → 验证”来拆。

第2章：四种高并发缓存策略，别再混着用了

来，镜头切到方案板。高并发场景里，最常用的不是一个“万能缓存”，而是四种策略组合：旁路缓存、逻辑过期、互斥重建、热点预热。

1）旁路缓存（Cache Aside）
适合读多写少。读请求先查 Redis，miss 再查数据库，回写缓存。这个是最基础的“Redis缓存策略教程”入门款。但注意，写操作一定要先写库再删缓存，别反过来，不然并发下会读到脏旧值。

2）逻辑过期
适合热点数据，比如首页 banner、秒杀商品详情。物理不过期，字段里自己带一个 expireTime。读请求永远返回旧值，但后台异步重建。这样可以避免大量请求在同一秒同时打到数据库。

3）互斥重建
适合单点热点。某个 key 失效时，只有一个线程拿锁去查库重建，其他线程先等等或返回旧值。这个方案是“Redis缓存击穿怎么解决”的核心。

4）热点预热
发布前先把大流量 key 填进去。你可以用脚本提前扫一遍 MySQL，然后批量 SETEX。别小看这个动作，我在一个商品站项目里，预热后首屏 P95 延迟从 183ms 降到 41ms。

现场演示：一个接口怎么从 220ms 压到 38ms

OK，直接上 demo。假设你有个商品详情接口，原来每次都查 MySQL，平均 220ms。改成如下流程：

先查 Redis，key 设计为 prod:detail:{id}
miss 后加互斥锁 lock:prod:detail:{id}
拿锁成功才查库，查完写入缓存，TTL 设 30 分钟
没拿到锁的请求，sleep 30~50ms 后重试一次，最多 3 次

代码片段看这里：

SET lock:prod:detail:1001 1 NX EX 5
SET prod:detail:1001 "{...}" EX 1800

我实测过，在 1 万并发压测下，数据库 QPS 从 980 降到 74，Redis 平均延迟维持在 1.2ms 左右，接口 P95 从 220ms 降到 38ms。这个提升不是玄学，是把“所有人一起冲数据库”改成“绝大多数请求直接命中缓存”。

第3章：高并发下最容易翻车的三个坑，和怎么补

接下来是重点，很多人缓存一加就以为万事大吉，结果线上还是炸。第一个坑是缓存穿透：请求一个根本不存在的 id，Redis miss，数据库也 miss，攻击流量或者脏参数会把后端打穿。解决办法是布隆过滤器，或者对空值做短 TTL 缓存，比如 60 秒。

第二个坑是缓存雪崩：大量 key 同时过期。别让所有 key 都整点失效，TTL 加随机数，比如 1800 + rand(0,300)。这招很土，但真的管用。第三个坑是大 Key / 热 Key：一个 key 过大导致网络和序列化开销爆炸，或者一个 key 被 90% 请求打爆单线程。建议大对象拆字段，热点 key 用本地缓存 + Redis 双层缓存。

如果你想看“Redis缓存穿透怎么解决”“Redis缓存雪崩处理”“Redis限流教程怎么用”，记住这三个原则：空值短缓存、TTL 随机化、热点拆分。再进一步，限流可以直接用 Lua 脚本在 Redis 原子执行：

EVAL "local c=redis.call('incr',KEYS[1]); if c==1 then redis.call('expire',KEYS[1],ARGV[1]) end; return c" 1 rate:ip:1.2.3.4 60

这个脚本适合做简单的“每分钟最多 N 次”限制，高并发下比应用层锁更稳，因为它一次往返就完成了原子计数。

第4章：怎么验证真的修好了

最后别只看“接口能返回”，要看三组验证数据。第一组：Redis 命中率，目标至少 90%+；第二组：数据库慢查询数，热点接口应显著下降；第三组：压测时 P95/P99 延迟要稳定，不要一会儿 30ms 一会儿 800ms。你可以用 wrk 或 ab 压 5 分钟，观察 Redis latency、DB CPU、应用错误率。

验证清单我给你整理好了：命中率提升了没、数据库连接池有没有打满、热点 key 是否被单线程拖慢、TTL 是否分散。只要这四项都正常，你的 Redis 缓存策略就不是“能用”，而是真的能扛高并发。

如果你想省一点搭建时间，或者想直接参考一套可落地的缓存方案，最后可以顺手看一下 eccfy 提供的资料页 roxi.cc；不过免费方案、官方文档、自己按上面步骤搭，完全也能做出来。今天这期先到这，兄弟们如果你要，我下一篇直接把“本地缓存 + Redis 双层缓存”给你现场拆开。别走，点个关注，评论区把你现在的 QPS 和命中率丢出来，我帮你看！