解決 Redis 數(shù)據(jù)傾斜、熱點等問題

更新時間：2022年12月13日 11:46:04 作者：洗刷先生

?單臺機(jī)器的硬件配置有上限制約，一般我們會采用分布式架構(gòu)將多臺機(jī)器組成一個集群，這篇文章主要介紹了解決 Redis 數(shù)據(jù)傾斜、熱點等問題,需要的朋友可以參考下

1.如果redis集群出現(xiàn)數(shù)據(jù)傾斜，數(shù)據(jù)分配不均，該如何解決？

2.處理hotKey時，為key創(chuàng)建多個副本，如k-1，k-2…，如何讓這些副本能均勻?qū)懭?？如何均勻訪問？

3.redis使用hash slot來維護(hù)集群。與一致性哈希類似，都可以避免全量遷移。為什么不直接使用一致性hash？

分布式緩存作為性能加速器，在系統(tǒng)優(yōu)化中承擔(dān)著非常重要的角色。相比本地緩存，雖然增加了一次網(wǎng)絡(luò)傳輸，大約占用不到 1 毫秒外，但是卻有集中化管理的優(yōu)勢，并支持非常大的存儲容量。

分布式緩存領(lǐng)域，目前應(yīng)用比較廣泛的要數(shù) Redis 了，該框架是純內(nèi)存儲存，單線程執(zhí)行命令，擁有豐富的底層數(shù)據(jù)結(jié)構(gòu)，支持多種維度的數(shù)據(jù)存儲和查找。

當(dāng)然，數(shù)據(jù)量一大，各種問題就出現(xiàn)了，比如：數(shù)據(jù)傾斜、數(shù)據(jù)熱點等

什么是數(shù)據(jù)傾斜？

單臺機(jī)器的硬件配置有上限制約，一般我們會采用分布式架構(gòu)將多臺機(jī)器組成一個集群，下圖的集群就是由三臺Redis單機(jī)組成?？蛻舳送ㄟ^一定的路由策略，將讀寫請求轉(zhuǎn)發(fā)到具體的實例上。

由于業(yè)務(wù)數(shù)據(jù)特殊性，按照指定的分片規(guī)則，可能導(dǎo)致不同的實例上數(shù)據(jù)分布不均勻，大量的數(shù)據(jù)集中到了一臺或者幾臺機(jī)器節(jié)點上計算，從而導(dǎo)致這些節(jié)點負(fù)載多大，而其他節(jié)點處于空閑等待中，導(dǎo)致最終整體效率低下。

數(shù)據(jù)傾斜有哪些原因呢？

1、存在大key

比如存儲一個或多個 String 類型的 bigKey 數(shù)據(jù)，內(nèi)存占用很大。

Tom哥之前排查過這種問題，有同事開發(fā)時為了省事，采用JSON格式，將多個業(yè)務(wù)數(shù)據(jù)合并到一個 value，只關(guān)聯(lián)一個key，導(dǎo)致了這個鍵值對容量達(dá)到了幾百M。

頻繁的大key讀寫，內(nèi)存資源消耗比較重，同時給網(wǎng)絡(luò)傳輸帶了極大的壓力，進(jìn)而導(dǎo)致請求響應(yīng)變慢，引發(fā)雪崩效應(yīng)，最后系統(tǒng)各種超時報警。

解決方案：

辦法非常簡單，采用化整為零的策略，將一個bigKey拆分為多個小key，獨立維護(hù)，成本會降低很多。當(dāng)然這個拆也講究些原則，既要考慮業(yè)務(wù)場景也要考慮訪問場景，將關(guān)聯(lián)緊密的放到一起。

比如：有個RPC接口內(nèi)部對 Redis 有依賴，之前訪問一次就可以拿到全部數(shù)據(jù)，拆分將要控制單值的大小，也要控制訪問的次數(shù)，畢竟調(diào)用次數(shù)增多了，會拉大整體的接口響應(yīng)時間。

2、HashTag 使用不當(dāng)

