達到物理網卡上限，忽然幾十萬的請求訪問Redis的某個key如何解決

時間 2019-11-06

標籤達到物理網卡上限忽然十萬請求訪問 redis 某個 key 如何解決欄目網絡硬件简体版

原文原文鏈接

熱Key問題

所謂熱key問題就是，忽然有幾十萬的請求去訪問redis上的某個特定key。那麼，這樣會形成流量過於集中，達到物理網卡上限，從而致使這臺redis的服務器宕機。redis

那接下來這個key的請求，就會直接懟到你的數據庫上，致使你的服務不可用。數據庫

怎麼發現熱key

方法一:憑藉業務經驗，進行預估哪些是熱key緩存

其實這個方法仍是挺有可行性的。好比某商品在作秒殺，那這個商品的key就能夠判斷出是熱key。缺點很明顯，並不是全部業務都能預估出哪些key是熱key。bash

方法二:在客戶端進行收集服務器

這個方式就是在操做redis以前，加入一行代碼進行數據統計。那麼這個數據統計的方式有不少種，也能夠是給外部的通信系統發送一個通知信息。缺點就是對客戶端代碼形成入侵。架構

方法三:在Proxy層作收集併發

有些集羣架構是下面這樣的，Proxy能夠是Twemproxy，是統一的入口。能夠在Proxy層作收集上報，可是缺點很明顯，並不是全部的redis集羣架構都有proxy。dom

方法四:用redis自帶命令異步

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

(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，其實看完上面的內容，你們可能會有一個疑問。