JD hotkey是一個非常好用的京東熱點(diǎn)數(shù)據(jù)分析軟件，對任意突發(fā)性的無法預(yù)先感知的熱點(diǎn)請求，都可以進(jìn)行毫秒級精準(zhǔn)探測到。 然后對這些熱數(shù)據(jù)、熱用戶等，推送到該應(yīng)用部署的所有機(jī)器JVM內(nèi)存中，以大幅減輕對后端數(shù)據(jù)存儲層的沖擊。熱數(shù)據(jù)探測并推送至集群各個服務(wù)器， 這些熱key在整個應(yīng)用集群內(nèi)保持一致性。

軟件介紹

JD-hotkey是京東APP后臺熱數(shù)據(jù)探測框架，歷經(jīng)多次高壓壓測和2020年京東618大促考驗(yàn)。在上線運(yùn)行的這段時間內(nèi)，每天探測的key數(shù)量數(shù)十億計，精準(zhǔn)捕獲了大量爬蟲、刷子用戶，另準(zhǔn)確探測大量熱門商品并毫秒級推送到各個服務(wù)端內(nèi)存，大幅降低了熱數(shù)據(jù)對數(shù)據(jù)層的查詢壓力，提升了應(yīng)用性能。

對任意突發(fā)性的無法預(yù)先感知的熱點(diǎn)請求，包括并不限于熱點(diǎn)數(shù)據(jù)（如突發(fā)大量請求同一個商品）、熱用戶（如爬蟲、刷子）、熱接口（突發(fā)海量請求同一個接口）等，進(jìn)行毫秒級精準(zhǔn)探測到。 然后對這些熱數(shù)據(jù)、熱用戶等，推送到該應(yīng)用部署的所有機(jī)器JVM內(nèi)存中，以大幅減輕對后端數(shù)據(jù)存儲層的沖擊，并可以由客戶端決定如何使用這些熱key（譬如對熱商品做本地緩存、對熱用戶進(jìn)行拒絕訪問、對熱接口進(jìn)行熔斷或返回默認(rèn)值）。 這些熱key在整個應(yīng)用集群內(nèi)保持一致性。

核心功能：熱數(shù)據(jù)探測并推送至集群各個服務(wù)器

應(yīng)用場景

JD-hotkey適用場景：

1、mysql熱數(shù)據(jù)本地緩存

2、redis熱數(shù)據(jù)本地緩存

3、黑名單用戶本地緩存

4、爬蟲用戶限流

5、接口、用戶維度限流

6、單機(jī)接口、用戶維度限流限流

7、集群用戶維度限流

8、集群接口維度限流

安裝方法

1、安裝etcd

在etcd下載頁面下載對應(yīng)操作系統(tǒng)的etcd

2、啟動worker（集群） 下載并編譯好代碼，將worker打包為jar，啟動即可。如：

java -jar $JAVA_OPTS worker-0.0.1-SNAPSHOT.jar --etcd.server=${etcdServer}

worker可供配置項(xiàng)如下：

etcdServer為etcd集群的地址，用逗號分隔

JAVA_OPTS是配置的JVM相關(guān)，可根據(jù)實(shí)際情況配置

threadCount為處理key的線程數(shù)，不指定時由程序來計算。

workerPath代表該worker為哪個應(yīng)用提供計算服務(wù)，譬如不同的應(yīng)用appName需要用不同的worker進(jìn)行隔離，以避免資源競爭。

3、啟動控制臺

下載并編譯好dashboard項(xiàng)目，創(chuàng)建數(shù)據(jù)庫并導(dǎo)入resource下db.sql文件。 配置一下application.yml里的數(shù)據(jù)庫相關(guān)和etcdServer地址。

啟動dashboard項(xiàng)目，訪問ip:8081，即可看到界面。

其中節(jié)點(diǎn)信息里，即是當(dāng)前已啟動的worker列表。

規(guī)則配置就是為各app設(shè)置規(guī)則的地方，初次使用時需要先添加APP。在用戶管理菜單中，添加一個新用戶，設(shè)置他的APP名字，如sample。之后新添加的這個用戶就可以登錄dashboard給自己的APP設(shè)置規(guī)則了，登錄密碼默認(rèn)123456。

如圖就是一組規(guī)則，譬如其中as__開頭的熱key的規(guī)則就是interval-2秒內(nèi)出現(xiàn)了threshold-10次就認(rèn)為它是熱key，它就會被推送到j(luò)vm內(nèi)存中，并緩存60秒，prefix-true代表前綴匹配。那么在應(yīng)用中，就可以把一組key，都用as__開頭，用來探測。

4、client端接入使用

引入client的pom依賴。

在應(yīng)用啟動的地方初始化HotKey，譬如

@PostConstruct public void initHotkey() { ClientStarter.Builder builder = new ClientStarter.Builder(); ClientStarter starter = builder.setAppName("appName").setEtcdServer("http://1.8.8.4:2379,http://1.1.4.4:2379,http://1.1.1.1:2379").build(); starter.startPipeline(); }

