引言

講了幾天的數(shù)據(jù)庫系列的文章，大家一定看煩了，其實還沒講完。。。(以下省略一萬字)。

今天我們換換口味，來寫redis方面的內(nèi)容，談?wù)劅醟ey問題如何解決。

其實熱key問題說來也很簡單，就是瞬間有幾十萬的請求去訪問redis上某個固定的key，從而壓垮緩存服務(wù)的情情況。

其實生活中也是有不少這樣的例子。比如XX明星結(jié)婚。那么關(guān)于XX明星的Key就會瞬間增大，就會出現(xiàn)熱數(shù)據(jù)問題。

ps: hot key和big key問題，大家一定要有所了解。

本文預(yù)計分為如下幾個部分

• 熱key問題
• 如何發(fā)現(xiàn)
• 業(yè)內(nèi)方案

正文

熱Key問題

上面提到，所謂熱key問題就是，突然有幾十萬的請求去訪問redis上的某個特定key。那么，這樣會造成流量過于集中，達(dá)到物理網(wǎng)卡上限，從而導(dǎo)致這臺redis的服務(wù)器宕機(jī)。

那接下來這個key的請求，就會直接懟到你的數(shù)據(jù)庫上，導(dǎo)致你的服務(wù)不可用。

怎么發(fā)現(xiàn)熱key

方法一:憑借業(yè)務(wù)經(jīng)驗，進(jìn)行預(yù)估哪些是熱key

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

方法二:在客戶端進(jìn)行收集

這個方式就是在操作redis之前，加入一行代碼進(jìn)行數(shù)據(jù)統(tǒng)計。那么這個數(shù)據(jù)統(tǒng)計的方式有很多種，也可以是給外部的通訊系統(tǒng)發(fā)送一個通知信息。缺點就是對客戶端代碼造成入侵。

方法三:在Proxy層做收集

有些集群架構(gòu)是下面這樣的，Proxy可以是Twemproxy，是統(tǒng)一的入口。可以在Proxy層做收集上報，但是缺點很明顯，并非所有的redis集群架構(gòu)都有proxy。

方法四:用redis自帶命令

(1)monitor命令，該命令可以實時抓取出redis服務(wù)器接收到的命令，然后寫代碼統(tǒng)計出熱key是啥。當(dāng)然，也有現(xiàn)成的分析工具可以給你使用，比如 redis-faina 。但是該命令在高并發(fā)的條件下，有內(nèi)存增暴增的隱患，還會降低redis的性能。

(2)hotkeys參數(shù)，redis 4.0.3提供了redis-cli的熱點key發(fā)現(xiàn)功能，執(zhí)行redis-cli時加上