霍利斯，对编码有独特追求的人
这是Hollis的300篇原创份额
作者l Hollis
源Lhollis(id:HollisChuang ) ) )。
对于大规模的分布式系统来说，热点数据一直是值得关注的事情，如热点商品、热点新闻等都是热点数据。
通常情况下，这种热点数据都会被放在缓存里面尽管如此，大量通信突然需要访问同一特定数据时，通信过于集中，导致许多物理连接，包括网络带宽、物理存储空间和数据库连接
所以，某明星官宣后，可能会在微博上瘫痪。 发生此停机后，其他功能可能可用，但只有与此热点相关的内容将无法访问。 这实际上与热点数据有关。
一般来说，热点数据是缓存的，但缓存需要固定的密钥。 因此，这类问题往往也被称为热键问题。
如何发现热点数据
一般来说，我们可以通过几种手段识别和发现热键。 主要有以下几种方法。
经验预测，该方法往往卓有成效。 常见的情况是，在电子商务系统中，在开始秒杀和抢购等业务之前可以预测热键。
但是，这种方式的局限性也很大，有些热键完全无法预测。 例如，无法预测明星什么时候做官宣。
实时收集还有一种热点数据发现机制，可以实时收集，包括客户端、服务端、代理层等，收集实时数据，进行统计汇总。
达到一定数量后，会被识别为热键
如何解决热key问题
通过使用http://www.Sina.com/cache最大限度地减少系统交互，可以提前恢复用户请求。
这样可以提高用户体验，也减少系统压力。
缓存的方法有很多。 一些数据可以缓存在客户的客户端浏览器中。 一些数据可以缓存在与用户相近的DNS上。 一些数据可以在Redis等缓存框架中缓存。 另外，一些数据可以在服务器本地缓存中缓存。
使用这样的多个缓存时，将配置多级缓存，如l2缓存和l3缓存。 也就是说，通过缓存方式尽可能缩短用户的接入链路的长度。
如果有缓存，则还存在一个问题，即如果热点数据缓存在同一缓存服务器上，该服务器也可能锁定。
因此，许多人添加缓存后，还可以同时部署多个缓存服务器，如Redis。 另外，将热点数据实时发布到多个高速缓存服务器集群，在部分集群无法承担时立即进行切换。
对于无私内核的Redis热键缓存，Redis具有切片机制，同一热键可能存储在同一片上，因此可以在多个片中同步一个热键。 这样可以从多个片同时执行查询，从而减少单个片的压力。
因为有瓷砖。 此外，多个热键可能被分类为同一瓷砖。 为了减少这一点，可以添加更多的瓷砖来分担流量。
解决热key问题最主要的方式就是加缓存
我简要介绍了热键的发现和解决，这类问题实际上发生得最明显的是像电商系统和微博这样的社交系统。
所以很多公司内部也有很多成熟的方案。
今天我想介绍一下京东内部的框架——JD-hotkey。 这是京东APP的后台热数据探测框架。
这个框架是开源在Gitee之上的。 (https://gitee.com/JD-platform-open source/hotkey )，官方说明如下：
不仅是热点，突发无法提前识别的热点，比如突然大量索要相同商品的热点、恶意爬虫刷一样的热点用户、热点界面、突然大量索要相同界面的热点等
然后，这些热数据、热用户等将推送到所有服务端JVM内存中，大大减少了对后端数据存储的影响。 使用者可以决定如何分配热键、热商品的本地缓存、拒绝访问热用户、热界面熔断、恢复默认值等。
这些热数据在整个服务端群集上是一致的、业务隔离的，工作器方面的性能也很好。
JD-hotkey探测器框架经历了多次高压压力测量和2020年京东618大考验。 在线运行期间，每天检测到的密钥数量为数十亿，可以准确捕获大量爬虫和画笔用户，还可以准确检测到大量热门商品，并以毫秒级推送到每个服务端的内存中，大大降低了热数据查询数据层的压力
升了应用性能。该框架历经多次压测，8核单机worker端每秒可接收处理16万个key探测任务，16核单机至少每秒平稳处理30万以上，实际压测达到37万，CPU平稳支撑，框架无异常。
简单点说，这个框架的主要功能就是热数据探测并推送至集群各个服务器。这个框架主要适用于以下场景：
mysql 热数据本地缓存
redis 热数据本地缓存
黑名单用户本地缓存
爬虫用户限流
接口、用户维度限流
单机接口、用户维度限流限流
集群用户维度限流
集群接口维度限流
在官方文档中，大概介绍了一下这个框架的工作原理，这个框架主要由四个主要部分，分别是ETCD集群、worker集群、client客户端以及dashboard控制台。
下图介绍了一下各个部分的主要功能及简单原理：

这个框架的使用还是相对简单的，主要分为以下几个步骤：
搭建etcd集群
启动dashboard可视化界面
启动worker集群
client启动
详情见 https://gitee.com/jd-platform-opensource/hotkey 中的安装教程部分，这里就不详细介绍了。
近日，这个框架在618稳定版0.2版基础上，引入了proto序列化方式，并优化了传输对象。
worker单机性能从618大促稳定版的20万QPS稳定，30万极限，提升至30万稳定，37万极限。且cpu峰值下降了15%。
该中间件目前在京东内部10余个核心部门接入使用，服务于京东App服务端前台、中台，数据中台等多个核心业务线。
最后，目前关于热key的探测方面，京东做的还是不错的，至少他们开源了一个工具出来，给大家多了一个选择。致敬开源，给京东的开源精神点个赞！
往期推荐《Java开发手册》解读：大整数传输为何禁用Long类型?
不要再自己封装各种Util工具类了，这款神仙级框架你值得拥有！
没想到，我都来阿里5年了！
本文由“壹伴编辑器”提供技术支
直面Java第329期：哪个命令可以监控虚拟机各种运行状态信息？
深入并发第013期：拓展synchronized——锁优化
如果你喜欢本文,
请长按二维码，关注 Hollis.
转发至朋友圈，是对我最大的支持。
点个 在看
喜欢是一种感觉
在看是一种支持
↘↘↘