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

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

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

問題描述：

回復(fù)：

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

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

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

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

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

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

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

1、存在大key

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

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

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

解決方案：

辦法非常簡(jiǎn)單，采用<code style='font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace;background-color: rgba(0, 0, 0, 0.06);border-width: 1px;border-style: solid;border-color: rgba(0, 0, 0, 0.08);border-radius: 2px;padding-right: 2px;padding-left: 2px;'><span style="font-size: 16px;">化整為零</span>的策略，將一個(gè)bigKey拆分為多個(gè)小key，獨(dú)立維護(hù)，成本會(huì)降低很多。當(dāng)然這個(gè)拆也講究些原則，既要考慮業(yè)務(wù)場(chǎng)景也要考慮訪問場(chǎng)景，將關(guān)聯(lián)緊密的放到一起。

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

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

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

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

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

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

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

<span style="color: rgb(43, 43, 43);font-size: 16px;">節(jié)點(diǎn)- 1</span>

<span style="color: rgb(0, 0, 0);font-size: 16px;">node-2</span>

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

舉個(gè)例子：

Redis 集群 總共有4臺(tái)機(jī)器，假設(shè)數(shù)據(jù)分布均衡，每臺(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>CRC16計(jì)算后，并結(jié)合槽位與實(shí)例的綁定關(guān)系，無論是擴(kuò)容還是縮容，只需將相應(yīng)節(jié)點(diǎn)的key做下數(shù)據(jù)平滑遷移，廣播存儲(chǔ)新的槽位映射關(guān)系，不會(huì)產(chǎn)生緩存失效，靈活性很高。

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