Redis中熱點Key是怎麼產生的？如何解決？

熱點Key產生的原因

1、使用者消費的資料遠大於生產的資料

熱key問題就是某個瞬間有大量的請求去存取redis上某個固定的key，導致快取擊穿，請求都打到了DB上，壓垮了快取服務和DB服務，從而影響到應用服務可用的可用性。【相關推薦：Redis視訊教學】

最常見的就是微博的熱搜，比如XX明星結婚/出軌。那麼關於XX明星的Key就會瞬間增大，就會出現熱資料問題。微博也時不時的來個崩潰。

同理，被大量刊發、瀏覽的熱點新聞、熱點評論、明星直播等，這些典型的讀多寫少的場景也會產生熱點問題。

2、請求分片集中，超過單Server的效能極限

在伺服器端讀資料進行存取時，往往會對資料進行分片切分，此過程中會在某一主機 Server上對相應的Key進行存取，當存取超過Server極限時，就會導致熱點Key問題的產生。

熱點Key問題的危害

1、流量集中，達到物理網路卡上限。

當某一熱點 Key 的請求在某一主機上超過該主機網路卡上限時，由於流量的過度集中，會導致伺服器中其它服務無法進行。

2、請求過多，快取分片服務被打垮。

如果熱點過於集中，熱點 Key 的快取過多，超過目前的快取容量時，就會導致快取分片服務被打垮現象的產生。

3、DB 擊穿，引起業務雪崩。

當快取服務崩潰後，此時再有請求產生，會快取到後臺 DB 上，由於DB 本身效能較弱，在面臨大請求時很容易發生請求穿透現象，會進一步導致雪崩現象，嚴重影響裝置的效能。

熱點key的發現

1、憑藉業務經驗，進行預估哪些是熱key

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

2、在使用者端進行收集

這個方式就是在操作redis之前，加入一行程式碼進行資料統計。那麼這個資料統計的方式有很多種，也可以是給外部的通訊系統傳送一個通知資訊。缺點就是對使用者端程式碼造成入侵。

3、在Proxy層做收集

有些叢集架構是下面這樣的，Proxy可以是Twemproxy，是統一的入口。可以在Proxy層做收集上報，但是缺點很明顯，並非所有的redis叢集架構都有proxy。

4、用redis自帶命令

• monitor命令：該命令可以實時抓取出redis伺服器接收到的命令，然後寫程式碼統計出熱key是啥。當然，也有現成的分析工具可以給你使用，比如redis-faina。但是該命令在高並行的條件下，有記憶體增暴增的隱患，還會降低redis的效能。
• hotkeys引數：redis 4.0.3提供了redis-cli的熱點key發現功能，執行redis-cli時加上–hotkeys選項即可。但是該引數在執行的時候，如果key比較多，執行起來比較慢。

5、自己抓包評估

Redis使用者端使用TCP協定與伺服器端進行互動，通訊協定採用的是RESP。自己寫程式監聽埠，按照RESP協定規則解析資料，進行分析。缺點就是開發成本高，維護困難，有丟包可能性。

以上五種方案，各有優缺點。根據自己業務場景進行抉擇即可。

熱點Key的解決方案

1、利用二級快取

比如利用ehcache、spring cache，甚至是一個HashMap都可以。在你發現熱key以後，把熱key載入到系統的JVM中。

針對這種熱key請求，會直接從jvm中取，而不會走到redis層。

假設此時有十萬個針對同一個key的請求過來,如果沒有本地快取，這十萬個請求就直接懟到同一臺redis上了。
現在假設，你的應用層有50臺機器，OK，你也有jvm快取了。這十萬個請求平均分散開來，每個機器有2000個請求，會從JVM中取到value值，然後返回資料。避免了十萬個請求懟到同一臺redis上的情形。

2、讀寫分離

讀寫分離就是將同為 Write 的請求傳送到 Master 模組內，而將 Read 的請求傳送至 ReadOnly 模組。

而模組中的唯讀節點還可以進一步擴充，把這個key，在多個redis上都存一份不。有熱key請求進來的時候，我們就在有備份的redis上隨機選取一臺，進行存取取值，返回資料。從而有效解決熱點讀的問題。

讀寫分離同時具有可以靈活擴容讀熱點能力、可以儲存大量熱點Key、對使用者端友好等優點。

更多程式設計相關知識，請存取：！！

以上就是Redis中熱點Key是怎麼產生的？如何解決？的詳細內容，更多請關注TW511.COM其它相關文章！