引言

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

今天我們換換口味，來寫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，是統一的入口?？梢栽赑roxy層做收集上報，但是缺點很明顯，并非所有的redis集群架構都有proxy。

方法四:用redis自帶命令

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

(2)hotkeys參數，redis 4.0.3提供了redis-cli的熱點key發現功能，執行redis-cli時加上