Redis 作為主流技術(shù)，應(yīng)用場景非常多，許多大中小廠面試都列為重點(diǎn)考察內(nèi)容

前幾天有星球小夥伴學(xué)習(xí)時(shí)，遇到下面幾個(gè)問題，來諮詢Tom哥

考慮到這些問題比較高頻，工作中常會(huì)遇到，這裡寫篇文章系統(tǒng)講解下

問題描述：

向你提問：在複習(xí)redis時(shí)，有些疑問，麻煩看：?

如果redis集群出現(xiàn)資料傾斜，資料分配不均，該如何解決？

處理hotKey時(shí)，為key建立多個(gè)副本，如k-1，k-2…， 如何讓這些副本能均勻?qū)懭耄咳绾尉鶆蛟L問？

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

回覆：

#分散式快取作為效能加速器，在系統(tǒng)最佳化中承擔(dān)著非常重要的角色。相較於本地緩存，雖然增加了一次網(wǎng)路傳輸，大約佔(zhàn)用不到 1 毫秒外，但卻有集中化管理的優(yōu)勢，並支援非常大的儲(chǔ)存容量。

分散式快取領(lǐng)域，目前應(yīng)用比較廣泛的要數(shù)Redis 了，該框架是純記憶體儲(chǔ)存，單執(zhí)行緒執(zhí)行指令，擁有豐富的底層資料結(jié)構(gòu)，支援多種維度的資料儲(chǔ)存和查找。

當(dāng)然，資料量一大，各種問題就出現(xiàn)了，例如：資料傾斜、資料熱點(diǎn)等

什麼是資料傾斜？

單一機(jī)器的硬體配置有上限制約，一般我們會(huì)採用分散式架構(gòu)將多臺(tái)機(jī)器組成一個(gè)集群，下圖的集群就是由三臺(tái)Redis單機(jī)組成。客戶端透過一定的路由策略，將讀寫請(qǐng)求轉(zhuǎn)送到具體的實(shí)例上。

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

#

資料傾斜有哪些原因呢？

1、存在大key

#例如儲(chǔ)存一個(gè)或多個(gè)String 類型的bigKey 數(shù)據(jù)，記憶體佔(zhàn)用量很大。

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

頻繁的大key讀寫，記憶體資源消耗比較重，同時(shí)給網(wǎng)路傳輸帶了極大的壓力，進(jìn)而導(dǎo)致請(qǐng)求回應(yīng)變慢，引發(fā)雪崩效應(yīng)，最後系統(tǒng)各種超時(shí)報(bào)警。

#：

#非常簡單，採用 <span style="font-size: 16px;">化整為零</span>的策略，將一個(gè)bigKey分割為多個(gè)小key，獨(dú)立維護(hù)，成本會(huì)降低很多。當(dāng)然這個(gè)拆也講究些原則，既要考慮業(yè)務(wù)場景也要考慮訪問場景，將關(guān)聯(lián)緊密的放在一起。

例如：有個(gè)RPC介面內(nèi)部對(duì)Redis 有依賴，之前訪問一次就可以拿到全部數(shù)據(jù)，拆分將要控制單值的大小，也要控制訪問的次數(shù)，畢竟呼叫次數(shù)增加了，會(huì)拉大整體的介面回應(yīng)時(shí)間。

浙江的政府機(jī)構(gòu)都在提倡優(yōu)化流程，最多跑一次，都是一個(gè)道理。

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

##Redis 採用單執(zhí)行緒執(zhí)行指令，從而保證了原子性。當(dāng)採用叢集部署後，為了解決mset、lua 腳本等對(duì)多key 批次操作，為了確保不同的 key 能路由到同一個(gè) Redis 實(shí)例上，引入了 HashTag 機(jī)制。

用法也很簡單，使用{}<span style="font-size: 16px;"></span>#大括號(hào)，指定key只計(jì)算大括號(hào)內(nèi)字串的哈希，從而將不同key的健值對(duì)插入到同一個(gè)哈希槽。

舉例：

#

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ù)程式碼，有沒有引進(jìn)HashTag ，將太多的key路由到了一個(gè)實(shí)例。結(jié)合具體場景，考慮如何做下拆分。

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

3、slot 槽位分配不均

#如果採用Redis Cluster 的部署方式，叢集中的資料庫被分成16384個(gè)槽（slot），資料庫中的每個(gè)健都屬於這16384個(gè)槽的其中一個(gè)，集群中的每個(gè)節(jié)點(diǎn)可以處理的0個(gè)或最多16384個(gè)槽。

你可以手動(dòng)做遷移，將一個(gè)比較大的 slot 遷移到稍微空閒的機(jī)器上，保證儲(chǔ)存和存取的均勻性。

#什麼是快取熱點(diǎn)？

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

