面试官：“你们系统的缓存命中率是多少？如果低于 90%，你是怎么优化的？”

公众号名称：Fox爱分享

作者名称：Fox爱分享

发布时间：2026-05-20 07:00

写在开头

很多兄弟在写简历时，总喜欢往上堆技术栈：“熟练使用 Redis，熟悉各种数据结构”。

面试官稍微往下探一步：“那你们生产环境 Redis 的日常命中率是多少？”

这时候，90% 的人会愣住。平时只管用 RedisTemplate 调 get/set，只要配好 application.yml，服务能跑通就谢天谢地了，谁还去看监控面板？

但在高端局面试官眼里，脱离了“命中率”谈缓存，纯属耍流氓。

如果你们系统的缓存命中率只有 30%，这意味着什么？意味着 70% 的并发流量像利剑一样直接穿透了缓存层，狠狠扎在底层数据库上。这时候 Redis 不仅没帮你扛并发，反而让整个调用链路多了一次无意义的网络 I/O 开销，纯属“占着茅坑不拉屎”。

真实的面试博弈往往是这样的：

面试官：“如果缓存命中率低于 90%，你作为核心开发是怎么排查和优化的？”

小白（支支吾吾）：“额……没怎么关注过，我们系统平时用着感觉挺快的……”（典型的 CRUD 思维，直接被 Pass）

老鸟（稳如老狗）：“我们核心业务的基准线是 99%，普通业务保底 90%。针对长尾数据造成的 Cache Churn（缓存抖动），我曾通过‘多级缓存架构 + 淘汰策略降维打击’，把一个推荐系统的命中率从 75% 强行拉升到了 95% 以上。”

今天咱们不搞虚的，直接扒开底层，手撕这个高并发架构下的“深水区”难题。

一、拒绝“体感”，拿指标砸人

优化之前，先得有监控。别跟面试官扯“我觉得”，要拿真实数据说话。

核心公式：

$$ 命中率 = 缓存命中次数 (Hits) / [ 缓存命中次数 (Hits) + 缓存未命中次数 (Misses) ] $$

实战摸底：

直接连上 Redis 节点，敲一个 INFO stats 命令，照妖镜就出来了：

127.0.0.1:6379> INFO stats
# Stats
keyspace_hits: 145032    # 命中了 145032 次
keyspace_misses: 3401    # 穿透了 3401 次

算一笔账：145032 / (145032 + 3401) ≈ 97.7%。在生产环境，这个数据是能拿出来吹牛的。但如果你算出来只有 50% 甚至更低，那你得赶紧复盘了，底层的 MySQL 可能正处在崩溃的边缘。

二、提升命中率的 5 套“硬核连招”

如果你接手了一个命中率惨不忍睹的系统，别慌。排查无非三个方向：内存被挤爆了、数据过期太频繁、Key 的粒度设计太业余。直接上这套连招：

1. 缓存预热 (Pre-warming)：拒绝让首批用户当“炮灰”

痛点： 系统刚发版重启，或者大促秒杀刚开启，Redis 里是空的。此时洪峰流量涌入，产生经典的“冷启动击穿”，命中率瞬间跌零。
解法：
静态字典/配置： 利用 Spring 的 ApplicationRunner，系统启动时利用后台线程全量刷入缓存。
热点业务数据： 通过 Canal 监听 Binlog 异步预热，或者每天凌晨跑大数据离线任务，算出 Top 1000 的活跃商品，提前推送到 Redis。别等用户去查了你再存。

2. 粒度重塑 (Granularity)：拆解大对象，降低失效频次

痛点： 图省事，直接把一个几十个字段的完整 User 实体序列化成 JSON 塞进缓存。但大部分 C 端接口其实只需要 nickname 和 avatar。一旦用户修改了“最后登录时间”这种高频但边缘的字段，整个庞大的缓存就得面临失效或更新，命中率自然上不去，还会引发大 Key 阻塞问题。
解法：
拆粒度！把大对象拆成细粒度的小 Key，或者用 Hash 结构分片存储。
架构铁律：对象越庞大，更新越频繁，命中率就越低。 内存很贵，只缓存高频读取的核心字段。

3. 淘汰策略切换：从 LRU 到 LFU 的降维打击

痛点： 内存是有限的（比如只给了 4GB），但业务数据有几十 GB。在传统的 LRU（最近最少使用）算法下，只要有运营在后台跑了一次“全表扫描”导出报表，或者有爬虫来遍历你的历史文章，产生的大量“一次性冷数据”就会把真正的核心热点数据全部踢出内存。
解法：
把 maxmemory-policy 升级为 allkeys-lfu（Redis 4.0+ 引入）。
底层逻辑： LFU（Least Frequently Used）认的是“访问频率”而不是单纯的“最后访问时间”。它内部维护了一个基于概率的对数计数器（Morris Counter），能精准识别出谁才是“长期热点”。这就彻底阻断了冷门数据偶尔被访问一次就鸠占鹊巢的可能。

