共計 2571 個字符，預計需要花費 7 分鐘才能閱讀完成。
自動寫代碼機器人，免費開通
這篇文章主要介紹了 redis 中熱 key 問題的解決方法，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓丸趣 TV 小編帶著大家一起了解一下。
正文
熱 Key 問題
上面提到，所謂熱 key 問題就是，突然有幾十萬的請求去訪問 redis 上的某個特定 key。那么，這樣會造成流量過于集中，達到物理網卡上限，從而導致這臺 redis 的服務器宕機。
那接下來這個 key 的請求，就會直接懟到你的數據庫上，導致你的服務不可用。
怎么發現熱 key
方法一: 憑借業務經驗，進行預估哪些是熱 key
其實這個方法還是挺有可行性的。比如某商品在做秒殺，那這個商品的 key 就可以判斷出是熱 key。缺點很明顯，并非所有業務都能預估出哪些 key 是熱 key。
方法二: 在客戶端進行收集
這個方式就是在操作 redis 之前，加入一行代碼進行數據統計。那么這個數據統計的方式有很多種，也可以是給外部的通訊系統發送一個通知信息。缺點就是對客戶端代碼造成入侵。
方法三: 在 Proxy 層做收集
有些集群架構是下面這樣的，Proxy 可以是 Twemproxy，是統一的入口。可以在 Proxy 層做收集上報，但是缺點很明顯，并非所有的 redis 集群架構都有 proxy。
方法四: 用 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，步驟如下圖所示
注: 不一定是 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。最后往本地緩存里寫，也是可以的。
感謝你能夠認真閱讀完這篇文章，希望丸趣 TV 小編分享的“redis 中熱 key 問題的解決方法”這篇文章對大家有幫助，同時也希望大家多多支持丸趣 TV，關注丸趣 TV 行業資訊頻道，更多相關知識等著你來學習!
向 AI 問一下細節
