项目介绍

京东 App 后台中间件，毫秒级探测热点数据，毫秒级推送至服务器集群内存，大幅降低热 key 对数据层查询压力。

对任意突发性的无法预先感知的热点请求，包括并不限于热点数据（如突发大量请求同一个商品）、热用户（如爬虫、刷子）、热接口（突发海量请求同一个接口）等，进行毫秒级精准探测到。然后对这些热数据、热用户等，推送到该应用部署的所有机器 JVM 内存中，以大幅减轻对后端数据存储层的冲击，并可以由客户端决定如何使用这些热 key（譬如对热商品做本地缓存、对热用户进行拒绝访问、对热接口进行熔断或返回默认值）。这些热 key 在整个应用集群内保持一致性。

核心功能：热数据探测并推送至集群各个服务器

适用场景：

• mysql 热数据本地缓存
• redis 热数据本地缓存
• 黑名单用户本地缓存
• 爬虫用户限流
• 接口、用户维度限流
• 单机接口、用户维度限流限流
• 集群用户维度限流
• 集群接口维度限流

性能指标

该框架历经多次压测，性能指标主要有两个：

探测性能： 8 核单机 worker 端每秒可接收处理 16 万个 key 探测任务，16 核单机至少每秒平稳处理 30 万以上，实际压测达到 37 万，CPU 平稳支撑，框架无异常。

推送性能： 在高并发写入的同时，对外推送目前性能约平稳推送每秒 10-12 万次，譬如有 1 千台 server，一台 worker 上每秒产生了 100 个热 key，那么这 1 秒会平稳推送 100 * 1000 = 10 万次，10 万次推送会明确在 1s 内全部送达。如果是写入少，推送多，以纯推送来计数的话，该框架每秒可稳定对外推送 40-60 万次平稳，80 万次极限可撑几秒。

实战检验

京东 APP 后台热数据探测框架，历经多次高压压测和 2020 年京东 618、双 11 大促考验。

在上线运行的这段时间内，每天探测的 key 数量数十亿计，精准捕获了大量爬虫、刷子用户，另准确探测大量热门商品并毫秒级推送到各个服务端内存，大幅降低了热数据对数据层的查询压力，提升了应用性能。

在大促期间，hotkey 的 worker 集群秒级吞吐量达到 1500 万级别，由 hotkey 探测出的热 key 进而产生的本地缓存占应用总访问量的 50%以上，使得大部分请求进行的是本地查询，减轻了 redis 层一半以上负担。

架构设计

该框架没有依赖于任何定制化的组件，与 redis 更是毫无关系，核心就是靠 netty 连接，client 端送出待测 key，然后由各个 worker 完成分布式计算，算出热 key 后，就直接推送到 client 端，非常轻量级。

该框架主要由 4 个部分组成：

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

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

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

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

项目地址

https://gitee.com/jd-platform-opensource/hotkey