其中還可以setCaffeineSize(int size)設(shè)置本地緩存最大數(shù)量，默認(rèn)5萬，setPushPeriod(Long period)設(shè)置批量推送key的間隔時間，默認(rèn)500ms，該值越小，上報熱key越頻繁，相應(yīng)越及時，建議根據(jù)實(shí)際情況調(diào)整，如單機(jī)每秒qps10個，那么0.5秒上報一次即可，否則是空跑。該值最小為1，即1ms上報一次。

注意：

如果原有項(xiàng)目里使用了guava，需要升級guava為以下版本，否則過低的guava版本可能發(fā)生jar包沖突?；蛘邉h除自己項(xiàng)目里的guava的maven依賴，guava升級不會影響原有任何邏輯。

<dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>28.2-jre</version> <scope>compile</scope> </dependency>

有時可能項(xiàng)目里沒有直接依賴guava，但是引入的某個pom里引了guava，也需要將guava排除掉。

常見問題

1、worker掛了怎么辦

client根據(jù)worker的數(shù)量對key進(jìn)行hash后分發(fā)，同一個key一定會被發(fā)往同一個worker。譬如4臺，掛了一臺，key就自動hash到另外3臺。那么這個過程中，就會丟失最多一個探測周期內(nèi)的所有發(fā)來的key，譬如2秒10次算熱，那么就可能全部被rehash，丟失這2秒的數(shù)據(jù)。

它的影響是什么呢？我要不要去存下來所有發(fā)來的key呢？很多人都會問的問題。

首先掛機(jī)，那是極其罕見的事件，即便掛了，對于特別熱的key，完全不影響，hash丟幾秒，不影響它繼續(xù)瞬間變熱。對于不熱的key，它掛不掛，它也熱不了。對于那些將熱未熱的，可能會這次讓它熱不起來，但沒有什么影響，業(yè)務(wù)服務(wù)完全可以吃下這個熱key。而加上一堆別的組件如存儲、worker間通信傳輸key等，它的復(fù)雜度，性能都會影響很大。

所以它掛了對系統(tǒng)沒有任何影響

2、為什么全部要worker匯總計算，而不是客戶端自己計算

首先，客戶端是會本地累加的，在固定的上報周期內(nèi)，如500ms內(nèi)，本地就是在累加，每500ms批量上報給worker一次。如果上報頻率很高，如10ms一次，那么大概率本地同一個key是沒有累加。

有人會說，把這個間隔拉長，譬如本地計算3秒后，本地判定熱key，再上報給其他機(jī)器。那么這種場景首先對于京東是不可行的，哪怕1秒都不行。譬如一個用戶刷子，它在非常頻繁地刷接口，一秒刷了500次，而正常用戶一秒最多點(diǎn)5次，它已經(jīng)是非常嚴(yán)重的刷子了。但我們本地還是判斷不出來它是不是刷子。為什么？機(jī)器多。

隨便一個app小組都有數(shù)千臺機(jī)器，一秒500次請求，一個機(jī)器連1次都平均不到，大部分是0次，本地如何判斷它是刷子呢？總不能訪問我一次就算它刷吧。

然后搶購場景，有些秒殺商品，1-2秒就沒了，流量就停了，你本地計算了3秒，才去上報，那活動已經(jīng)結(jié)束了，你的熱key再推送已經(jīng)沒價值了。我們就要在活動即將開始之前的可能在10ms內(nèi)，就要該商品被推送到所有client的jvm里去，根本等不了1秒。

3、為什么是worker推送，而不是worker發(fā)送熱key到etcd，客戶端直接監(jiān) 聽etcd獲取熱key

（1） worker和client是長連接，產(chǎn)生熱key后，直接推送過去，鏈路短，耗時少。如果是發(fā)到etcd，客戶端再通過etcd獲取，多了一層中轉(zhuǎn)，耗時明顯增加。

（2） etcd性能不夠，存在單點(diǎn)風(fēng)險。譬如我有5000臺client，每秒產(chǎn)生100個熱key，那么每秒就對應(yīng)50萬次推送。我用2臺worker即可輕松完成，隨著worker的橫向擴(kuò)展，每秒的推送上限線性增加。但無論是etcd、redis等等任何組件，都不可能做到1秒50萬次拉取或推送，會瞬間cpu爆滿卡死。因?yàn)閣orker是各自隔離的，而etcd是單點(diǎn)的。實(shí)際情況下，也不止5000臺client，每秒也不止100個熱key，只有當(dāng)前的架構(gòu)能支撐。

4、為什么是etcd，不是zookeeper之類的

etcd里面具備一個過期刪除的功能，你可以設(shè)置一個key幾秒過期，etcd會自動刪除它，刪除時還會給所有監(jiān) 聽的client回調(diào)，這個功能在框架里是在用的，別的配置中心沒有這個功能。

etcd的性能和穩(wěn)定性、低負(fù)載等各項(xiàng)指標(biāo)非常優(yōu)異，完全滿足我們的需求。而zk在很多暴漲流量前和高負(fù)載下，并不是那么穩(wěn)定，性能也差的遠(yuǎn)。