熱Key問題

所謂熱key問題就是，突然有幾十萬的請求去訪問redis上的某個特定key。那麼，這樣會造成流量過於集中，達到物理網卡上限，從而導致這臺redis的伺服器宕機。

那接下來這個key的請求，就會直接懟到你的資料庫上，導致你的服務不可用。

怎麼發現熱key

方法一:憑藉業務經驗，進行預估哪些是熱key

其實這個方法還是挺有可行性的。比如某商品在做秒殺，那這個商品的key就可以判斷出是熱key。缺點很明顯，並非所有業務都能預估出哪些key是熱key。

方法二:在客戶端進行收集

這個方式就是在操作redis之前，加入一行代碼進行數據統計。那麼這個數據統計的方式有很多種，也可以是給外部的通訊系統發送一個通知信息。缺點就是對客戶端代碼造成入侵。

方法三:在Proxy層做收集

有些集羣架構是下面這樣的，Proxy可以是Twemproxy，是統一的入口。可以在Proxy層做收集上報，但是缺點很明顯，並非所有的redis集羣架構都有proxy。

方法四:用redis自帶命令

(1)monitor命令，該命令可以實時抓取出redis伺服器接收到的命令，然後寫代碼統計出熱key是啥。當然，也有現成的分析工具可以給你使用，比如redis-faina。但是該命令在高並發的條件下，有內存增暴增的隱患，還會降低redis的性能。

(2)hotkeys參數，redis 4.0.3提供了redis-cli的熱點key發現功能，執行redis-cli時加上–hotkeys選項即可。但是該參數在執行的時候，如果key比較多，執行起來比較慢。

方法五:自己抓包評估

Redis客戶端使用TCP協議與服務端進行交互，通信協議採用的是RESP。自己寫程序監聽埠，按照RESP協議規則解析數據，進行分析。缺點就是開發成本高，維護困難，有丟包可能性。

以上五種方案，各有優缺點。根據自己業務場景進行抉擇即可。那麼發現熱key後，如何解決呢？

如何解決

目前業內的方案有兩種

(1)利用二級緩存

比如利用ehcache，或者一個HashMap都可以。在你發現熱key以後，把熱key載入到系統的JVM中。

針對這種熱key請求，會直接從jvm中取，而不會走到redis層。

假設此時有十萬個針對同一個key的請求過來,如果沒有本地緩存，這十萬個請求就直接懟到同一臺redis上了。

現在假設，你的應用層有50臺機器，OK，你也有jvm緩存了。這十萬個請求平均分散開來，每個機器有2000個請求，會從JVM中取到value值，然後返回數據。避免了十萬個請求懟到同一臺redis上的情形。

(2)備份熱key

這個方案也很簡單。不要讓key走到同一臺redis上不就行了。我們把這個key，在多個redis上都存一份不就好了。接下來，有熱key請求進來的時候，我們就在有備份的redis上隨機選取一臺，進行訪問取值，返回數據。

假設redis的集羣數量為N，步驟如下圖所示

注:不一定是2N，你想取3N，4N都可以，看要求。

偽代碼如下

const M = N * 2
//生成隨機數
random = GenRandom(0, M)
//構造備份新key
bakHotKey = hotKey + 「_」 + random
data = redis.GET(bakHotKey)
if data == NULL {
data = GetFromDB()
redis.SET(bakHotKey, expireTime + GenRandom(0,5))
}

業內方案

OK，其實看完上面的內容，大家可能會有一個疑問。

有辦法在項目運行過程中，自動發現熱key，然後程序自動處理麼？

嗯，好問題，那我們來講講業內怎麼做的。其實只有兩步

  1. 監控熱key
  2. 通知系統做處理

監控熱key

那Hermes-SDK包用來幹嘛？

就是做熱點發現和本地緩存。

從監控的角度看，該包對於Jedis-Client的每次key值訪問請求，Hermes-SDK 都會通過其通信模塊將key訪問事件非同步上報給Hermes服務端集羣，以便其根據上報數據進行「熱點探測」。

當然，這只是其中一種方式，有的公司在監控方面用的是方式五:自己抓包評估。

具體是這麼做的，先利用flink搭建一套流式計算系統。然後自己寫一個抓包程序抓redis監聽埠的數據，抓到數據後往kafka裏丟。

接下來，流式計算系統消費kafka裏的數據，進行數據統計即可，也能達到監控熱key的目的。

通知系統做處理

在監控到熱key後，Hermes服務端集羣會通過各種手段通知各業務系統裏的Hermes-SDK，告訴他們:"老弟，這個key是熱key，記得做本地緩存。"

於是Hermes-SDK就會將該key緩存在本地，對於後面的請求。Hermes-SDK發現這個是一個熱key，直接從本地中拿，而不會去訪問集羣。

除了這種通知方式以外。我們也可以這麼做，比如你的流式計算系統監控到熱key了，往zookeeper裡頭的某個節點裡寫。然後你的業務系統監聽該節點，發現節點數據變化了，就代表發現熱key。最後往本地緩存裏寫，也是可以的。

通知方式各種各樣，大家可以自由發揮。本文只是提供一個思路。

本文到此結束喜歡的朋友幫忙點點贊和關注，感謝感謝！

如果你是Java程序員，對技術提升很感興趣，現在私信我【架構】加入我的交流羣 裡面都是同行，有資源共享。歡迎一到五年的工程師加入，合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間「來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！

現在加入還可以免費領取BAT等各大廠面試資料及java架構師技術思維導圖。


推薦閱讀：
相關文章