Redis熱點 Key 問題發現與5種解決方案是什么

本篇文章給大家分享的是有關Redis熱點 Key 問題發現與5種解決方案是什么，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

熱點問題產生的原因大致有以下兩種：

1、用戶消費的數據遠大于生產的數據（熱賣商品、熱點新聞、熱點評論、明星直播）。

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

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

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

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

熱點問題的危害

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

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

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

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

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

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

解決方案

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

1、服務端緩存方案

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

當 Server 本身就擁堵時，Server 不會將請求進一步發送給 DB 而是直接返回，只有當 Server 本身暢通時才會將 Client 請求發送至 DB，并且將該數據重新寫入到緩存中。

此時就完成了緩存的訪問跟重建。

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

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

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

• 3、臟讀問題

2、使用 Memcache、Redis 方案

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

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

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

• 1、內存資源浪費 

• 2、臟讀問題

3、使用本地緩存方案

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

• 1、需要提前獲知熱點 

• 2、緩存容量有限 

• 3、不一致性時間增長 

• 4、熱點 Key 遺漏

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

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

架構中各節點的作用如下：

• 1、SLB 層做負載均衡 

• 2、Proxy 層做讀寫分離自動路由 

• 3、Master 負責寫請求 

• 4、ReadOnly 節點負責讀請求 

• 5、Slave 節點和 Master 節點做高可用

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

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

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

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

5、熱點數據解決方案

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

首先 Client 也會訪問 SLB，并且通過 SLB 將各種請求分發至 Proxy 中，Proxy 會按照基于路由的方式將請求轉發至后端的 Redis 中。

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

具體來說就是在 Proxy 上增加本地緩存，本地緩存采用 LRU 算法來緩存熱點數據，后端 db 節點增加熱點數據計算模塊來返回熱點數據。

Proxy 架構的主要有以下優點：

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

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

• 3、DB 反饋 Proxy 熱點數據 

• 4、對客戶端完全透明，不需做任何兼容

熱點 key 處理

熱點數據的讀取

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

假若經過后端熱點模塊計算發現 K1 成為熱點 key 后， Proxy 會將該熱點進行緩存，當下次客戶端再進行訪問 K1 時，可以不經 Redis。

最后由于 proxy 是可以水平擴充的，因此可以任意增強熱點數據的訪問能力。

熱點數據的發現

對于 db 上熱點數據的發現，首先會在一個周期內對 Key 進行請求統計，在達到請求量級后會對熱點 Key 進行熱點定位，并將所有的熱點 Key 放入一個小的 LRU 鏈表內，在通過 Proxy 請求進行訪問時，若 Redis 發現待訪點是一個熱點，就會進入一個反饋階段，同時對該數據進行標記。

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

• 1、基于統計閥值的熱點統計 

• 2、基于統計周期的熱點統計 

• 3、基于版本號實現的無需重置初值統計方法 

• 4、DB 計算同時具有對性能影響極其微小、內存占用極其微小等優點

方案對比

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

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