4. TTL 柔性控制：拒绝“一刀切”导致的集中雪崩

痛点： 为了省事，所有业务缓存的过期时间统一设为 5 分钟。结果热点数据每到 5 分钟就必须回源一次 DB，导致命中率永远被一个天花板压制。
解法： 打散 TTL，实施分层防御。
不变的元数据： TTL 设为 24 小时或半永久。
高频突发热点： 采用逻辑过期。不设置物理的 expire time，而是在 Value 里封装一个过期时间戳。前端拿到数据后，如果发现逻辑时间已过期，直接返回老数据保底，同时利用线程池异步去 DB 拉取新数据更新缓存。
常规业务数据：TTL = 基础时间 + 随机扰动值，防止同时失效。

5. 引入本地缓存 (Local Cache)：终极防御塔

痛点： 面对千万级 QPS 的秒杀（如抢茅台），Redis 性能再被榨干，也绕不开千兆网卡的 I/O 瓶颈和序列化开销。
解法： Caffeine / Guava 构筑 L1 级应用内缓存。
在 JVM 层面直接拦截掉 60% 的读请求。虽然这部分流量没有打到 Redis（不算 Redis 的监控命中），但站在整体架构的高度，这属于“缓存体系”的 100% 命中。没有网络开销，直读内存，真正的降维打击。

三、真实生产复盘：从 75% 到 95% 的绝地反击

某资讯类 App 的“推荐信息流”接口，QPS 峰值 5000+。监控告警显示 Redis 命中率长期在 75% 的死亡线上挣扎，数据库 CPU 动不动飙红。

排查与架构调整：

数据抓轨，定位元凶： 团队通过分析 Redis 的慢日志和 keyspace_misses 指标，发现罪魁祸首是海量的“长尾内容”（比如 3 年前的老新闻）。这些文章单篇访问极低，但由于基数庞大，严重挤占了内存，把“今日头条”全给挤出去了。
第一刀：淘汰策略洗牌： 连夜将淘汰策略从 volatile-lru 切换至 allkeys-lfu。LFU 瞬间发威，由于老新闻的累积访问频率极低，很快被系统自动清理。命中率当场回血至 82%。
第二刀：Caffeine 多级拦截： 针对算法推荐出来的 Top 100 爆款文章，我们在 JVM 层面强加了 10 秒的极短 Caffeine 缓存。这招直接让 Redis 的 QPS 腰斩 30%，整体接口 TP99 延迟直线下降。
第三刀：智能续命 (Read Prolongation)： 修改了底层的分布式缓存组件——每次从 Redis 命中高频数据时，如果发现 TTL 剩余生命周期不足 20%，直接发个异步消息，给它自动“续命”一倍时间。只要文章还在被频繁点击，它就永远不下线。

最终战果： Redis 命中率死死焊在 95% 以上，数据库负载从 80% 断崖式跌落到 10% 以内。

四、面试绝杀话术

下次在面试场上遇到这个问题，不要慌，按照这个思路直接输出：

“我认为缓存命中率是评估整个后端架构抗压能力的晴雨表。在我的项目经验中，通常把 90% 设为及格线，核心高并发接口追求 99% 以上。

针对命中率低下，我通常会从三个维度进行架构重构：

第一是提前防御。系统启动或大促前，我会通过异步任务做全量预热，防止冷启动击穿；面对超高并发，我会引入 Caffeine 搭建多级缓存，在应用层就将洪峰流量拦截掉。

第二是精细化控制。我会重构对象的存储粒度，拒绝无效大字段挤占内存。同时摒弃‘一刀切’的 TTL 配置，对高并发的热点数据采用逻辑过期或者**读延期（动态滑动续命）**策略，确保热点永不掉线。

第三是底层策略调优。如果排查出是海量长尾数据造成的 Cache Churn，我会果断将 Redis 的淘汰策略从 LRU 升级为 LFU。利用 LFU 访问频率计数的特性，防止真正的长期热点被一次性离线任务或爬虫恶意挤出内存。

总结来说，单纯的加内存是掩耳盗铃。提高命中率的核心，是利用架构手段让高价值数据在有限的内存里**‘少进多出’**。”

满大街吃灰资料改不了底薪，看透业务本质的架构思维，才能真正决定职业上限。

我是Fox。不堆砌无用资料，只带你死磕书本里没有的实战硬坑。

觉得今天这篇硬核拆解对你有启发，拒绝白嫖，顺手点个赞和在看。

关注公众号**【Fox 爱分享】**，吃透底层架构，技术面试一路畅通！

cover_image

原创 Fox爱分享 Fox爱分享

内容效果不满意？点此反馈