redis中熱key問(wèn)題該如何解決
引言
講了幾天的數(shù)據(jù)庫(kù)系列的文章,大家一定看煩了,其實(shí)還沒(méi)講完。。。(以下省略一萬(wàn)字)。
今天我們換換口味,來(lái)寫(xiě)redis方面的內(nèi)容,談?wù)劅醟ey問(wèn)題如何解決。
其實(shí)熱key問(wèn)題說(shuō)來(lái)也很簡(jiǎn)單,就是瞬間有幾十萬(wàn)的請(qǐng)求去訪問(wèn)redis上某個(gè)固定的key,從而壓垮緩存服務(wù)的情情況。
其實(shí)生活中也是有不少這樣的例子。比如XX明星結(jié)婚。那么關(guān)于XX明星的Key就會(huì)瞬間增大,就會(huì)出現(xiàn)熱數(shù)據(jù)問(wèn)題。
ps: hot key和big key問(wèn)題,大家一定要有所了解。
本文預(yù)計(jì)分為如下幾個(gè)部分
- 熱key問(wèn)題
- 如何發(fā)現(xiàn)
- 業(yè)內(nèi)方案
正文
熱Key問(wèn)題
上面提到,所謂熱key問(wèn)題就是,突然有幾十萬(wàn)的請(qǐng)求去訪問(wèn)redis上的某個(gè)特定key。那么,這樣會(huì)造成流量過(guò)于集中,達(dá)到物理網(wǎng)卡上限,從而導(dǎo)致這臺(tái)redis的服務(wù)器宕機(jī)。
那接下來(lái)這個(gè)key的請(qǐng)求,就會(huì)直接懟到你的數(shù)據(jù)庫(kù)上,導(dǎo)致你的服務(wù)不可用。
怎么發(fā)現(xiàn)熱key
方法一:憑借業(yè)務(wù)經(jīng)驗(yàn),進(jìn)行預(yù)估哪些是熱key
其實(shí)這個(gè)方法還是挺有可行性的。比如某商品在做秒殺,那這個(gè)商品的key就可以判斷出是熱key。缺點(diǎn)很明顯,并非所有業(yè)務(wù)都能預(yù)估出哪些key是熱key。
方法二:在客戶端進(jìn)行收集
這個(gè)方式就是在操作redis之前,加入一行代碼進(jìn)行數(shù)據(jù)統(tǒng)計(jì)。那么這個(gè)數(shù)據(jù)統(tǒng)計(jì)的方式有很多種,也可以是給外部的通訊系統(tǒng)發(fā)送一個(gè)通知信息。缺點(diǎn)就是對(duì)客戶端代碼造成入侵。
方法三:在Proxy層做收集
有些集群架構(gòu)是下面這樣的,Proxy可以是Twemproxy,是統(tǒng)一的入口??梢栽赑roxy層做收集上報(bào),但是缺點(diǎn)很明顯,并非所有的redis集群架構(gòu)都有proxy。

