架构与思维：如何应对Redis热Key？
★ 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的危害主要體現在以下幾個方面：
- 單點訪問頻率過高：Hot Key會導致大部分的訪問流量集中在某一個Redis實例上，使得該實例的負載過高，可能會導致該實例崩潰，影響線上業務。
- 分片服務癱瘓：Redis集群會分很多個分片，每個分片有其要處理的數據范圍。當某一個分片被頻繁請求，該分片服務就可能會癱瘓。
- Redis分布式集群優勢弱化：如果請求不夠均衡，過于單點，那么Redis分布式集群的優勢也必然被弱化。
- 可能造成資損：在極端場景下，容易發生邊界數據處理不及時，在訂單等場景下，可能造成資損。
- 引發緩存擊穿：如果緩存請求不到，就會去請求數據庫。如果請求過于集中，Redis承載不了，就會有大量請求打到數據庫。此時，可能引發數據庫服務癱瘓，進而引發系統雪崩。我們在之前的文章中，大量討論到 緩存擊穿、緩存雪崩、緩存穿透
- CPU占用高，影響其他服務：單個分片CPU占用率過高，其他分片無法擁有CPU資源，從而被影響。
4 如何監測并分析Hot Key
-
容量評估
聯網的業務場景具備一定規律的，根據一些決策樹，結合業務場景，可以分析出哪些是熱點場景，哪些信息可能是Hot Ke，比如- 雙11、618的秒殺商品、積分競拍商品，那么這個商品信息、競拍/購買操作都是熱操作，關聯的Redis信息都可能是HotKey。
- 比如突發的新聞熱點，依照畫像識別，數據不斷攀升，在某個時間點有概率會成為HotKey新聞，需要提前干預
-
業務埋點上報
這種方式low一點，需要切入我們的業務代碼進行埋點，加入對Redis Key 調用次數的統計，并把收集到的數據上報到統一的服務進行聚合計算，缺點就是對業務有一定的侵入性。 -
使用Redis自帶命令
可以使用INFO命令獲取關于Redis服務器的各種信息，包括鍵的讀寫次數。通過定期執行INFO命令并分析返回的信息，可以判斷哪些鍵是Hot Key。另外，Redis 4.0.3提供了redis-cli的熱點key發現功能，執行redis-cli時加上–hotkeys選項即可。 -
使用第三方工具
如redis-faina是一個現成的分析工具，可以用來分析Redis中的Hot Key。 -
使用Redis監控工具
如使用Redis Exporter可以導出Redis服務器的各種信息，包括鍵的訪問頻率等，方便進行監控和分析。
以上是Redis監測并分析Hot Key的幾種常見方法，可以根據實際需求選擇適合的方法進行操作。
5 如何避免Hot Key引發線上故障
解決Redis中的熱key問題，可以采取以下幾種解決方案：
-
緩存預熱
既然是可預見的HotKey，那么緩存預熱是一個好辦法，比如雙11開啟活動前，熱點新聞爆出之后，預先加載一些熱key的數據到緩存中，以減少對數據庫的沖擊 -
緩存擊穿處理
根據上面的監測預判一些可能會成為HotKey的信息，對緩存擊穿進行一些應對處理。詳細可以參考『 架構與思維：再聊緩存擊穿』的4.5、4.6、4.7節。
大概如下：
-
短暫降級之備選緩存
-
短暫降級之客戶端緩存（Redis 6.0）
-
短暫降級之空初始值
-
分布式緩存
通過分布式緩存系統來分散請求負載，避免單一節點壓力過大?，F在的Redis高可用部署模式最常見的是主從和Cluster，無論哪一種，都會降低單點帶來的影響。 -
限流和降級
可以使用 Hystrix進行限流 + 降級 ，比如一下子來了1W個請求，不是當前系統的吞吐能力能夠承受的，假設單秒TPS的能力只能是 5000個，那么剩余的 5000 請求就可以走限流邏輯。
可以設置一些默認值，然后調用我們自己降級邏輯去FallBack，保護最后的 MySQL 不會被大量的請求掛起。 除了Hystrix之外，阿里的Sentinel 和 Google的RateLimiter 都是不錯的選擇。
Sentinel 漏桶算法
RateLimiter 令牌桶算法
-
優化數據結構和算法
通過優化數據結構和算法來減少對熱key的訪問和更新操作。 -
定期清理過期數據
定期清理過期數據可以避免過多的熱key占用緩存空間，從而減少緩存分片服務的壓力。 -
使用二級緩存
如JVM本地緩存來實現二級緩存，減少Redis的讀請求，可以先從本地緩存中取，取不到再去redis中去取，Redis再取不到采取數據庫中取。
提供了多層保障。
6 總結
本文主要介紹了Redis中的熱Key(Hot Key)產生的原因，討論監測和排查Hot Key的方法，以及采用哪些解決方案來避免Hot Key引發線上故障。
總結
以上是生活随笔為你收集整理的架构与思维：如何应对Redis热Key？的全部內容，希望文章能夠幫你解決所遇到的問題。
