京东毫秒级热key探测框架JD-hotkey

原创

已于 2025-07-29 16:08:52 修改 · 2.9k 阅读

32 ·

CC 4.0 BY-SA版权

文章标签：

#redis #java #JD-hotkey #热key

于 2024-11-03 23:20:22 首次发布

前言

对任意突发性的，无法预先感知的热点数据，包括热点数据（如突发大量请求同一个商品）、热用户（如恶意爬虫刷子）、热接口（突发海量请求同一个接口）等，一瞬间打到我们的服务器，这些突发的无法预先感知的压力，将会使我们系统潜在巨大风险。

譬如我们在Mysql之上做一层缓存，将数据存放在redis，那个未知的热数据会按照hash规则被存在于某个redis分片上，平时使用时都从该分片获取它的数据。由于redis性能还不错，再加上集群模式，每秒我们假设它能支撑20万次读取，这足以支持大部分的日常使用了。但是，以京东为例的这些头部互联网公司，动辄某个爆品，会瞬间引入每秒上百万甚至数百万的请求，当然流量多数会在几秒内就消失。但就是这短短的几秒的热key，就会瞬间造成其所在redis分片集群瘫痪。

原因也很简单，redis作为一个单线程的结构，所有的请求到来后都会去排队，当请求量远大于自身处理能力时，后面的请求会陷入等待、超时。由于该redis分片完全被这个key的请求给打满，导致该分片上所有其他数据操作都无法继续提供服务，也就是热key不仅仅影响自己，还会影响和它合租的数据。很显然，在这个极短的时间窗口内，我们是无法快速扩容10倍以上redis来支撑这个热点的。虽然redis已经很优秀，但面对这种场景时，往往也是redis成为最大的瓶颈。

譬如我们在Redis之上再做一层JVM的缓存，先访问JVM的缓存，数据不存在，我们再从Redis中获取数据，如果 Redis 中的数据也不存在的话，最后才从Mysql 中获取数据。但有个问题，对任意突发性的，无法预先感知的热点数据，我们将什么数据放在JVM缓存呢？

对于这个问题，JD-hotkey 提供了一整套解决方案，我们可以直接使用这个框架来解决我们的问题。

JD-hotkey 框架介绍

JD-hotkey 项目地址

在经历了多次被突发海量请求压垮数据层服务的场景，并时刻面临大量的爬虫刷子机器人用户的请求，京东根据既有经验设计开发了一套通用轻量级热key探测框架——JdHotkey。

它很轻量级，既不改redis源码也不改redis的客户端jar包，当然，它与redis没一点关系，完全不依赖redis。它是一个独立的系统，部署后，在server代码里引入jar，之后就像使用一个本地的HashMap一样来使用它即可。

框架自身会完成一切，包括对待测key的上报，对热key的推送，本地热key的缓存，过期、淘汰策略等等。框架会告诉你，它是不是个热key，其他的逻辑交给你自己去实现即可。

它有很强的实时性，默认情况下，500ms即可探测出待测key是否热key，是热key它就会进到jvm内存中。当然，我们也提供了更快频率的设置方式，通常如果非极端场景，建议保持默认值就好，更高的频率带来了更大的资源消耗。

它有着强悍的性能表现，一台8核8G的机器，在承担该框架热key探测计算任务时（即下面架构图里的worker服务），每秒可以处理来自于数千台服务器发来的高达16万个的待测key，8核单机吞吐量在16万，16核机器每秒可达30万以上探测量，当然前提是cpu很稳定。高性能代表了低成本，所以我们就可以仅仅采用10台机器，即可完成每秒近300万次的key探测任务，一旦找到了热key，那该数据的访问耗时就和redis不在一个数量级了。如果是加redis集群呢？把QPS从20万提升到200万，我们又需要扩充多少台服务器呢？

JD-hotkey 核心结构

1、etcd集群

etcd作为一个高性能的配置中心，可以以极小的资源占用，提供高效的监听订阅服务。主要用于存放规则配置，各worker的ip地址，以及探测出的热key、手工添加的热key等。

2、client端jar包

就是在服务中添加的引用jar，引入后，就可以以便捷的方式去判断某key是否热key。同时，该jar完成了key上报、监听etcd里的rule变化、worker信息变化、热key变化，对热key进行本地caffeine缓存等。

3、worker端集群

worker端是一个独立部署的Java程序，启动后会连接etcd，并定期上报自己的ip信息，供client端获取地址并进行长连接。之后，主要就是对各个client发来的待测key进行累加计算，当达到etcd里设定的rule阈值后，将热key推送到各个client。

4、dashboard控制台

控制台是一个带可视化界面的Java程序，也是连接到etcd，之后在控制台设置各个APP的key规则，譬如2秒出现20次算热key。然后当worker探测出来热key后，会将key发往etcd，dashboard也会监听热key信息，进行入库保存记录。同时，dashboard也可以手工添加、删除热key，供各个client端监听。