Redis 熱點問題發現及通用解決方案

微信公眾號： 深廣大資料Club

關注可瞭解更多大資料相關的諮詢。問題或建議，請公眾號留言;

如果你覺得深廣大資料Club對你有幫助，歡迎轉發朋友圈推薦關注

每當我們擁有一個擁有大量使用者的資料庫時，遇到資料庫中的熱點並不罕見。對於Redis，頻繁訪問分割槽中的相同Key稱為熱點。在本文中，我們將討論熱點的常見原因，評估此問題的影響，並提出有效的解決方案來處理熱點。

熱點的常見原因

原因1：使用者消費資料的大小遠遠大於生產資料的大小，包括熱門專案，熱門新聞，熱門評論和名人直播。

在你的日常工作和生活中出現意外事件，例如：當天降價和促銷某些熱門商品，當其中一件物品被瀏覽或購買數萬次時，需求會更大，並且這種情況會導致熱點問題。

同樣，它已經被大量的熱門新聞，熱門評論，明星直播等釋出和觀看，這些典型的無讀寫場景也產生了熱點問題。

原因2：請求切片數超過單個伺服器的效能閾值。

在伺服器上訪問一條資料時，通常會對資料進行拆分或切片。在此過程中，將在伺服器上訪問相應的Key。當訪問流量超過伺服器的效能閾值時，會出現熱鍵問題。

熱點問題的影響

• 流量集中，達到物理網路介面卡的上限。

• 請求排隊太多，導致快取的分片服務崩潰。

• 資料庫過載，導致服務雪崩。

如前所述，當伺服器上的熱點請求數超過伺服器上網路介面卡的上限時，由於流量過度集中，伺服器停止提供其他服務。

如果熱點的分佈過於密集，則會快取大量熱點，從而耗盡快取容量並導致快取的分片服務崩潰。

快取服務崩潰後，新生成的請求將快取在後臺數據庫中。由於該資料庫效能不佳，很容易因大量請求而耗盡，導致服務雪崩和效能大幅下降。

推薦解決方案

提高效能的常見解決方案是通過伺服器或客戶端上重建。

Server快取解決方案

客戶端將請求傳送到伺服器。假定伺服器是多執行緒服務，則可以使用基於快取記憶體LRU策略的本地快取記憶體空間。

當伺服器變得擁擠時，它直接將請求轉發回來而不是將它們轉發到資料庫。只有在稍後清除擁塞之後，伺服器才會將請求從客戶端傳送到資料庫並將資料重新寫入快取。

訪問並重建快取。

但是，該程式還存在以下問題：

• 快取失敗時快取多執行緒服務的構建問題

• 快取丟失時快取構建問題

• 髒讀問題

“MemCache + Redis”解決方案

在此解決方案中，在客戶端上部署單獨的快取以解決熱點問題。

採用此解決方案時，客戶端首先訪問服務層，然後訪問同一主機上的快取層。

該解決方案具有以下優勢：就近訪問，高速和零頻寬限制。但是，它也有以下缺點：

• 浪費了記憶體資源

• 髒讀問題

本地快取解決方案

使用本地快取會產生以下問題：

• 必須提前檢測熱點。

• 快取容量有限。

• 不一致的持續時間很長。

• 熱點不完整。

如果傳統的熱點解決方案都有缺陷，那麼如何解決熱點問題呢？

讀/寫拆分解決方案

該解決方案解決了熱點讀取問題。以下描述了體系結構中不同節點的功能：

• 負載平衡在SLB層實現。

• 在代理層實現讀/寫分離和自動路由。

• 寫請求由主節點處理。

• 讀取請求由只讀節點處理。

• HA在從節點和主節點上實現。

實際上，客戶端向SLB傳送請求，SLB將這些請求分發給多個代理。然後，代理識別並分類請求並進一步分發它們。

例如，代理將所有寫請求傳送到主節點，並將所有讀請求傳送到只讀節點。

但是模組中的只讀節點可以進一步擴充套件，從而有效地解決了熱點讀取的問題。

讀寫分離還具有靈活擴容讀取熱點的能力，可以儲存大量熱點關鍵，客戶端友好等優點。

熱點資料解決方案

在此解決方案中，發現並存儲熱點以解決熱點問題。

具體來說，客戶端訪問SLB並通過SLB將請求分發給代理。然後，代理通過路由將請求轉發到後臺Redis。

此外，還在伺服器上添加了快取。

具體而言，將本地快取新增到代理。此快取使用LRU演算法來快取熱點資料。此外，將熱點資料計算模組新增到後臺資料庫節點以返回熱點資料。

代理架構的主要優點是：

• 代理在本地快取熱點資料，其讀取能力可水平擴充套件。

• 資料庫節點定期計算熱點資料集。

• 資料庫將熱點資料反饋給代理。

• 代理體系結構對客戶端是完全透明的，因此不必增加相容性。

處理熱點

讀取熱點資料

熱點處理分為兩個部分：寫入和讀取。在資料寫入期間，SLB接收資料K1並通過代理將其寫入Redis資料庫。

如果K1在後臺熱點模組進行計算後成為熱點，則代理會快取熱點。通過這種方式，客戶端可以在下次繞過Redis時直接訪問K1。

最後，因為代理可以水平擴充套件，所以熱點資料的可訪問性也可以無限增強。

發現熱點資料

在發現期間，資料庫首先計算在一個週期中發生的請求。當請求數達到閾值時，資料庫將找到熱點並將其儲存在LRU列表中。當客戶端通過向代理髮送請求來嘗試訪問資料時，Redis會進入反饋階段並在發現目標訪問點是熱點時標記資料。

資料庫使用以下方法計算熱點：

• 基於統計閾值的熱點統計。

• 基於統計週期的熱點統計。

• 基於版本號的統計資訊收集方法，在使用時不需要重置初始值。

• 計算資料庫上的熱點具有最小的效能影響和輕量級記憶體佔用。

解決方案的比較

從前面的分析可以看出，在解決熱點問題時，這兩種解決方案都是傳統解決方案的改進。此外，讀/寫分離和熱點資料解決方案都支援靈活的容量擴充套件，並且對客戶端是透明的，儘管它們無法確保100％的資料一致性。

讀/寫分離解決方案支援儲存大型熱點資料卷，而基於代理的熱點資料解決方案更具成本效益。

參考連結：

https：//www.alibabacloud.com/blog/redis-hotspot-key-discovery-and-common-solutions_594446?spm=a2c41.12559851.0.0

https://medium.com/@Alibaba_Cloud/redis-hotspot-key-discovery-and-common-solutions-95474d27e0f8