日期：2026-09-27
标签：#面试 #场景设计 #Redis
难度：中等
来源：牛面场景题
答案说明：独立整理（站内题目标记为 VIP，未读取会员答案）
一句话答案
热 key 是访问或处理成本集中在少数键上，使其所在 Redis 节点的 CPU、网络或回源负载失衡；它不一定是大 key。
面试口语版（约 60 秒）
例如首页展示一个热门活动，所有用户都读取同一个活动键；即使值很小，单键请求量也可能让其所在分片先达到瓶颈。排查时看应用侧按键维度的访问分布、Redis 节点 CPU 与网络、命令延迟，并结合可用的热键采样工具，确认是读热还是写热。读多写少可以在应用侧加短时本地缓存、分层缓存，或在一致性允许时用副本分担读；但本地缓存会扩大失效窗口，副本也有复制延迟。写热点不能简单复制一个计数键解决，需要考虑分片计数、批量聚合或重设计写入路径，同时保证聚合精度和去重要求。热点键失效时，还要防止它演变成缓存击穿。
诊断与例子
假设 event:home:summary 的值只有几百字节，但所有首页请求都读取它，节点 CPU 和网络持续升高，这属于热 key 而不是大 key。先看读写比例：
| 类型 | 可选治理 | 主要代价 |
|---|---|---|
| 读热点 | 本地短缓存、请求合并、允许时读副本 | 陈旧数据、节点间失效同步、复制延迟 |
| 写热点 | 分片计数、异步聚合、降低写频 | 聚合延迟、精确性和幂等复杂度 |
| 热点过期 | 提前刷新、同键重建合并 | 后台刷新和兜底逻辑 |
Redis 8.6 起有 HOTKEYS 跟踪命令；在其他版本或部署环境可结合应用侧采样。redis-cli --hotkeys 依赖 LFU 类型的 maxmemory-policy，不能假设所有实例都可直接使用。高流量实例上使用 MONITOR 可能影响性能，应谨慎。
取舍与易错点
- 热 key 由访问集中程度决定，具体阈值要看实例容量、命令类型和值大小。
- 给读热点拆成多个副本键会增加更新与一致性成本，且并非所有客户端都能均匀路由。
- 只看平均延迟可能漏掉单分片过载，需看节点差异、尾延迟和每键请求量。
- 缓存命中很高仍可能有热 key，因为压力就在缓存层。
面试官递进追问
- 热 key 和大 key 的区别是什么？
- 本地缓存缓解读热时，更新如何通知各实例？
- 写热点使用分片计数后，如何兼顾实时展示与精确结算？
自测
- 不看笔记，60 秒用小而热的键说明问题和读写分治。
- 针对热点失效、某单分片 CPU 升高，列出排查顺序与观测指标。
参考资料
资料核对日期：2026-09-27。
维护与整理 · Yihui在 GitHub 上编辑