缓存命中率 99%，接口还是慢
【摘要】 命中率 99% 看着放心，直到发现剩下那 1% 正好是首页最热的请求，每次回源 200ms。平均值看不出来，P99 看得出来。一、延迟按没命中的算平均延迟会骗人：99% 的请求 1ms、1% 的请求 200ms，平均只有 3ms，但每秒都有人在等 200ms。看 P99。回源成本 × miss 率才是缓存没省掉的部分：回源一次 50ms、命中率 95%，平均仍有 2.5ms 花在回源上；剩下...
命中率 99% 看着放心，直到发现剩下那 1% 正好是首页最热的请求，每次回源 200ms。平均值看不出来，P99 看得出来。
一、延迟按没命中的算
- 平均延迟会骗人：99% 的请求 1ms、1% 的请求 200ms，平均只有 3ms，但每秒都有人在等 200ms。看 P99。
- 回源成本 × miss 率才是缓存没省掉的部分：回源一次 50ms、命中率 95%，平均仍有 2.5ms 花在回源上；剩下 5% 的用户要等满 50ms。
- 穿透、击穿、雪崩是三件事：不存在的数据加空值缓存或布隆过滤器；热点 key 过期用互斥重建；大批 key 同时过期就加 TTL 随机、重启前预热。
判据：能说出 P99 里 miss 占多少、回源一次多久、下游扛不扛得住。
二、一致性靠兜底，不靠顺序
「先更新库还是先删缓存」能吵一下午，生产上真正管用的是兜底。
- Cache Aside：先更新数据库，再删缓存；删失败就重试。
- 延迟双删：先删缓存、更新库，隔几百毫秒再删一次，覆盖旧值写回的窗口。
- binlog 订阅 + TTL：变更由数据库顺序同步，TTL 兜住漏网之鱼，每类数据都有最长不一致时间。
判据：任何一类缓存数据，都能说出它最长可能旧多久。
三、容量问题别用代码解
- 先定淘汰策略：
noeviction写满就报错，allkeys-lru连热点也可能被淘汰，别用默认值。 - 大 key 卡实例、热 key 卡分片：拆 key、分批取；本地缓存或 key 打散，别把缓存当存储。
- 持久化和扩容都有代价：RDB fork、主从全量同步会带来延迟抖动，容量规划要留余量。
判据：内存水位、淘汰次数、大 key 数量都有阈值和告警。
落到华为云上：命中率、内存、连接数与淘汰次数看分布式缓存服务 DCS 的监控，大 key 与热 key 用 DCS 缓存分析扫；回源压力回云数据库 RDS for MySQL / TaurusDB 核对慢 SQL，用数据管理服务 DAS 看当前会话；缓存与数据库各占多少耗时从应用性能管理 APM 调用链拆；告警在云监控服务 CES 配。
一张表收尾
| 症状 | 通常是 | 先补这个 |
|---|---|---|
| 命中率高，P99 仍慢 | 慢在 miss 回源 | 优化回源 + 预热 |
| 数据时而新时而旧 | 更新与删除之间有窗口 | 删缓存 + TTL + binlog |
| 内存满后延迟抖动 | 淘汰频繁或大 key | 拆 key + 扩容 |
| 单分片 CPU 打满 | 热 key | 本地缓存 + key 打散 |
参考
- 华为云 · 分布式缓存服务 DCS
- 华为云 · 云数据库 RDS for MySQL
- 华为云 · 应用性能管理 APM
- 华为云 · 云监控服务 CES
- Redis 官方文档 · Key eviction
【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）