# #1、複製多份副本

我們可以在key的後面拼上有序編號(hào)，例如key#01、key#02。 。 。 key#10多個(gè)副本，這些加工後的key位於多個(gè)快取節(jié)點(diǎn)上。

客戶端每次存取時(shí)，只需要在原key的基礎(chǔ)上拼接一個(gè)分片數(shù)上限的隨機(jī)數(shù)，將請(qǐng)求路由不到的實(shí)例節(jié)點(diǎn)。

注意：快取一般都會(huì)設(shè)定過期時(shí)間，為了避免快取的集中失效，我們對(duì)快取的過期時(shí)間盡量不要一樣，可以在預(yù)設(shè)的基礎(chǔ)上增加一個(gè)隨機(jī)數(shù)。 至於資料路由的均勻性，這個(gè)由 Hash 演算法來保證。

2、本機(jī)記憶體快取

####把熱點(diǎn)資料緩存在客戶端的本機(jī)記憶體中，並且設(shè)定一個(gè)失效時(shí)間。對(duì)於每次讀取請(qǐng)求，將首先檢查該資料是否存在於本機(jī)快取中，如果存在則直接傳回，如果不存在再去存取分散式快取的伺服器。 ############本機(jī)記憶體快取徹底「解放」了快取伺服器，不會(huì)對(duì)快取伺服器有任何壓力。 ############缺點(diǎn)：即時(shí)感知最新的快取資料有點(diǎn)麻煩，會(huì)產(chǎn)生資料不一致的情況。我們可以設(shè)定一個(gè)比較短的過期時(shí)間，採用被動(dòng)更新。當(dāng)然，也可以用監(jiān)控機(jī)制，如果感知到資料已經(jīng)發(fā)生了變化，就及時(shí)更新本地快取。 ##########

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

Redis Cluster 叢集有16384個(gè)哈希槽，每個(gè)<span style="font-size: 16px;">key</span>透過<span style="font-size: 16px;">#CRC16</span>校驗(yàn)後對(duì)<span style="font-size: 16px;">16384</span>取模來決定要放置哪個(gè)槽。叢集的每個(gè)節(jié)點(diǎn)負(fù)責(zé)一部分hash槽，舉個(gè)例子，例如目前叢集有3個(gè)節(jié)點(diǎn)，那麼<span style="font-size: 16px;">node-1</span> 包含0 到5460 號(hào)哈希槽，<span style="font-size: 16px;">node-2</span> 包含5461 到10922 號(hào)哈希槽，<span style="font-size: 16px;">node-3</span>包含10922 ?到16383 號(hào)哈希槽。

#一致性雜湊演算法是1997年麻省理工學(xué)院的Karger 等人提出了，為的就是解決分散式快取的問題。

一致性雜湊演算法本質(zhì)上也是一種取模演算法，不同於以伺服器數(shù)量取模，一致性雜湊是對(duì)固定值 2^32 取模。

公式= hash（key） % 2^32

其取模的結(jié)果必然是在[0, 2^32-1] 這個(gè)區(qū)間中的整數(shù)，從圓上映射的位置開始順時(shí)針方向找到的第一個(gè)節(jié)點(diǎn)即為儲(chǔ)存key的節(jié)點(diǎn)

#

一致性雜湊演算法大大緩解了擴(kuò)容或縮容導(dǎo)致的快取失效問題，只影響本節(jié)點(diǎn)負(fù)責(zé)的那一小段key。如果叢集的機(jī)器不多，且平時(shí)單機(jī)的負(fù)載水位很高，某節(jié)點(diǎn)宕機(jī)帶來的壓力很容易引發(fā)雪崩效應(yīng)。

舉例：

Redis叢集總共有4臺(tái)機(jī)器，假設(shè)資料分佈均衡，每臺(tái)機(jī)器承擔(dān)四分之一的流量，如果某一臺(tái)機(jī)器突然掛了，順時(shí)針方向下一臺(tái)機(jī)器將要承擔(dān)這多出來的四分之一流量，最終要承擔(dān)二分之一的流量，還是有點(diǎn)恐怖。

但是如果採用<span style="font-size: 16px;">CRC16</span>#計(jì)算後，並結(jié)合槽位與實(shí)例的綁定關(guān)係，無論是擴(kuò)容還是縮容，只需將對(duì)應(yīng)節(jié)點(diǎn)的key做下資料平滑遷移，廣播儲(chǔ)存新的槽位映射關(guān)係，不會(huì)產(chǎn)生快取失效，彈性很高。

另外，如果伺服器節(jié)點(diǎn)配置存在差異化，我們可以自訂分配不同節(jié)點(diǎn)負(fù)責(zé)的 slot 編號(hào)，調(diào)整不同節(jié)點(diǎn)的負(fù)載能力，非常方便。