架构与思维：如何应对Redis热Key？
★ Redis系列文章
Redis系列1：深刻理解高性能Redis的本質(zhì)
Redis系列2：數(shù)據(jù)持久化提高可用性
Redis系列3：高可用之主從架構(gòu)
Redis系列4：高可用之Sentinel(哨兵模式）
Redis系列5：深入分析Cluster 集群模式
追求性能極致：Redis6.0的多線程模型
追求性能極致：客戶端緩存帶來的革命
Redis系列8：Bitmap實(shí)現(xiàn)億萬級數(shù)據(jù)計(jì)算
Redis系列9：Geo 類型賦能億級地圖位置計(jì)算
Redis系列10：HyperLogLog實(shí)現(xiàn)海量數(shù)據(jù)基數(shù)統(tǒng)計(jì)
Redis系列11：內(nèi)存淘汰策略
Redis系列12：Redis 的事務(wù)機(jī)制
Redis系列13：分布式鎖實(shí)現(xiàn)
Redis系列14：使用List實(shí)現(xiàn)消息隊(duì)列
Redis系列15：使用Stream實(shí)現(xiàn)消息隊(duì)列
Redis系列16：聊聊布隆過濾器（原理篇）
Redis系列17：聊聊布隆過濾器（實(shí)踐篇）
Redis系列18：過期數(shù)據(jù)的刪除策略
Redis系列19：LRU內(nèi)存淘汰算法分析
Redis系列20：LFU內(nèi)存淘汰算法分析
Redis系列21：緩存與數(shù)據(jù)庫的數(shù)據(jù)一致性討論
Redis系列22：Redis 的Pub/Sub能力
Redis系列23：性能優(yōu)化指南
Redis系列24：Redis使用規(guī)范
1 什么是Redis HotKey?
分布式系統(tǒng)繞不開的核心點(diǎn)之一的就是數(shù)據(jù)緩存，有了緩存的支撐，系統(tǒng)的整體吞吐量會有很大的提升。我們通過使用緩存，我們把頻繁查詢的數(shù)據(jù)由磁盤調(diào)度到高速緩存中，保證數(shù)據(jù)的高效率讀寫。
在互聯(lián)網(wǎng)的大流量場景下，我們經(jīng)常會遇到一些熱點(diǎn)的信息需要存儲到Redis中，而這種訪問頻率高的Key，稱為 Hot Key。
Hot Key 處理不好，會產(chǎn)生一些問題。比如短時(shí)間的群蜂效應(yīng)（群蜂請求），大量請求會在短時(shí)間內(nèi)朝著Redis服務(wù)沖擊，很可能會導(dǎo)致被訪問的Redis服務(wù)器壓力劇增，甚至可能將Redis服務(wù)器擊垮。
Redis服務(wù)關(guān)了之后，那對這個(gè)Key的請求，都會直接透過緩存層請求到我們的數(shù)據(jù)庫中，數(shù)據(jù)庫性能遠(yuǎn)低于高速緩存，這樣的結(jié)果就是直接壓垮數(shù)據(jù)庫，進(jìn)而導(dǎo)致后端服務(wù)不可用，造成整體雪崩。
關(guān)于緩存雪崩、緩存擊穿，我們在之前的的文章 『一次緩存雪崩的災(zāi)難復(fù)盤』、『 架構(gòu)與思維：再聊緩存擊穿』中詳細(xì)討論過，可以回頭看看。
2 Hot Key出現(xiàn)的場景
Hot Key的主要場景包括如下：
-
電商商品秒殺、活動(dòng)積分競拍、熱點(diǎn)驚爆新聞等
- 雙十一、618 的商品秒殺，造成短時(shí)間內(nèi)某寶或者夕夕上的爆款商品被瀏覽百萬次
- 某博上的驚爆新聞等引發(fā)大量圍觀，造成一個(gè)redis緩存信息被群蜂沖擊，熱點(diǎn)Key問題造成服務(wù)雪崩，某博研發(fā)同學(xué)*加班修復(fù)
-
請求分片集中，調(diào)度不合理，超過單臺Redis服務(wù)的吞吐瓶頸和性能極限
Redis緩存會采用分片進(jìn)行數(shù)據(jù)管理和性能提升。服務(wù)端對數(shù)據(jù)進(jìn)行訪問時(shí)，會通過一些負(fù)載均衡策略進(jìn)行訪問平衡，但是類似hash計(jì)算，也有可能會落入同一臺redis服務(wù)器，如果瞬間訪問量過大，超過主機(jī)吞吐極限時(shí)，就會導(dǎo)致熱點(diǎn) Key 現(xiàn)象發(fā)生。 -
突發(fā)事件
系統(tǒng)故障、黑客攻擊、自然災(zāi)害等，導(dǎo)致大量的用戶訪問某個(gè)特定的Redis Key。
3 Hot Key產(chǎn)生的危害
在Redis中，Hot Key的危害主要體現(xiàn)在以下幾個(gè)方面：
- 單點(diǎn)訪問頻率過高：Hot Key會導(dǎo)致大部分的訪問流量集中在某一個(gè)Redis實(shí)例上，使得該實(shí)例的負(fù)載過高，可能會導(dǎo)致該實(shí)例崩潰，影響線上業(yè)務(wù)。
- 分片服務(wù)癱瘓：Redis集群會分很多個(gè)分片，每個(gè)分片有其要處理的數(shù)據(jù)范圍。當(dāng)某一個(gè)分片被頻繁請求，該分片服務(wù)就可能會癱瘓。
- Redis分布式集群優(yōu)勢弱化：如果請求不夠均衡，過于單點(diǎn)，那么Redis分布式集群的優(yōu)勢也必然被弱化。
- 可能造成資損：在極端場景下，容易發(fā)生邊界數(shù)據(jù)處理不及時(shí)，在訂單等場景下，可能造成資損。
- 引發(fā)緩存擊穿：如果緩存請求不到，就會去請求數(shù)據(jù)庫。如果請求過于集中，Redis承載不了，就會有大量請求打到數(shù)據(jù)庫。此時(shí)，可能引發(fā)數(shù)據(jù)庫服務(wù)癱瘓，進(jìn)而引發(fā)系統(tǒng)雪崩。我們在之前的文章中，大量討論到 緩存擊穿、緩存雪崩、緩存穿透
- CPU占用高，影響其他服務(wù)：單個(gè)分片CPU占用率過高，其他分片無法擁有CPU資源，從而被影響。
4 如何監(jiān)測并分析Hot Key
-
容量評估
聯(lián)網(wǎng)的業(yè)務(wù)場景具備一定規(guī)律的，根據(jù)一些決策樹，結(jié)合業(yè)務(wù)場景，可以分析出哪些是熱點(diǎn)場景，哪些信息可能是Hot Ke，比如- 雙11、618的秒殺商品、積分競拍商品，那么這個(gè)商品信息、競拍/購買操作都是熱操作，關(guān)聯(lián)的Redis信息都可能是HotKey。
- 比如突發(fā)的新聞熱點(diǎn)，依照畫像識別，數(shù)據(jù)不斷攀升，在某個(gè)時(shí)間點(diǎn)有概率會成為HotKey新聞，需要提前干預(yù)
-
業(yè)務(wù)埋點(diǎn)上報(bào)
這種方式low一點(diǎn)，需要切入我們的業(yè)務(wù)代碼進(jìn)行埋點(diǎn)，加入對Redis Key 調(diào)用次數(shù)的統(tǒng)計(jì)，并把收集到的數(shù)據(jù)上報(bào)到統(tǒng)一的服務(wù)進(jìn)行聚合計(jì)算，缺點(diǎn)就是對業(yè)務(wù)有一定的侵入性。 -
使用Redis自帶命令
可以使用INFO命令獲取關(guān)于Redis服務(wù)器的各種信息，包括鍵的讀寫次數(shù)。通過定期執(zhí)行INFO命令并分析返回的信息，可以判斷哪些鍵是Hot Key。另外，Redis 4.0.3提供了redis-cli的熱點(diǎn)key發(fā)現(xiàn)功能，執(zhí)行redis-cli時(shí)加上–hotkeys選項(xiàng)即可。 -
使用第三方工具
如redis-faina是一個(gè)現(xiàn)成的分析工具，可以用來分析Redis中的Hot Key。 -
使用Redis監(jiān)控工具
如使用Redis Exporter可以導(dǎo)出Redis服務(wù)器的各種信息，包括鍵的訪問頻率等，方便進(jìn)行監(jiān)控和分析。
以上是Redis監(jiān)測并分析Hot Key的幾種常見方法，可以根據(jù)實(shí)際需求選擇適合的方法進(jìn)行操作。
5 如何避免Hot Key引發(fā)線上故障
解決Redis中的熱key問題，可以采取以下幾種解決方案：
-
緩存預(yù)熱
既然是可預(yù)見的HotKey，那么緩存預(yù)熱是一個(gè)好辦法，比如雙11開啟活動(dòng)前，熱點(diǎn)新聞爆出之后，預(yù)先加載一些熱key的數(shù)據(jù)到緩存中，以減少對數(shù)據(jù)庫的沖擊 -
緩存擊穿處理
根據(jù)上面的監(jiān)測預(yù)判一些可能會成為HotKey的信息，對緩存擊穿進(jìn)行一些應(yīng)對處理。詳細(xì)可以參考『 架構(gòu)與思維：再聊緩存擊穿』的4.5、4.6、4.7節(jié)。
大概如下：
-
短暫降級之備選緩存
-
短暫降級之客戶端緩存（Redis 6.0）
-
短暫降級之空初始值
-
分布式緩存
通過分布式緩存系統(tǒng)來分散請求負(fù)載，避免單一節(jié)點(diǎn)壓力過大。現(xiàn)在的Redis高可用部署模式最常見的是主從和Cluster，無論哪一種，都會降低單點(diǎn)帶來的影響。 -
限流和降級
可以使用 Hystrix進(jìn)行限流 + 降級 ，比如一下子來了1W個(gè)請求，不是當(dāng)前系統(tǒng)的吞吐能力能夠承受的，假設(shè)單秒TPS的能力只能是 5000個(gè)，那么剩余的 5000 請求就可以走限流邏輯。
可以設(shè)置一些默認(rèn)值，然后調(diào)用我們自己降級邏輯去FallBack，保護(hù)最后的 MySQL 不會被大量的請求掛起。 除了Hystrix之外，阿里的Sentinel 和 Google的RateLimiter 都是不錯(cuò)的選擇。
Sentinel 漏桶算法
RateLimiter 令牌桶算法
-
優(yōu)化數(shù)據(jù)結(jié)構(gòu)和算法
通過優(yōu)化數(shù)據(jù)結(jié)構(gòu)和算法來減少對熱key的訪問和更新操作。 -
定期清理過期數(shù)據(jù)
定期清理過期數(shù)據(jù)可以避免過多的熱key占用緩存空間，從而減少緩存分片服務(wù)的壓力。 -
使用二級緩存
如JVM本地緩存來實(shí)現(xiàn)二級緩存，減少Redis的讀請求，可以先從本地緩存中取，取不到再去redis中去取，Redis再取不到采取數(shù)據(jù)庫中取。
提供了多層保障。
6 總結(jié)
本文主要介紹了Redis中的熱Key(Hot Key)產(chǎn)生的原因，討論監(jiān)測和排查Hot Key的方法，以及采用哪些解決方案來避免Hot Key引發(fā)線上故障。
總結(jié)
以上是生活随笔為你收集整理的架构与思维：如何应对Redis热Key？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 武术套路论文文献
- 下一篇： 使用 PostgreSQL 16.1 +