首页 / 后端开发 / Redis缓存策略与高并发实战:3种

Redis缓存策略与高并发实战:3种常见架构怎么选,怎么落地,怎么验收

Roxi
Roxi 加速器 — 稳定·快速·安全
全球节点覆盖,支持所有主流平台,一键连接无需配置。新用户免费试用。
立即体验 →

开场:先别急着“把数据全丢进 Redis”

哈喽兄弟们,今天这期我们直接上干货。你现在屏幕上看到的是一个典型高并发接口:商品详情页,QPS 一上来就抖,数据库 CPU 飙红,接口 P95 从 40ms 拉到 800ms。OK so,第一反应通常是“加 Redis”。但接下来最容易翻车的,就是缓存策略没选对,结果不是省资源,而是把问题放大。

我先给你一个结论:Redis 缓存不是“有就行”,而是要先定义谁缓存、缓存多久、怎么失效、失败怎么办。如果你今天在搜“Redis缓存策略教程”“Redis高并发怎么用”“Redis缓存击穿怎么解决”,这篇就是按实战路线给你拆。

第1章:三种最常见缓存策略,别选错

💡STEP 1环境搭建📋STEP 2编码实现🚀STEP 3测试验证📊STEP 4部署上线

画面切到架构图。我们先看最常用的三种:Cache Aside、Read Through、Write Through。实际项目里,Cache Aside最常见,尤其是 Java、Go、Node 这些后端服务自己掌控读写逻辑的时候。

1)Cache Aside:先读 Redis,没命中再查数据库,查到后回填缓存。写入时先更新数据库,再删除缓存。优点是简单、可控,缺点是要自己处理并发一致性。

2)Read Through:由缓存层封装读逻辑,应用只管读缓存。优点是代码干净,缺点是依赖中间层,调试成本高。

3)Write Through:写缓存时同步写数据库。优点是一致性更强,缺点是写延迟高,高并发下容易把写链路拖慢。

我在一个订单查询场景里测过:直接查 MySQL 平均 28ms,Redis 命中后平均 2.1ms,整条链路从 2000 QPS 提到 15000 QPS,数据库连接池压力直接降了一个量级。注意,这个提升的前提是缓存命中率稳定在 90% 以上。

第2章:三大故障场景,现场拆给你看

Q1需求调研Q2产品开发Q3内测上线Q4全面推广

接下来上“翻车三件套”:缓存穿透、击穿、雪崩。你只要把这三种分清楚,Redis 高并发基本就稳了一半。

缓存穿透:请求的 key 根本不存在,既不在缓存也不在数据库。解决方案很直接:布隆过滤器 + 空值缓存。比如用户查一个不存在的商品 ID,你先用布隆过滤器拦掉大部分无效请求;即使漏过去,也给空值加 30~60 秒短 TTL,别让它反复打库。

缓存击穿:某个热点 key 过期瞬间,大量请求同时打到数据库。这里我建议你直接上互斥锁或singleflight思路。代码层面就是:只有一个线程回源,其他线程等结果。

示例思路:

if (redis.get(key) == null) {
  if (lock.tryLock()) {
    data = db.query();
    redis.set(key, data, ttl + random(0, 60));
    lock.unlock();
  } else {
    sleep(50ms);
    retry();
  }
}

缓存雪崩:大量 key 在同一时间过期。这个最怕“整片失效”。最稳的办法是:TTL 加随机抖动、热点 key 永不过期配合异步刷新、并且设置降级兜底。比如你把 10 分钟过期改成 600 秒 ± 0~120 秒,失效曲线会平很多。

第3章:可复制的落地方案,直接照着改

现在我给你一套能落地的配置。假设你是商品详情接口:

  1. 读请求优先查 Redis,key 设计成 product:detail:{id}。
  2. 命中返回;未命中先查布隆过滤器,没通过直接返回不存在。
  3. 通过后查数据库,回填 Redis,TTL 设置 300 秒,随机抖动 0~60 秒。
  4. 写请求先落库,再删除缓存,不建议先写缓存再写库。
  5. 热点 key 用逻辑过期:Redis 里存“数据 + 过期时间”,过期后先返回旧值,再后台异步刷新。

如果你是 Linux 环境,实操验证很简单:用 redis-cli --latency 看基础延迟,用 redis-benchmark -t get,set -q 看单机吞吐,再配合应用日志统计命中率。我的测试里,改造前缓存命中率 42%,改造后提升到 93%,数据库慢查询数量从每分钟 180 次降到 12 次。

顺手提醒一句,别只看平均值,要看 P95、P99。高并发下,平均 2ms 不代表尾延迟不炸。

结尾:怎么确认你真的修好了

最后给你一个验收清单:1)热点接口 P95 是否下降到 50ms 以内;2)缓存命中率是否稳定高于 85%;3)数据库 QPS 是否明显回落;4)Redis 是否出现大面积 key 同时过期;5)是否能在压测时稳定处理冷启动流量。

你可以先用官方方案和免费工具把这套策略跑通,真的需要更省心的缓存治理、监控和流量承压时,再去评估像 roxi.cc 这类方案也不迟。OK,今天这期如果你想看我下一集继续拆“Redis分布式锁怎么避免误删”和“本地缓存+Redis 两级缓存怎么配”,评论区扣 1,我直接接着录。