京东hotkey源码解析

京东hotkey是一个经过京东大促验证的hotkey防御中间件，大概原理是通过上报key访问数到统计服务器集群，统计服务器集群将hotkey通知到客户端，让hotkey能缓存到本地内存中，做到毫秒级的Scale-Out。处理方式有点像美团cat实时收集数据进行统计，只不过美团cat没有反向通知逻辑而已。非常贴近工作实践，值得一看。

首先看一下缓存入口Cache的get方法，JdHotKeyStore.getValue是获取hotkey的方法，并且会进行访问次数的统计上报，如果获取到hotkey不为空，则直接返回，否则从redis获取并调用JdHotKeyStore.smartSet判断是否有hotkey，有则设置值，最后返回。

JdHotKeyStore.getValue会先调用inRule校验此key是否有对应规则，如果没有对应规则则不处理，然后调用getValueSimple从本地内存中获取hotkey的存储对象ValueModel，如果没有获取到，则调用HotKeyPusher.push开始计数；如果获取到，会调用isNearExpire判断是否快过期了，如果是也计数，然后取出ValueModel里的value是否有设置对应值，有才返回。最后调用KeyHandlerFactory.getCounter().collect进行对应规则的计数。下面来一步步分析此流程。

inRule会去KeyRule缓存中获取对应的规则，经过层层调用会到KeyRuleHolder的findByKey方法，然后继续调用其findRule方法选择对应的KeyRule，如果没有KeyRule就直接返回了，否则会拿到它的duration(hotkey缓存时间)，拿到对应duration的本地缓存。实际上这里为了方法的通用性，用了get来代替contain的判断。

findRule的逻辑比较特别，作者已经留下了注释，优先全匹配->prefix匹配->* 通配，这样做是为了更精确选择对应的规则。比如配置了sku_的前缀规则，但是茅台sku的流量突升，需要针对茅台sku的本地缓存再长一点时间让系统平稳渡过高峰期，那就配置一个sku_moutai_sku_id的全匹配规则，这样不会干扰到其他sku的缓存规则。

那么KEY_RULES的规则是怎么来的呢？这就要说到etcd了，其实可以把etcd当做zookeeper，也有对配置crud，然后通知客户端的功能。这里是做了定时拉取+监听变化的双重保证，这里跟携程apollo的处理非常像：不要把鸡蛋放在一个篮子，兜底功能真的很重要。每5秒定时从etcd拉取规则，开启监听器有变化就去etcd拉取规则。fetchRuleFromEtcd从ectd的rule_path获取rules，然后转化成ruleList继续调用notifyRuleChange进行本地处理。

notifyRuleChange会往EventBus发送KeyRuleInfoChangeEvent的通知，进而进入KeyRuleHolder的putRules方法，这里可以看到维护了KEY_RULES和RULE_CACHE_MAP。

回到原有流程，getValueSimple方法的链路比较长，主要是通过key的规则，获取到对应的duration，然后从对应duration的本地缓存中获取ValueModel。

接下来是HotKeyPusher.push，如果是remove则在etcd创建一个节点然后再删除，达到集群删除的效果。如果是探测并且key在规则内，则调用KeyHandlerFactory.getCollector().collect进行统计。

KeyHandlerFactory.getCollector().collect方法交替使用两个map，对count进行累加，这样清理map的时候就不需要停顿了，交替使用是避免停顿的有效方式。

接回上文，还有一个 KeyHandlerFactory.getCounter().collect收集的是规则的访问次数，也是取到对应的规则，然后对规则的访问总数、热次数进行累加。

两个指标的收集已经分析完毕，那怎么发送到worker呢？来到PushSchedulerStarter，这里会启动对两个指标的定时线程池，分别会定时调用NettyKeyPusher的send和sendCount方法。

NettyKeyPusher的send和sendCount方法都是为统计数据选择对应的worker然后进行请求，chooseChannel就是根据key哈希到其中一个worker上，然后发送请求即可。

最后当worker统计到hotkey时，client需要接收worker推送过来的hotkey进行存储，可以看到NettyClientHandler会向EventBus发送ReceiveNewKeyEvent事件，ReceiveNewKeyListener收到此事件后将调用receiveNewKeyListener.newKey，将hotkey放到本地缓存，client端的处理流程就结束了。

由上文可知，client与worker的交互只有推送统计数据到worker，worker接收处理，最后推送hotkey到client。因此worker端只需要分析两个部分：统计数据汇总、推送hotkey。

首先看到HotKey的处理逻辑是在HotKeyFilter中，首先会对totalReceiveKeyCount进行累加，然后调用publishMsg，如果统计信息超时1秒或者在白名单中就不处理，否则继续调用keyProducer.push。

keyProducer.push将未过时的统计信息丢进queue中。

worker端会开启指定数量的KeyConsumer，不断消费queue中的统计数据。根据统计数据的类型调用KeyListener的removeKey和newKey。

KeyListener的removeKey和newKey方法对Cache中的滑动窗口SlidingWindow进行删除或者累加，删除或者达到一定访问数就会推送到根据appname选出所有client进行推送。

京东的hotkey处理是通过计数来动态判断是否为hotkey，然后缓存再本地内存中，做到毫秒级的scale out。那还有没有其他解决方案？下面是我的观点：

1.如果面对一些缓存key很少的场景，比如活动页信息（同时进行的活动页不可能超过1000），完全就可以直接将缓存放在本地内存中，到了刷新时间就从redis拉取最新缓存即可，不需要动态计算hotkey。也就是常见的多级缓存。

2.同样是动态判断hotkey，但会将hotkey迁移到专门的、更多节点、更高性能的hotkey redis集群中，集群中每个节点都有同一个hotkey缓存，这样就可以做到请求的分散，避免流量都流向同一个redis节点，判断是hotkey就去hotkey集群中取，不需要存在本地内存中了，维护起来会比较简单。

本帖最后由 云平台技术客服 于 2013-8-9 14:10 编辑

For windows:

首先从google code下载最新的windows的git安装包msysgit，本文所用版本为Git-1.8.0-preview20121022.exe ,然后就开始安装了：

安装msysgit

下一步

选择安装位置，下一步

选择安装主键，默认，下一步

不启动创建文件夹选项

默认选择Git Bash

选择默认的Checkout Style

安装完成

For linux:从源码按安装：

从http://git-scm.com/download 下载最新版本的源码tar包，我下载的是git-1.7.6.tar.gz

# tar xzvf git-1.7.6.tar.gz# cd git-1.7.6

# ./configure -prefix=/usr/local/git

# make install

CentOS/Redhat Fedora安装：

# yum install git

Debian/ubuntu 安装：

# apt-get install git

或者

# aptitude install git

Gentoo安装

# emerge –av git

费 + 开源 ECSHOP是一款开源免费的网上商店系统。由专业的开发团队升级维护，为您提供及时高效的技术支持，您还可以根据自己的商务特征对ECSHOP进行定制，增加自己商城的特色功能。

强大 + 简便 ECSHOP除了注重功能上的强大以外更重要的特点就是 *** 作上的方便快捷。我们设身处地为用户着想的设计理念使我们的产品达到了极高的易用性。只需轻点鼠标+简单录入即可完成商城管理。

效率 + 速度 ECSHOP在系统架构，数据库，程序等方面的设计都由资深的专业人士完成，保证了系统的健壮和效率，高效合理的管理流程助您在瞬息万变的商务活动中始终领先一步，掌握市场的主动权。

---