热点 key 与多级缓存：扛住明星结婚
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 2 · 缓存体系 · 第 14/49 篇 · 🚧 占位待学
上一篇：《缓存一致性：延迟双删、订阅 binlog 与最终一致》
下一篇：《同步链路的天花板：级联失败与延迟叠加》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 2 · 单元 2.6
一、本文要解决的问题
明星官宣结婚，一条热搜的 key 被百万 QPS 打——单个 Redis 分片扛不住，整个集群也没用，因为同一个 key 只会落在一个分片上。热点 key 的解法是把「一份热数据」复制成「很多份」，靠近应用的地方挡掉绝大部分流量。
二、知识点清单
- 热点 key 的三来源：突发热点（官宣）、常态热点（首页商品）、批量热点（活动页全部 key）
- 热点探测：Redis hotkey 命令、客户端埋点统计、代理层统计
- 本地缓存 Caffeine：W-TinyLFU 淘汰算法概览、与 Redis 组成 L1 / L2 两级架构
- 热点 key 拆分复制：key 加随机后缀散到多个 Redis 分片，读端随机选一（写端写全部）
- 主动刷新 vs 被动过期：热数据的「逻辑过期 + 后台异步刷新」组合
- Redis 单线程与 10 万 QPS 的量级认知：什么时候单分片先死
三、动手实验（学习时必须真跑）
- 纯 Redis 版接口压测出基线（观察 Redis 实例 CPU）
- 加 Caffeine 本地缓存（L1），重复压测：对比 L1 命中路径与 Redis 路径的 QPS 差距（数量级）
- 实现热点 key 后缀拆分（key_0 ~ key_7 散 8 个分片），压测验证单分片压力下降
四、验收标准（全部通过才进入下一篇）
五、阶段验收（本篇是阶段 2收尾篇）
六、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。