Redis 熱點 key 發現及解決方案.doc

目錄：

1. 什麼狀況下產生熱點key問題？

2. 熱點key問題的危害

3. 解決方案：

1. 服務端緩存方案

2. 使用Memcache、Redis方案

3. 使用本地緩存方案

4. 讀寫分離方案解決熱讀

5. 熱點數據解決方案

4. 熱點key處理

5. 方案對比
   

一. 什麼狀況下產生熱點Key問題？

大體有如下兩種：

一、用戶消費的數據遠大於生產的數據，好比：熱賣商品、熱點新聞、熱點評論、明星直播

在平常工做生活中一些突發的的事件，例如：雙十一期間某些熱門商品的降價促銷，當這其中的某一件商品被數萬次點擊瀏覽或者購買時，會造成一個較大的需求量，這種狀況下就會形成熱點問題。

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

二、請求分片集中，超過單 Server 的性能極限。

在服務端讀數據進行訪問時，每每會對數據進行分片切分，此過程當中會在某一主機 Server 上對相應的 Key 進行訪問，當訪問超過 Server 極限時，就會致使熱點 Key 問題的產生。

二. 熱點Key問題的危害

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

二、請求過多，緩存分片服務被打垮。

三、DB 擊穿，引發業務雪崩。

如前文講到的，當某一熱點 Key 的請求在某一主機上超過該主機網卡上限時，因爲流量的過分集中，會致使服務器中其它服務沒法進行。

若是熱點過於集中，熱點 Key 的緩存過多，超過目前的緩存容量時，就會致使緩存分片服務被打垮現象的產生。

當緩存服務崩潰後，此時再有請求產生，會緩存到後臺 DB 上，因爲DB 自己性能較弱，在面臨大請求時很容易發生請求穿透現象，會進一步致使雪崩現象，嚴重影響設備的性能。

三. 解決方案

一般的解決方案主要集中在對客戶端和 Server 端進行相應的改造。

一、服務端緩存方案

首先 Client 會將請求發送至 Server 上，而 Server 又是一個多線程的服務，本地就具備一個基於 Cache LRU 策略的緩存空間。

當 Server 自己就擁堵時，Server 不會將請求進一步發送給 DB 而是直接返回，只有當 Server 自己暢通時纔會將 Client 請求發送至 DB，而且將該數據從新寫入到緩存中。此時就完成了緩存的訪問跟重建。

但該方案也存在如下問題：

• 緩存失效，多線程構建緩存問題

• 緩存丟失，緩存構建問題

• 髒讀問題

二、使用 Memcache、Redis 方案

該方案經過在客戶端單獨部署緩存的方式來解決熱點 Key 問題。

使用過程當中 Client 首先訪問服務層，再對同一主機上的緩存層進行訪問。

該種解決方案具備就近訪問、速度快、沒有帶寬限制的優勢，可是同時也存在如下問題。

• 內存資源浪費

• 髒讀問題

3. 使用本地緩存方案

使用本地緩存則存在如下問題：

• 須要提早獲知熱點

• 緩存容量有限

• 不一致性時間增加

• 熱點 Key 遺漏

傳統的熱點解決方案都存在各類各樣的問題，那麼究竟該如何解決熱點問題呢？

四、讀寫分離方案解決熱讀

架構中各節點的做用以下：

一、SLB 層作負載均衡

二、Proxy 層作讀寫分離自動路由

三、Master 負責寫請求

四、ReadOnly 節點負責讀請求

五、Slave 節點和 Master 節點作高可用

實際過程當中 Client 將請求傳到 SLB，SLB 又將其分發至多個 Proxy 內，經過 Proxy 對請求的識別，將其進行分類發送。

例如，將同爲 Write 的請求發送到 Master 模塊內，而將 Read 的請求發送至 ReadOnly 模塊。

而模塊中的只讀節點能夠進一步擴充，從而有效解決熱點讀的問題。

讀寫分離同時具備能夠靈活擴容讀熱點能力、能夠存儲大量熱點Key、對客戶端友好等優勢。

五、熱點數據解決方案

該方案經過主動發現熱點並對其進行存儲來解決熱點 Key 的問題。

首先 Client 也會訪問 SLB，而且經過 SLB 將各類請求分發至 Proxy 中，Proxy 會按照基於路由的方式將請求轉發至後端的 Redis 中。

在熱點 key 的解決上是採用在服務端增長緩存的方式進行。

具體來講就是在 Proxy 上增長本地緩存，本地緩存採用 LRU 算法來緩存熱點數據，後端 db 節點增長熱點數據計算模塊來返回熱點數據。

Proxy 架構的主要有如下優勢：

一、Proxy 本地緩存熱點，讀能力可水平擴展

二、DB 節點定時計算熱點數據集合

三、DB 反饋 Proxy 熱點數據

四、對客戶端徹底透明，不需作任何兼容

四. 熱點 key 處理

熱點數據的讀取

在熱點 Key 的處理上主要分爲寫入跟讀取兩種形式，在數據寫入過程當 SLB 收到數據 K1 並將其經過某一個 Proxy 寫入一個 Redis，完成數據的寫入。

倘若通過後端熱點模塊計算髮現 K1 成爲熱點 key 後， Proxy 會將該熱點進行緩存，當下次客戶端再進行訪問 K1 時，能夠不經 Redis。

最後因爲 proxy 是能夠水平擴充的，所以能夠任意加強熱點數據的訪問能力。

熱點數據的發現

對於 db 上熱點數據的發現，首先會在一個週期內對 Key 進行請求統計，在達到請求量級後會對熱點 Key 進行熱點定位，並將全部的熱點 Key 放入一個小的 LRU 鏈表內。

在經過 Proxy 請求進行訪問時，若 Redis 發現待訪點是一個熱點，就會進入一個反饋階段，同時對該數據進行標記。

DB 計算熱點時，主要運用的方法和優點有：

一、基於統計閥值的熱點統計

二、基於統計週期的熱點統計

三、基於版本號實現的無需重置初值統計方法

四、DB 計算同時具備對性能影響極其微小、內存佔用極其微小等優勢

五. 方案對比

經過上述對比分析能夠看出，在解決熱點 Key 上較傳統方法相比都有較大的提升，不管是基於讀寫分離方案仍是熱點數據解決方案，在實際處理環境中均可以作靈活的水平能力擴充、都對客戶端透明、都有必定的數據不一致性。

此外讀寫分離模式能夠存儲更大量的熱點數據，而基於 Proxy 的模式有成本上的優點。

End

做者：梁盼

來源：https://yq.aliyun.com/articles/672690

本文版權歸做者全部

長按下圖二維碼，即刻關注【狸貓技術窩】 

阿里、京東、美團、字節跳動 頂尖技術專家坐鎮 

爲IT人打造一個 「有溫度」 的技術窩！