架构与思维:如何应对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 +