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

孤獨煙發表於2019-05-16

引言

講了幾天的資料庫系列的文章,大家一定看煩了,其實還沒講完。。。(以下省略一萬字)。
今天我們換換口味,來寫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的熱key問題如何解決
方法四:用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,步驟如下圖所示
【原創】談談redis的熱key問題如何解決
注:不一定是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問題。

相關文章