大厂面试必考场景题（1）：Redis hot key问题
一、Redis 热 key：互联网平台的 “流量噩梦”
在电商秒杀、爆款商品上线等场景中，海量用户请求会瞬间集中涌向存储对应信息的单个 Redis 节点，这就是 Redis 热 key 问题。就像一座设计合理的桥梁，某一车道突然涌入 100 万辆车，不仅会导致该车道瘫痪，还可能引发整座桥梁坍塌 —— 热 key 带来的连锁反应远比想象中严重：
- 数据层面：承载热 key 的 Redis 节点因过载被打挂后，其负责的缓存数据全部丢失，进而引发可怕的缓存雪崩；
- 应用层面：用户持续刷新却无法加载页面，服务直接陷入不可用状态，严重影响用户体验与业务连续性。
很多人会误以为 “简单扩容就能解决问题”，但实际这是一个典型误区。原因有三：一是热点具有突发性，扩容根本来不及响应；二是热点是动态变化的，今天的爆款可能并非明天的焦点；三是全节点冗余扩容的成本极高，完全不切实际。
二、解决方案的底层逻辑：热点探测 + 本地缓存
尽管三大厂的实现路径不同，但所有高效解决方案的核心都遵循统一底层逻辑，可拆解为两个关键组件：
- 热点探测（Hot Spot Detection）：如同 “侦探” 一般，实时、准确识别出被高频访问的热 key，这是解决问题的前提；
- 本地缓存（Local Cache）：一旦探测到热 key，就将对应数据缓存到应用服务器自身内存（如 JVM）中。相当于在 “中央仓库”（Redis 集群）之外，在路边搭建 “小粮仓”，让大部分请求无需挤向已过载的 Redis 节点，从源头分流流量。
但要落地这个核心逻辑，需攻克四个尖锐难题：
- 内存约束：客户端内存有限，无法缓存所有 key，需在有限空间内服务更多用户；
- 实时性要求：热点瞬息万变，必须在 Redis 被打垮前完成探测与缓存；
- 数据一致性：本地缓存与 Redis 主库数据需同步，避免出现 “旧数据” 问题；
- 资源效率：热点探测本身不能耗费过多 CPU、内存或网络资源，否则得不偿失。
三、三大厂的差异化实现：三种路径，三种取舍
京东、得物、B 站围绕 “热点探测 + 本地缓存” 核心，结合自身业务场景与技术优势，走出了三条截然不同的路径，分别代表 “中央聚合”“内核改造”“智能客户端” 三种设计哲学。
（一）京东：中央聚合模式 —— 建立 “全局热点情报局”
京东的核心思路是部署独立的 worker 计算集群，作为 “大脑中枢” 专门负责热点识别与指令下发，相当于建立了一个 “全局热点情报局”。
- 实现流程：
- 所有客户端悄悄记录 key 的访问信息，异步汇总到 worker 集群；
- worker 集群通过滑动窗口算法，实时统计 key 的访问频率，精准筛选出 Top K 热 key；
- 通过长连接将热 key 信息快速推送给所有客户端实例，客户端立即更新本地缓存。
- 核心优势：全局视野：能捕捉全网访问数据，热点识别精度最高；实时性极强：探测 + 推送全流程可在 500ms 内完成；高并发支撑：单台 worker 每秒可处理 15 万个请求，适配大规模流量场景。
- 潜在代价：系统复杂度高：需额外维护 worker 集群与协调系统（如 etcd），运维成本上升；业务侵入性：客户端需集成特定 SDK，对业务代码有一定影响。
（二）得物：内核改造模式 —— 让 Redis “自己报信”
得物的思路更为根本：直接改造 Redis 内核，让 Redis 服务器自身具备热点探测与广播能力，无需额外依赖外部组件。
- 实现流程：
- Redis 内部通过固定大小的 LRU 队列，统计单位时间（如 1 秒）内每个 key 的访问次数；
- 当访问次数达到预设阈值，Redis 直接判定该 key 为热 key；
- 通过 Redis 原生的发布订阅机制，将热 key 信息通过专属 channel 广播；
- 客户端或代理程序提前订阅该 channel，收到广播后立即更新本地缓存。
- 核心优势：零侵入性：业务代码无需任何修改，对业务方完全透明；实时性强：探测在 Redis 内部完成，统计粒度可达秒级；资源开销低：仅依赖 Redis 内部小巧的数据结构，内存占用少。
- 潜在代价：技术门槛极高：需自主开发、维护定制版 Redis，对内核研发能力要求苛刻；长期维护成本高：定制化 Redis 需适配官方版本迭代，兼容性与稳定性保障难度大，非普通团队可驾驭。
（三）B 站：智能客户端模式 —— 让每个 “士兵” 自带 “雷达”
B 站的核心是将热点探测逻辑拆分并下沉到每个应用实例，让客户端 SDK 自带 “热点探测器”，相当于让每个 “士兵” 都能自主侦测 “敌人”（热点）。
- 实现流程：
- 每个应用实例通过Heavy Keeper 算法自主识别热点；
- 该算法类似布隆过滤器，通过多维数组 + 多哈希函数 + 计数器衰减机制，在牺牲微小准确性的前提下，实现高效热点识别 —— 高频 key 被坚定保留，低频 key 被快速淘汰；
- 实例识别出热 key 后，直接缓存到本地内存，无需依赖外部集群。
- 核心优势：接入成本极低：无需部署额外服务，无需修改 Redis 源码，仅升级客户端 SDK 即可；资源效率极高：仅需几 MB 内存就能实现高效统计，日常高峰期本地缓存命中率可达 35%；适配大规模部署：轻量设计适合成千上万台服务器的分布式场景。
- 潜在代价：缺乏全局视野：每个实例仅能感知自身流量，若全局热点流量被均匀分散到多台服务器，单实例的访问频率可能未达阈值，导致热点漏判；准确性略有牺牲：算法允许微小误差，可能误判部分低频 key，但整体不影响核心场景。
四、方案对比与选型建议：没有银弹，只有适配
三大厂的方案没有绝对的优劣之分，本质是在 “准确性、实时性、一致性、成本” 之间的权衡取舍。以下是核心维度对比与选型建议：
核心优势 | 全局视野、实时性强、高并发支撑 | 零侵入、实时性强、资源开销低 | 接入成本低、资源效率高、易部署 |
主要劣势 | 复杂度高、运维成本高、有侵入性 | 技术门槛高、维护成本高 | 可能漏判全局热点、准确性略低 |
适用场景 | 对热点准确性 / 实时性要求极高、能承担运维成本的大规模电商场景 | 追求方案优雅、有强大内核研发团队的中大型企业 | 快速落地、成本敏感、分布式规模大的互联网平台 |
选型核心建议：
- 若需极致准确与实时，且不在乎运维成本 —— 选京东模式；
- 若追求零侵入与方案优雅，且具备 Redis 内核研发能力 —— 选得物模式；
- 若需快速落地、控制成本，且能接受轻微漏判 —— 选 B 站模式。
五、总结：热 key 问题的本质是 “流量分流与效率平衡”
Redis 热 key 问题的核心矛盾，是 “集中式存储” 与 “分布式流量” 的不匹配。三大厂的解决方案虽路径不同，但都抓住了 “分流” 与 “平衡” 两个关键：通过热点探测精准识别流量焦点，通过本地缓存实现流量分流，同时在技术成本与业务需求之间找到最优解。
没有能解决所有问题的 “银弹”，最终选型需回归自身团队能力、业务优先级与成本预算 —— 适合自己的，才是最好的解决方案。
六、原文链接
京东零售技术微信公众号：https://mp.weixin.qq.com/s/xOzEj5HtCeh_ezHDPHw6Jw 得物技术微信公众号：https://mp.weixin.qq.com/s/RWQzLZq6X7B5ThaKX6U4SQ 哔哩哔哩技术微信公众号：https://mp.weixin.qq.com/s/C8CI-1DDiQ4BC_LaMaeDBg
七、其他
我在牛客也写了一些java学习和求职的经验帖子，大家可以去看看：
想要学习Java冲实习或冲春招的，我能助你一臂之力，我之前整理了高质量可速成的魔改外卖项目话术和7000字轮子项目话术，还有超全超精品八股大全专栏，怎么写简历，怎么包装实习经历，怎么0基础速成冲春招和实习等等精品帖子，大家可以去看看我的精品文章汇总帖子：往期精品秋招帖子汇总
我的八股大全、算法、项目话术全专栏（20w人学习，超千人订阅，牛客最受欢迎最高质量java八股专栏，内容包含： 1.八股大全：多一句没有少一句不行的最精简八股整理，完全可以应付校招社招的八股拷打！ 2.速成项目话术：目前有魔改苍穹外卖项目话术（额外扩展了很多技术亮点），能速成拿去面试，后面会更新魔改黑马点评、商城项目等等热门高质量项目话术 3.智力题超详细题解汇总； 4.面试时非技术问题话术整理，绝对震惊面试官一年； 5.算法lc hot100全题系列题解：绝对通俗易懂；6、场景题汇总：快速冲刺秋招专栏
