架構與思維：如何應對Redis熱Key？

Brand發表於2023-12-25
架構Redis

★ Redis系列文章

Redis系列1：深刻理解高效能Redis的本質
Redis系列2：資料持久化提高可用性
Redis系列3：高可用之主從架構
Redis系列4：高可用之Sentinel(哨兵模式）
Redis系列5：深入分析Cluster 叢集模式
追求效能極致：Redis6.0的多執行緒模型
追求效能極致：客戶端快取帶來的革命
Redis系列8：Bitmap實現億萬級資料計算
Redis系列9：Geo 型別賦能億級地圖位置計算
Redis系列10：HyperLogLog實現海量資料基數統計
Redis系列11：記憶體淘汰策略
Redis系列12：Redis 的事務機制
Redis系列13：分散式鎖實現
Redis系列14：使用List實現訊息佇列
Redis系列15：使用Stream實現訊息佇列
Redis系列16：聊聊布隆過濾器（原理篇）
Redis系列17：聊聊布隆過濾器（實踐篇）
Redis系列18：過期資料的刪除策略
Redis系列19：LRU記憶體淘汰演算法分析
Redis系列20：LFU記憶體淘汰演算法分析
Redis系列21：快取與資料庫的資料一致性討論
Redis系列22：Redis 的Pub/Sub能力
Redis系列23：效能最佳化指南
Redis系列24：Redis使用規範

1 什麼是Redis HotKey?

分散式系統繞不開的核心點之一的就是資料快取，有了快取的支撐，系統的整體吞吐量會有很大的提升。我們透過使用快取，我們把頻繁查詢的資料由磁碟排程到快取記憶體中，保證資料的高效率讀寫。
在網際網路的大流量場景下，我們經常會遇到一些熱點的資訊需要儲存到Redis中，而這種訪問頻率高的Key，稱為 Hot Key。
Hot Key 處理不好，會產生一些問題。比如短時間的群蜂效應（群蜂請求），大量請求會在短時間內朝著Redis服務衝擊，很可能會導致被訪問的Redis伺服器壓力劇增，甚至可能將Redis伺服器擊垮。
Redis服務關了之後，那對這個Key的請求，都會直接透過快取層請求到我們的資料庫中，資料庫效能遠低於快取記憶體，這樣的結果就是直接壓垮資料庫，進而導致後端服務不可用，造成整體雪崩。

關於快取雪崩、快取擊穿，我們在之前的的文章 『一次快取雪崩的災難覆盤』、『 架構與思維：再聊快取擊穿』中詳細討論過，可以回頭看看。

2 Hot Key出現的場景

Hot Key的主要場景包括如下：

  • 電商商品秒殺、活動積分競拍、熱點驚爆新聞等

    • 雙十一、618 的商品秒殺，造成短時間內某寶或者夕夕上的爆款商品被瀏覽百萬次
    • 某博上的驚爆新聞等引發大量圍觀，造成一個redis快取資訊被群蜂衝擊，熱點Key問題造成服務雪崩，某博研發同學被迫加班修復

  • 請求分片集中，排程不合理，超過單臺Redis服務的吞吐瓶頸和效能極限
    Redis快取會採用分片進行資料管理和效能提升。服務端對資料進行訪問時，會透過一些負載均衡策略進行訪問平衡，但是類似hash計算，也有可能會落入同一臺redis伺服器，如果瞬間訪問量過大，超過主機吞吐極限時，就會導致熱點 Key 現象發生。

  • 突發事件
    系統故障、駭客攻擊、自然災害等，導致大量的使用者訪問某個特定的Redis Key。

3 Hot Key產生的危害

在Redis中，Hot Key的危害主要體現在以下幾個方面：

  1. 單點訪問頻率過高：Hot Key會導致大部分的訪問流量集中在某一個Redis例項上，使得該例項的負載過高，可能會導致該例項崩潰，影響線上業務。
  2. 分片服務癱瘓：Redis叢集會分很多個分片，每個分片有其要處理的資料範圍。當某一個分片被頻繁請求，該分片服務就可能會癱瘓。
  3. Redis分散式叢集優勢弱化：如果請求不夠均衡，過於單點，那麼Redis分散式叢集的優勢也必然被弱化。
  4. 可能造成資損：在極端場景下，容易發生邊界資料處理不及時，在訂單等場景下，可能造成資損。
  5. 引發快取擊穿：如果快取請求不到，就會去請求資料庫。如果請求過於集中，Redis承載不了，就會有大量請求打到資料庫。此時，可能引發資料庫服務癱瘓，進而引發系統雪崩。我們在之前的文章中，大量討論到 快取擊穿、快取雪崩、快取穿透
  6. CPU佔用高，影響其他服務：單個分片CPU佔用率過高，其他分片無法擁有CPU資源，從而被影響。

4 如何監測並分析Hot Key

  1. 容量評估
    聯網的業務場景具備一定規律的，根據一些決策樹，結合業務場景，可以分析出哪些是熱點場景，哪些資訊可能是Hot Ke，比如

    • 雙11、618的秒殺商品、積分競拍商品，那麼這個商品資訊、競拍/購買操作都是熱操作，關聯的Redis資訊都可能是HotKey。
    • 比如突發的新聞熱點，依照畫像識別，資料不斷攀升，在某個時間點有機率會成為HotKey新聞，需要提前干預

  2. 業務埋點上報
    這種方式low一點，需要切入我們的業務程式碼進行埋點，加入對Redis Key 呼叫次數的統計，並把收集到的資料上報到統一的服務進行聚合計算，缺點就是對業務有一定的侵入性。

  3. 使用Redis自帶命令
    可以使用INFO命令獲取關於Redis伺服器的各種資訊，包括鍵的讀寫次數。透過定期執行INFO命令並分析返回的資訊，可以判斷哪些鍵是Hot Key。另外，Redis 4.0.3提供了redis-cli的熱點key發現功能，執行redis-cli時加上–hotkeys選項即可。

  4. 使用第三方工具
    如redis-faina是一個現成的分析工具，可以用來分析Redis中的Hot Key。

  5. 使用Redis監控工具
    如使用Redis Exporter可以匯出Redis伺服器的各種資訊，包括鍵的訪問頻率等，方便進行監控和分析。

以上是Redis監測並分析Hot Key的幾種常見方法，可以根據實際需求選擇適合的方法進行操作。

5 如何避免Hot Key引發線上故障

解決Redis中的熱key問題，可以採取以下幾種解決方案：

  1. 快取預熱
    既然是可預見的HotKey，那麼快取預熱是一個好辦法，比如雙11開啟活動前，熱點新聞爆出之後，預先載入一些熱key的資料到快取中，以減少對資料庫的衝擊
    image

  2. 快取擊穿處理
    根據上面的監測預判一些可能會成為HotKey的資訊，對快取擊穿進行一些應對處理。詳細可以參考『 架構與思維：再聊快取擊穿』的4.5、4.6、4.7節。
    大概如下：

  • 短暫降級之備選快取
    image

  • 短暫降級之客戶端快取（Redis 6.0）
    image

  • 短暫降級之空初始值
    image

  1. 分散式快取
    透過分散式快取系統來分散請求負載，避免單一節點壓力過大。現在的Redis高可用部署模式最常見的是主從和Cluster，無論哪一種，都會降低單點帶來的影響。
    image

  2. 限流和降級
    可以使用 Hystrix進行限流 + 降級 ，比如一下子來了1W個請求，不是當前系統的吞吐能力能夠承受的，假設單秒TPS的能力只能是 5000個，那麼剩餘的 5000 請求就可以走限流邏輯。
    可以設定一些預設值，然後呼叫我們自己降級邏輯去FallBack，保護最後的 MySQL 不會被大量的請求掛起。 除了Hystrix之外，阿里的Sentinel 和 Google的RateLimiter 都是不錯的選擇。

Sentinel 漏桶演算法
image

RateLimiter 令牌桶演算法
image

  1. 最佳化資料結構和演算法
    透過最佳化資料結構和演算法來減少對熱key的訪問和更新操作。

  2. 定期清理過期資料
    定期清理過期資料可以避免過多的熱key佔用快取空間，從而減少快取分片服務的壓力。

  3. 使用二級快取
    如JVM本地快取來實現二級快取，減少Redis的讀請求，可以先從本地快取中取，取不到再去redis中去取，Redis再取不到採取資料庫中取。
    提供了多層保障。

6 總結

本文主要介紹了Redis中的熱Key(Hot Key)產生的原因，討論監測和排查Hot Key的方法，以及採用哪些解決方案來避免Hot Key引發線上故障。

相關文章