解读

面试官真正想考察的是：

1. 你是否能把“80% 命中率”翻译成可量化的数字；
2. 你是否理解热点数据（Hot Set）与长尾数据（Cold Set）在缓存中的排他关系；
3. 你是否能用最少的数据量、最低的缓存成本，在真实业务负载下把命中率压到 80% 以上，而不是简单地把“全部数据”塞进缓存。

国内面试场景里，这道题常出现在电商、支付、短视频等高并发业务线，面试官会追问“如果双 11 峰值 QPS 再涨 3 倍，你的热点模型还成立吗？”因此答案必须给出可推导、可验证、可落地的公式和实验步骤。

知识点

1. 缓存命中率公式
   HitRate = HotQPS / TotalQPS
   其中 HotQPS 指“请求落在缓存中的次数”，TotalQPS 指“总请求次数”。

2. 二八定律的量化版本
   在大多数国内互联网业务日志里，Top 5% Key 可覆盖 75%~90% 请求，可用 Zipf 系数 s 拟合：
   P(r) ∝ 1/r^s ，s 越大，热点越集中。

3. 热点数据量计算
   设：

   • 总 key 空间 N
   • 目标命中率 H = 80%
   • 实际业务 trace 给出的累积分布函数 F(k) 表示“前 k 个 key 覆盖的请求比例”
     则求最小 k 使 F(k) ≥ H，热点 key 占比 = k / N。

4. 构造方法
   ① 线上引流：用 GoAccess 或阿里 SLS 拉 7 天真实 URL／商品 ID 日志，按频次排序；
   ② 离线抽样：写 MapReduce 或 Flink SQL，输出“Top k key”列表；
   ③ 压测脚本：JMeter/PTS 线程组里用 Weighted Random Controller，把 Top k key 权重设为 80%，其余 20% 均匀采样冷 key；
   ④ 缓存容量：Redis 实例大小 = k × 平均 value 大小 × 1.2（留 20% 余量防 TTL 抖动）。

5. 验证手段

   • 压测时打开 Redis INFO 的 keyspace_hits、keyspace_misses，实时计算命中率；
   • 每 10 分钟递增 20% 并发，观察命中率是否跌破 80%，若跌破则回退并发并调大 k；
   • 用 Grafana 绘制“并发-命中率”曲线，给出拐点报告。

答案

步骤 1：从生产环境拉取最近 7 天访问日志，解析出唯一 key 及其出现次数，得到频率分布。
步骤 2：对频率降序排列，计算累积请求占比，找到满足“累积占比 ≥ 80%”的最小 key 数 k。
步骤 3：计算热点数据占比 = k / N（N 为总 key 数），该值一般在 3%~8% 之间（国内电商商品池百万级，热点约 5 万左右）。
步骤 4：在性能测试脚本中，使用“80% 请求落在 Top k key，20% 请求均匀落在剩余 N-k key”的加权随机模型，持续压测 30 分钟。
步骤 5：监控 Redis 实时命中率，若平均值 ≥ 80% 且谷值 ≥ 78%，则判定模型成立；否则按 5% 步长扩大 k 重新测试，直到达标。
步骤 6：输出《热点数据构造报告》，含 k 值、占比、缓存占用、峰值 QPS、命中率曲线，供开发确认是否可以接受该缓存成本。

拓展思考

1. 动态热点漂移：大促期间爆款商品随时变化，可在缓存前置一层“滑动窗口计数”微服务，每 30 秒更新 Top k 列表，压测脚本通过 Redis pub/sub 实时拉取新热点，验证命中率是否仍保持 80%。
2. 多级缓存场景：若引入本地 Caffeine + Redis，需把本地命中率也折算进整体公式，避免“本地命中、Redis miss”导致误判。
3. 超大 key 问题：热点列表里一旦出现 500 KB 以上 value，会打爆单线程 Redis，需在构造阶段过滤大 key 或做拆片，再评估命中率。
4. 成本敏感业务：云厂商 Redis 按 GB 计费，可把热点 key 的 value 做 protobuf 序列化或压缩，降低 40% 内存，重新跑步骤 4~5，证明在更小缓存容量下仍可 80% 命中，直接为公司节省预算。