建站
咨詢
售后
建站咨詢
新聞中心
大家好，我是Tom哥。
創(chuàng)新互聯(lián)建站長期為成百上千客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺(tái)，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為平桂企業(yè)提供專業(yè)的成都網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)，平桂網(wǎng)站改版等技術(shù)服務(wù)。擁有十載豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。
Redis 作為一門主流技術(shù)，應(yīng)用場景非常多，很多大中小廠面試都列為重點(diǎn)考察內(nèi)容
前幾天有星球小伙伴學(xué)習(xí)時(shí)，遇到下面幾個(gè)問題，來咨詢 Tom哥
考慮到這些問題比較高頻，工作中經(jīng)常會(huì)遇到，這里寫篇文章系統(tǒng)講解下
問題描述：
向你提問：tom哥，在復(fù)習(xí)redis時(shí)，有些疑問，麻煩看看：
1.如果redis集群出現(xiàn)數(shù)據(jù)傾斜，數(shù)據(jù)分配不均，該如何解決？2.處理hotKey時(shí)，為key創(chuàng)建多個(gè)副本，如k-1，k-2…， 如何讓這些副本能均勻?qū)懭?？如何均勻訪問？3.redis使用hash slot來維護(hù)集群。與一致性哈希類似，都可以避免全量遷移。為什么不直接使用一致性hash？
Tom哥 回復(fù)：
分布式緩存作為性能加速器，在系統(tǒng)優(yōu)化中承擔(dān)著非常重要的角色。相比本地緩存，雖然增加了一次網(wǎng)絡(luò)傳輸，大約占用不到 1 毫秒外，但是卻有集中化管理的優(yōu)勢，并支持非常大的存儲(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ī)組成?？蛻舳送ㄟ^一定的路由策略，將讀寫請求轉(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è)鍵值對容量達(dá)到了幾百M(fèi)。
頻繁的大key讀寫，內(nèi)存資源消耗比較重，同時(shí)給網(wǎng)絡(luò)傳輸帶了極大的壓力，進(jìn)而導(dǎo)致請求響應(yīng)變慢，引發(fā)雪崩效應(yīng)，最后系統(tǒng)各種超時(shí)報(bào)警。
解決方案：
辦法非常簡單，采用化整為零的策略，將一個(gè)bigKey拆分為多個(gè)小key，獨(dú)立維護(hù)，成本會(huì)降低很多。當(dāng)然這個(gè)拆也講究些原則，既要考慮業(yè)務(wù)場景也要考慮訪問場景，將關(guān)聯(lián)緊密的放到一起。
比如：有個(gè)RPC接口內(nèi)部對 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 腳本等對多key 批量操作，為了保證不同的 key 能路由到同一個(gè) Redis 實(shí)例上，引入了 HashTag 機(jī)制。
用法也很簡單，使用{}大括號(hào)，指定key只計(jì)算大括號(hào)內(nèi)字符串的哈希，從而將不同key的健值對插入到同一個(gè)哈希槽。
舉個(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ù)代碼，有沒有引入HashTag，將太多的key路由到了一個(gè)實(shí)例。結(jié)合具體場景，考慮如何做下拆分。
就像 RocketMQ 一樣，很多時(shí)候只要能保證分區(qū)有序，就可以滿足我們的業(yè)務(wù)需求。具體實(shí)戰(zhàn)中，要找到這個(gè)平衡點(diǎn)，而不是為了解決問題而解決問題。
3、slot 槽位分配不均
如果采用 Redis Cluster 的部署方式，集群中的數(shù)據(jù)庫被分為16384個(gè)槽（slot），數(shù)據(jù)庫中的每個(gè)健都屬于這16384個(gè)槽的其中一個(gè)，集群中的每個(gè)節(jié)點(diǎn)可以處理的0個(gè)或最多16384個(gè)槽。
你可以手動(dòng)做遷移，將一個(gè)比較大的 slot 遷移到稍微空閑的機(jī)器上，保證存儲(chǔ)和訪問的均勻性。
什么是緩存熱點(diǎn)？
緩存熱點(diǎn)是指大部分甚至所有的業(yè)務(wù)請求都命中同一份緩存數(shù)據(jù)，給緩存服務(wù)器帶來了巨大壓力，甚至超過了單機(jī)的承載上限，導(dǎo)致服務(wù)器宕機(jī)。
解決方案：
1、復(fù)制多份副本
我們可以在key的后面拼上有序編號(hào)，比如key#01、key#02。key#10多個(gè)副本，這些加工后的key位于多個(gè)緩存節(jié)點(diǎn)上。
客戶端每次訪問時(shí)，只需要在原key的基礎(chǔ)上拼接一個(gè)分片數(shù)上限的隨機(jī)數(shù)，將請求路由不到的實(shí)例節(jié)點(diǎn)。
注意：緩存一般都會(huì)設(shè)置過期時(shí)間，為了避免緩存的集中失效，我們對緩存的過期時(shí)間盡量不要一樣，可以在預(yù)設(shè)的基礎(chǔ)上增加一個(gè)隨機(jī)數(shù)。
至于數(shù)據(jù)路由的均勻性，這個(gè)由 Hash 算法來保證。
2、本地內(nèi)存緩存
把熱點(diǎn)數(shù)據(jù)緩存在客戶端的本地內(nèi)存中，并且設(shè)置一個(gè)失效時(shí)間。對于每次讀請求，將首先檢查該數(shù)據(jù)是否存在于本地緩存中，如果存在則直接返回，如果不存在再去訪問分布式緩存的服務(wù)器。
本地內(nèi)存緩存徹底“解放”了緩存服務(wù)器，不會(huì)對緩存服務(wù)器有任何壓力。
缺點(diǎn)：實(shí)時(shí)感知最新的緩存數(shù)據(jù)有點(diǎn)麻煩，會(huì)產(chǎn)生數(shù)據(jù)不一致的情況。我們可以設(shè)置一個(gè)比較短的過期時(shí)間，采用被動(dòng)更新。當(dāng)然，也可以用監(jiān)控機(jī)制，如果感知到數(shù)據(jù)已經(jīng)發(fā)生了變化，及時(shí)更新本地緩存。
Redis Cluster 為什么不用一致性Hash?
Redis Cluster 集群有16384個(gè)哈希槽，每個(gè)key通過CRC16校驗(yàn)后對16384取模來決定放置哪個(gè)槽。集群的每個(gè)節(jié)點(diǎn)負(fù)責(zé)一部分hash槽，舉個(gè)例子，比如當(dāng)前集群有3個(gè)節(jié)點(diǎn)，那么 node-1 包含 0 到 5460 號(hào)哈希槽，node-2 包含 5461 到 10922 號(hào)哈希槽，node-3包含 10922 到 16383 號(hào)哈希槽。
一致性哈希算法是 1997年麻省理工學(xué)院的 Karger 等人提出了，為的就是解決分布式緩存的問題。
一致性哈希算法本質(zhì)上也是一種取模算法，不同于按服務(wù)器數(shù)量取模，一致性哈希是對固定值 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ù)載水位很高，某個(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)恐怖。
但是如果采用 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ù)載能力，非常方便。
文章名稱：如何解決Redis數(shù)據(jù)傾斜、熱點(diǎn)等問題
當(dāng)前鏈接：http://fisionsoft.com.cn/article/dhjhcjj.html