方法四:用redis自帶命令
(1)monitor命令,該命令可以實(shí)時(shí)抓取出redis服務(wù)器接收到的命令,然后寫(xiě)代碼統(tǒng)計(jì)出熱key是啥。當(dāng)然,也有現(xiàn)成的分析工具可以給你使用,比如 redis-faina 。但是該命令在高并發(fā)的條件下,有內(nèi)存增暴增的隱患,還會(huì)降低redis的性能。
(2)hotkeys參數(shù),redis 4.0.3提供了redis-cli的熱點(diǎn)key發(fā)現(xiàn)功能,執(zhí)行redis-cli時(shí)加上–hotkeys選項(xiàng)即可。但是該參數(shù)在執(zhí)行的時(shí)候,如果key比較多,執(zhí)行起來(lái)比較慢。
方法五:自己抓包評(píng)估
Redis客戶端使用TCP協(xié)議與服務(wù)端進(jìn)行交互,通信協(xié)議采用的是RESP。自己寫(xiě)程序監(jiān)聽(tīng)端口,按照RESP協(xié)議規(guī)則解析數(shù)據(jù),進(jìn)行分析。缺點(diǎn)就是開(kāi)發(fā)成本高,維護(hù)困難,有丟包可能性。
以上五種方案,各有優(yōu)缺點(diǎn)。根據(jù)自己業(yè)務(wù)場(chǎng)景進(jìn)行抉擇即可。那么發(fā)現(xiàn)熱key后,如何解決呢?
如何解決
目前業(yè)內(nèi)的方案有兩種
(1)利用二級(jí)緩存
比如利用 ehcache ,或者一個(gè) HashMap 都可以。在你發(fā)現(xiàn)熱key以后,把熱key加載到系統(tǒng)的JVM中。
針對(duì)這種熱key請(qǐng)求,會(huì)直接從jvm中取,而不會(huì)走到redis層。
假設(shè)此時(shí)有十萬(wàn)個(gè)針對(duì)同一個(gè)key的請(qǐng)求過(guò)來(lái),如果沒(méi)有本地緩存,這十萬(wàn)個(gè)請(qǐng)求就直接懟到同一臺(tái)redis上了。
現(xiàn)在假設(shè),你的應(yīng)用層有50臺(tái)機(jī)器,OK,你也有jvm緩存了。這十萬(wàn)個(gè)請(qǐng)求平均分散開(kāi)來(lái),每個(gè)機(jī)器有2000個(gè)請(qǐng)求,會(huì)從JVM中取到value值,然后返回?cái)?shù)據(jù)。避免了十萬(wàn)個(gè)請(qǐng)求懟到同一臺(tái)redis上的情形。
(2)備份熱key
這個(gè)方案也很簡(jiǎn)單。不要讓key走到同一臺(tái)redis上不就行了。我們把這個(gè)key,在多個(gè)redis上都存一份不就好了。接下來(lái),有熱key請(qǐng)求進(jìn)來(lái)的時(shí)候,我們就在有備份的redis上隨機(jī)選取一臺(tái),進(jìn)行訪問(wèn)取值,返回?cái)?shù)據(jù)。
假設(shè)redis的集群數(shù)量為N,步驟如下圖所示

