【原創】談談redis的熱key問題如何解決

引言

講了幾天的數據庫系列的文章，你們必定看煩了，其實還沒講完。。。(如下省略一萬字)。
今天咱們換換口味，來寫redis方面的內容，談談熱key問題如何解決。
其實熱key問題說來也很簡單，就是瞬間有幾十萬的請求去訪問redis上某個固定的key，從而壓垮緩存服務的情狀況。
其實生活中也是有很多這樣的例子。好比XX明星結婚。那麼關於XX明星的Key就會瞬間增大，就會出現熱數據問題。
ps:hot key和big key問題，你們必定要有所瞭解。
本文預計分爲以下幾個部分

• 熱key問題
• 如何發現
• 業內方案

正文

熱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)通知系統作處理
正巧，前幾天有贊出了一篇《有贊透明多級緩存解決方案（TMC）》，裏頭也有提到熱點key問題，咱們恰好藉此說明
(1)監控熱key
在監控熱key方面，有贊用的是方式二：在客戶端進行收集。
在《有贊透明多級緩存解決方案（TMC）》中有一句話提到

TMC 對原生jedis包的JedisPool和Jedis類作了改造，在JedisPool初始化過程當中集成TMC「熱點發現」+「本地緩存」功能Hermes-SDK包的初始化邏輯。

也就說人家改寫了jedis原生的jar包，加入了Hermes-SDK包。
那Hermes-SDK包用來幹嗎？
OK，就是作熱點發現和本地緩存。
從監控的角度看，該包對於Jedis-Client的每次key值訪問請求，Hermes-SDK 都會經過其通訊模塊將key訪問事件異步上報給Hermes服務端集羣，以便其根據上報數據進行「熱點探測」。

固然，這只是其中一種方式，有的公司在監控方面用的是方式五:本身抓包評估。
具體是這麼作的，先利用flink搭建一套流式計算系統。而後本身寫一個抓包程序抓redis監聽端口的數據，抓到數據後往kafka裏丟。
接下來，流式計算系統消費kafka裏的數據，進行數據統計便可，也能達到監控熱key的目的。

(2)通知系統作處理
在這個角度，有贊用的是上面的解決方案一:利用二級緩存進行處理。
有贊在監控到熱key後，Hermes服務端集羣會經過各類手段通知各業務系統裏的Hermes-SDK，告訴他們:"老弟，這個key是熱key，記得作本地緩存。"
因而Hermes-SDK就會將該key緩存在本地，對於後面的請求。Hermes-SDK發現這個是一個熱key，直接從本地中拿，而不會去訪問集羣。

除了這種通知方式之外。咱們也能夠這麼作，好比你的流式計算系統監控到熱key了，往zookeeper裏頭的某個節點裏寫。而後你的業務系統監聽該節點，發現節點數據變化了，就表明發現熱key。最後往本地緩存裏寫，也是能夠的。

通知方式各類各樣，你們能夠自由發揮。本文只是提供一個思路。

總結

但願經過本文，你們明白如何處理生產上遇到的熱key問題。