数据开放服务 Redis 缓存架构设计：从腹稿到落地方案

数据开放服务平台对外提供大量只读/少写的查询接口，QPS 高、响应要求低延迟。Redis 是这类场景的标配。本文把一份「腹稿」推演成可落地的缓存架构方案。

一、为什么需要缓存

数据开放接口的痛点：

底层数据源（关系库/数仓）查询慢，直接打库扛不住高并发；
同一份数据被大量调用方重复查询，热点明显；
业务对响应时间敏感（P99 要求百毫秒级）。

Redis 内存读写、单线程模型避免了锁竞争，单机即可支撑十万级 QPS，是缓存层的最佳选择。

二、整体架构：多级缓存

复制代码

客户端 → CDN/网关
        → 应用本地缓存(Caffeine/Guava)   ← 进程内，最快，容量小
        → Redis 集群                     ← 分布式共享缓存，主力
        → 底层数据源(MySQL/数仓)         ← 兜底

多级缓存的价值：本地缓存挡住绝大部分重复请求，Redis 挡住跨进程热点，数据库只服务缓存未命中。任一层失效都有下一层兜底，避免雪崩直击数据库。

三、三大经典问题与对策

3.1 缓存穿透（查不存在的数据）

请求不断访问 DB 里根本没有 key，缓存永不命中，压力全到数据库。

布隆过滤器：在缓存前加 BloomFilter，不存在的 key 直接拦截；
空值缓存 ：查到空结果也写 key → null，设短过期（如 60s），防止同 key 反复穿透。

3.2 缓存击穿（热点 key 失效瞬间）

某个超级热点 key 过期瞬间，海量请求同时打到数据库。

互斥锁（mutex）：第一个线程查 DB 时加锁，其他线程等待重试缓存；
逻辑过期：value 里带过期时间戳，异步刷新，不真删除 key；
热点 key 永不过期 + 后台更新：极端热点由定时任务主动刷新。

3.3 缓存雪崩（大量 key 同时失效）

大量 key 同一时刻过期，或 Redis 宕机，请求全部涌向数据库。

过期时间加随机抖动 ：expire = base + random(0, 300s)，避免集体失效；
高可用：Redis 用哨兵或 Cluster，主挂自动切换；
限流降级：网关层对 DB 做并发限流，故障时返回兜底数据。

四、Key 设计与命名规范

text 复制代码

业务:模块:实体:id   例：open:dataset:meta:1024

带业务前缀，便于按前缀批量管理/淘汰；
避免过长（Redis key 也是内存开销）；
禁止用裸 id 当 key（易冲突）。

五、淘汰策略与内存控制

内存上限：设 maxmemory，如 8GB；
淘汰策略：allkeys-lru（所有 key LRU 淘汰）最常用；
大 key 拆分：单个 value 过大（如几 MB 的 JSON）会阻塞，拆成 hash 的多 field 或分页；
定期清理：无用 key 设合理 TTL，避免内存只增不减。

六、落地清单

确定缓存目标（哪些接口、预期 QPS、命中率目标）；
选型：单实例 / 主从 / Cluster（数据量大且要分片选 Cluster）；
设计 Key 规范与 TTL 策略（加抖动）；
实现三大问题防护（布隆 + 空值 + 互斥锁）；
接入监控：命中率、内存、慢查询、大 key 告警。

七、小结

Redis 缓存不是「加个 set/get」那么简单。一套能扛生产的架构，必须同时解决穿透、击穿、雪崩，并用多级缓存 + 高可用把数据库护在最后。方案文档就按「定位 → 架构 → 问题对策 → 规范 → 监控」这条线写，基本不会偏。

参考资料

Redis 官方文档
个人缓存架构设计笔记