熱Key問題
所謂熱key問題就是，突然有幾十萬的請求去訪問redis上的某個特定key。那么，這樣會造成流量過于集中，達到物理網卡上限，從而導致這臺redis的服務器宕機。
那接下來這個key的請求，就會直接懟到你的數(shù)據(jù)庫上，導致你的服務不可用。
怎么發(fā)現(xiàn)熱key
方法一:憑借業(yè)務經驗，進行預估哪些是熱key
其實這個方法還是挺有可行性的。比如某商品在做秒殺，那這個商品的key就可以判斷出是熱key。缺點很明顯，并非所有業(yè)務都能預估出哪些key是熱key。
方法二:在客戶端進行收集
這個方式就是在操作redis之前，加入一行代碼進行數(shù)據(jù)統(tǒng)計。那么這個數(shù)據(jù)統(tǒng)計的方式有很多種，也可以是給外部的通訊系統(tǒng)發(fā)送一個通知信息。缺點就是對客戶端代碼造成入侵。
方法三:在Proxy層做收集
有些集群架構是下面這樣的，Proxy可以是Twemproxy，是統(tǒng)一的入口。可以在Proxy層做收集上報，但是缺點很明顯，并非所有的redis集群架構都有proxy。
方法四:用redis自帶命令
(1)monitor命令，該命令可以實時抓取出redis服務器接收到的命令，然后寫代碼統(tǒng)計出熱key是啥。當然，也有現(xiàn)成的分析工具可以給你使用，比如redis-faina。但是該命令在高并發(fā)的條件下，有內存增暴增的隱患，還會降低redis的性能。
(2)hotkeys參數(shù)，redis 4.0.3提供了redis-cli的熱點key發(fā)現(xiàn)功能，執(zhí)行redis-cli時加上–hotkeys選項即可。但是該參數(shù)在執(zhí)行的時候，如果key比較多，執(zhí)行起來比較慢。
方法五:自己抓包評估
Redis客戶端使用TCP協(xié)議與服務端進行交互，通信協(xié)議采用的是RESP。自己寫程序監(jiān)聽端口，按照RESP協(xié)議規(guī)則解析數(shù)據(jù)，進行分析。缺點就是開發(fā)成本高，維護困難，有丟包可能性。
以上五種方案，各有優(yōu)缺點。根據(jù)自己業(yè)務場景進行抉擇即可。那么發(fā)現(xiàn)熱key后，如何解決呢？
如何解決
目前業(yè)內的方案有兩種
(1)利用二級緩存
比如利用ehcache，或者一個HashMap都可以。在你發(fā)現(xiàn)熱key以后，把熱key加載到系統(tǒng)的JVM中。
針對這種熱key請求，會直接從jvm中取，而不會走到redis層。
假設此時有十萬個針對同一個key的請求過來,如果沒有本地緩存，這十萬個請求就直接懟到同一臺redis上了。
現(xiàn)在假設，你的應用層有50臺機器，OK，你也有jvm緩存了。這十萬個請求平均分散開來，每個機器有2000個請求，會從JVM中取到value值，然后返回數(shù)據(jù)。避免了十萬個請求懟到同一臺redis上的情形。
(2)備份熱key
這個方案也很簡單。不要讓key走到同一臺redis上不就行了。我們把這個key，在多個redis上都存一份不就好了。接下來，有熱key請求進來的時候，我們就在有備份的redis上隨機選取一臺，進行訪問取值，返回數(shù)據(jù)。
假設redis的集群數(shù)量為N，步驟如下圖所示
注:不一定是2N，你想取3N，4N都可以，看要求。
偽代碼如下
const M = N * 2
//生成隨機數(shù)
random = GenRandom(0, M)
//構造備份新key
bakHotKey = hotKey + “_” + random
data = redis.GET(bakHotKey)
if data == NULL {
data = GetFromDB()
redis.SET(bakHotKey, expireTime + GenRandom(0,5))
}
業(yè)內方案
OK，其實看完上面的內容，大家可能會有一個疑問。
有辦法在項目運行過程中，自動發(fā)現(xiàn)熱key，然后程序自動處理么？
嗯，好問題，那我們來講講業(yè)內怎么做的。其實只有兩步
- 監(jiān)控熱key
- 通知系統(tǒng)做處理
監(jiān)控熱key
那Hermes-SDK包用來干嘛？
就是做熱點發(fā)現(xiàn)和本地緩存。
從監(jiān)控的角度看，該包對于Jedis-Client的每次key值訪問請求，Hermes-SDK 都會通過其通信模塊將key訪問事件異步上報給Hermes服務端集群，以便其根據(jù)上報數(shù)據(jù)進行“熱點探測”。
當然，這只是其中一種方式，有的公司在監(jiān)控方面用的是方式五:自己抓包評估。
具體是這么做的，先利用flink搭建一套流式計算系統(tǒng)。然后自己寫一個抓包程序抓redis監(jiān)聽端口的數(shù)據(jù)，抓到數(shù)據(jù)后往kafka里丟。
接下來，流式計算系統(tǒng)消費kafka里的數(shù)據(jù)，進行數(shù)據(jù)統(tǒng)計即可，也能達到監(jiān)控熱key的目的。
通知系統(tǒng)做處理
在監(jiān)控到熱key后，Hermes服務端集群會通過各種手段通知各業(yè)務系統(tǒng)里的Hermes-SDK，告訴他們:"老弟，這個key是熱key，記得做本地緩存。"
于是Hermes-SDK就會將該key緩存在本地，對于后面的請求。Hermes-SDK發(fā)現(xiàn)這個是一個熱key，直接從本地中拿，而不會去訪問集群。
除了這種通知方式以外。我們也可以這么做，比如你的流式計算系統(tǒng)監(jiān)控到熱key了，往zookeeper里頭的某個節(jié)點里寫。然后你的業(yè)務系統(tǒng)監(jiān)聽該節(jié)點，發(fā)現(xiàn)節(jié)點數(shù)據(jù)變化了，就代表發(fā)現(xiàn)熱key。最后往本地緩存里寫，也是可以的。
通知方式各種各樣，大家可以自由發(fā)揮。本文只是提供一個思路。
