Redis中熱點Key如何產生的

這篇文章主要介紹了Redis中熱點Key如何產生的，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

熱點Key產生的原因

1、用戶消費的數據遠大于生產的數據

熱key問題就是某個瞬間有大量的請求去訪問redis上某個固定的key，導致緩存擊穿，請求都打到了DB上，壓垮了緩存服務和DB服務，從而影響到應用服務可用的可用性。

最常見的就是微博的熱搜，比如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如何產生的”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!