大厂面试必考场景题（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、场景题汇总：快速冲刺秋招专栏