Redis 采用單線程執(zhí)行命令，從而保證了原子性。當(dāng)采用集群部署后，為了解決mset、lua 腳本等對多key 批量操作，為了保證不同的 key 能路由到同一個 Redis 實例上，引入了 HashTag 機(jī)制。

用法也很簡單，使用{}大括號，指定key只計算大括號內(nèi)字符串的哈希，從而將不同key的健值對插入到同一個哈希槽。

舉個例子：

192.168.0.1:6380> CLUSTER KEYSLOT testtag
(integer) 764
192.168.0.1:6380> CLUSTER KEYSLOT {testtag}
(integer) 764
192.168.0.1:6380> CLUSTER KEYSLOT mykey1{testtag}
(integer) 764
192.168.0.1:6380> CLUSTER KEYSLOT mykey2{testtag}
(integer) 764

check 下業(yè)務(wù)代碼，有沒有引入HashTag，將太多的key路由到了一個實例。結(jié)合具體場景，考慮如何做下拆分。

就像 RocketMQ 一樣，很多時候只要能保證分區(qū)有序，就可以滿足我們的業(yè)務(wù)需求。具體實戰(zhàn)中，要找到這個平衡點，而不是為了解決問題而解決問題。

3、slot 槽位分配不均

如果采用 Redis Cluster 的部署方式，集群中的數(shù)據(jù)庫被分為16384個槽（slot），數(shù)據(jù)庫中的每個健都屬于這16384個槽的其中一個，集群中的每個節(jié)點可以處理的0個或最多16384個槽。

你可以手動做遷移，將一個比較大的 slot 遷移到稍微空閑的機(jī)器上，保證存儲和訪問的均勻性。

什么是緩存熱點？

緩存熱點是指大部分甚至所有的業(yè)務(wù)請求都命中同一份緩存數(shù)據(jù)，給緩存服務(wù)器帶來了巨大壓力，甚至超過了單機(jī)的承載上限，導(dǎo)致服務(wù)器宕機(jī)。

解決方案：

1、復(fù)制多份副本

我們可以在key的后面拼上有序編號，比如key#01、key#02。。。key#10多個副本，這些加工后的key位于多個緩存節(jié)點上。

客戶端每次訪問時，只需要在原key的基礎(chǔ)上拼接一個分片數(shù)上限的隨機(jī)數(shù)，將請求路由不到的實例節(jié)點。

注意：緩存一般都會設(shè)置過期時間，為了避免緩存的集中失效，我們對緩存的過期時間盡量不要一樣，可以在預(yù)設(shè)的基礎(chǔ)上增加一個隨機(jī)數(shù)。

至于數(shù)據(jù)路由的均勻性，這個由 Hash 算法來保證

2、本地內(nèi)存緩存

把熱點數(shù)據(jù)緩存在客戶端的本地內(nèi)存中，并且設(shè)置一個失效時間。對于每次讀請求，將首先檢查該數(shù)據(jù)是否存在于本地緩存中，如果存在則直接返回，如果不存在再去訪問分布式緩存的服務(wù)器。

好思路

本地內(nèi)存緩存徹底“解放”了緩存服務(wù)器，不會對緩存服務(wù)器有任何壓力。

缺點：實時感知最新的緩存數(shù)據(jù)有點麻煩，會產(chǎn)生數(shù)據(jù)不一致的情況。我們可以設(shè)置一個比較短的過期時間，采用被動更新。當(dāng)然，也可以用監(jiān)控機(jī)制，如果感知到數(shù)據(jù)已經(jīng)發(fā)生了變化，及時更新本地緩存。

Redis Cluster 為什么不用一致性Hash?

Redis Cluster 集群有16384個哈希槽，每個key通過CRC16校驗后對16384取模來決定放置哪個槽。集群的每個節(jié)點負(fù)責(zé)一部分hash槽，舉個例子，比如當(dāng)前集群有3個節(jié)點，那么 node-1 包含 0 到 5460 號哈希槽，node-2 包含 5461 到 10922 號哈希槽，node-3包含 10922 到 16383 號哈希槽。