一、什么是熱Key？

在Redis中，我們把訪問頻率高的Key，稱為熱Key。

比如突然又幾十萬的請求去訪問redis中某個特定的Key，那么這樣會造成redis服務(wù)器短時間流量過于集中，很可能導(dǎo)致redis的服務(wù)器宕機(jī)。

那么接下來對這個Key的請求，都會直接請求到我們的后端數(shù)據(jù)庫中，數(shù)據(jù)庫性能本來就不高，這樣就可能直接壓垮數(shù)據(jù)庫，進(jìn)而導(dǎo)致后端服務(wù)不可用。

二、熱Key產(chǎn)生的原因？

1、用戶消費(fèi)的數(shù)據(jù)遠(yuǎn)大于生產(chǎn)的數(shù)據(jù)，如商品秒殺、熱點新聞、熱點評論等讀多寫少的場景。

雙十一秒殺商品，短時間內(nèi)某個爆款商品可能被點擊/購買上百萬次，或者某條爆炸性新聞等被大量瀏覽，此時會造成一個較大的請求Redis量，這種情況下就會造成熱點Key問題。

2、請求分片集中，超過單臺Redis服務(wù)器的性能極限。

在服務(wù)端讀數(shù)據(jù)進(jìn)行訪問時，往往會對數(shù)據(jù)進(jìn)行分片切分，例如采用固定Hash分片，hash落入同一臺redis服務(wù)器，如果瞬間訪問量過大，超過機(jī)器瓶頸時，就會導(dǎo)致熱點 Key 問題的產(chǎn)生。

三、熱點Key的危害？

1、緩存擊穿，壓垮redis服務(wù)器，導(dǎo)致大量請求直接發(fā)往后端服務(wù)，并且DB本身性能較弱，很可能進(jìn)一步導(dǎo)致后端服務(wù)雪崩。

四、如何識別熱點Key？

1、憑借個人經(jīng)驗，結(jié)合業(yè)務(wù)場景，判斷哪些是熱Key。

比如，雙十一大促的時候，蘋果手機(jī)正在秒殺，那么我們可以判斷蘋果手機(jī)這個sku就是熱Key。

2、使用redis之前，在客戶端寫程序統(tǒng)計上報。

修改我們的業(yè)務(wù)代碼，在操作redis之前，加入Key使用次數(shù)的統(tǒng)計邏輯，定時把收集到的數(shù)據(jù)上報到統(tǒng)一的服務(wù)進(jìn)行聚合計算，這樣我們就可以找到那些熱點Key。缺點就是對我們的業(yè)務(wù)代碼有一定的侵入性。

3、服務(wù)代理層上報。

這個要看具體公司redis集群架構(gòu)是怎么樣的，如果是在redis前面有一個代理層，那么我們可以在代理層進(jìn)行收集上報，也是可以找到熱點Key。如下這種架構(gòu)：

這種方式確定也很明顯， 每個公司的架構(gòu)不一樣，并非都有Proxy代理這一層。

4、使用redis自帶的命令。

例如monitor、redis-cli加上--hotkeys選項等，不過這種方式執(zhí)行起來很慢，可能會降低redis的處理請求的性能，慎用。

monitor命令：可以實時抓取出redis服務(wù)器接收到的命令，然后寫代碼統(tǒng)計出熱Key，也有現(xiàn)成的分析工具可以使用。

5、redis節(jié)點抓包分析。

自己寫程序監(jiān)聽端口，解析數(shù)據(jù)，進(jìn)行分析。

五、如何解決熱Key問題？

1、Redis集群擴(kuò)容：增加分片副本，分?jǐn)偪蛻舳税l(fā)過來的讀請求；

2、使用二級緩存，即JVM本地緩存，減少Redis的讀請求。

例如使用Caffeine+redis 實現(xiàn)二級緩存，先從本地緩存中取，取不到再去redis中去取。當(dāng)然也可以使用其它框架，如ehcache、甚至一個HashMap都可以。

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論