注:不一定是2N,你想取3N,4N都可以,看要求。
偽代碼如下
const M = N * 2
//生成隨機(jī)數(shù)
random = GenRandom(0, M)
//構(gòu)造備份新key
bakHotKey = hotKey + “_” + random
data = redis.GET(bakHotKey)
if data == NULL {
data = GetFromDB()
redis.SET(bakHotKey, expireTime + GenRandom(0,5))
}
業(yè)內(nèi)方案
OK,其實(shí)看完上面的內(nèi)容,大家可能會(huì)有一個(gè)疑問(wèn)。
煙哥,有辦法在項(xiàng)目運(yùn)行過(guò)程中,自動(dòng)發(fā)現(xiàn)熱key,然后程序自動(dòng)處理么?
嗯,好問(wèn)題,那我們來(lái)講講業(yè)內(nèi)怎么做的。其實(shí)只有兩步
(1)監(jiān)控?zé)醟ey
(2)通知系統(tǒng)做處理
正巧,前幾天有贊出了一篇《有贊透明多級(jí)緩存解決方案(TMC)》,里頭也有提到熱點(diǎn)key問(wèn)題,我們剛好借此說(shuō)明
(1)監(jiān)控?zé)醟ey
在監(jiān)控?zé)醟ey方面,有贊用的是方式二:在客戶端進(jìn)行收集。
在《有贊透明多級(jí)緩存解決方案(TMC)》中有一句話提到
TMC 對(duì)原生jedis包的JedisPool和Jedis類做了改造,在JedisPool初始化過(guò)程中集成TMC“熱點(diǎn)發(fā)現(xiàn)”+“本地緩存”功能Hermes-SDK包的初始化邏輯。
也就說(shuō)人家改寫(xiě)了jedis原生的jar包,加入了Hermes-SDK包。
那Hermes-SDK包用來(lái)干嘛?
OK,就是做 熱點(diǎn)發(fā)現(xiàn) 和 本地緩存 。
從監(jiān)控的角度看,該包對(duì)于Jedis-Client的每次key值訪問(wèn)請(qǐng)求,Hermes-SDK 都會(huì)通過(guò)其通信模塊將key訪問(wèn)事件異步上報(bào)給Hermes服務(wù)端集群,以便其根據(jù)上報(bào)數(shù)據(jù)進(jìn)行“熱點(diǎn)探測(cè)”。
當(dāng)然,這只是其中一種方式,有的公司在監(jiān)控方面用的是方式五:自己抓包評(píng)估
具體是這么做的,先利用flink搭建一套流式計(jì)算系統(tǒng)。然后自己寫(xiě)一個(gè)抓包程序抓redis監(jiān)聽(tīng)端口的數(shù)據(jù),抓到數(shù)據(jù)后往kafka里丟。
接下來(lái),流式計(jì)算系統(tǒng)消費(fèi)kafka里的數(shù)據(jù),進(jìn)行數(shù)據(jù)統(tǒng)計(jì)即可,也能達(dá)到監(jiān)控?zé)醟ey的目的。
(2)通知系統(tǒng)做處理
在這個(gè)角度,有贊用的是上面的解決方案一:利用二級(jí)緩存進(jìn)行處理。
有贊在監(jiān)控到熱key后,Hermes服務(wù)端集群會(huì)通過(guò)各種手段通知各業(yè)務(wù)系統(tǒng)里的Hermes-SDK,告訴他們:"老弟,這個(gè)key是熱key,記得做本地緩存。"
于是Hermes-SDK就會(huì)將該key緩存在本地,對(duì)于后面的請(qǐng)求。Hermes-SDK發(fā)現(xiàn)這個(gè)是一個(gè)熱key,直接從本地中拿,而不會(huì)去訪問(wèn)集群。
除了這種通知方式以外。我們也可以這么做,比如你的流式計(jì)算系統(tǒng)監(jiān)控到熱key了,往zookeeper里頭的某個(gè)節(jié)點(diǎn)里寫(xiě)。然后你的業(yè)務(wù)系統(tǒng)監(jiān)聽(tīng)該節(jié)點(diǎn),發(fā)現(xiàn)節(jié)點(diǎn)數(shù)據(jù)變化了,就代表發(fā)現(xiàn)熱key。最后往本地緩存里寫(xiě),也是可以的。
通知方式各種各樣,大家可以自由發(fā)揮。本文只是提供一個(gè)思路。
總結(jié)
希望通過(guò)本文,大家明白如何處理生產(chǎn)上遇到的熱key問(wèn)題。
好了,以上就是這篇文章的全部?jī)?nèi)容了,希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,謝謝大家對(duì)腳本之家的支持。
- redis熱key問(wèn)題怎樣解決
- Redis什么是熱Key問(wèn)題以及如何解決熱Key問(wèn)題
- Redis如何高效刪除大key
- Redis的大Key對(duì)持久化影響分析
- redis大key和大value的危害及解決
- Redis大key和多key拆分的解決方案
- Redis排查大key的3種方法小結(jié)
- Redis中什么是Big?Key(大key)問(wèn)題?如何解決Big?Key問(wèn)題?
- Redis大key多key拆分實(shí)現(xiàn)方法解析
- Redis獲取某個(gè)大key值的腳本實(shí)例
- 一文了解發(fā)現(xiàn)并解決Redis熱key與大key問(wèn)題
相關(guān)文章
window下創(chuàng)建redis出現(xiàn)問(wèn)題小結(jié)
這篇文章主要介紹了window下創(chuàng)建redis出現(xiàn)問(wèn)題總結(jié),本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2020-10-10
Redis?HyperLogLog數(shù)據(jù)統(tǒng)計(jì)輕量級(jí)解決方案詳解
這篇文章主要為大家介紹了Redis?HyperLogLog數(shù)據(jù)統(tǒng)計(jì)輕量級(jí)解決方案詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-12-12
基于Redis+Lua腳本實(shí)現(xiàn)分布式限流組件封裝的方法
這篇文章主要介紹了基于Redis+Lua腳本實(shí)現(xiàn)分布式限流組件封裝,本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2020-10-10
Redis使用RedisTemplate導(dǎo)致key亂碼問(wèn)題解決
本文主要介紹了Redis使用RedisTemplate導(dǎo)致key亂碼問(wèn)題解決,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2024-06-06
Redis實(shí)現(xiàn)高并發(fā)計(jì)數(shù)器
這篇文章主要為大家詳細(xì)介紹了Redis實(shí)現(xiàn)高并發(fā)計(jì)數(shù)器,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2018-10-10

