這篇文章主要為大家展示了“Redis中cluster集群的示例分析”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“Redis中cluster集群的示例分析”這篇文章吧。
1.前言
Redis集群模式主要有2種:
主從集群、分布式集群。
前者主要是為了高可用或是讀寫分離，后者為了更好的存儲數(shù)據(jù)，負(fù)載均衡。
redis集群提供了以下兩個好處
1、將數(shù)據(jù)自動切分(split)到多個節(jié)點
2、當(dāng)集群中的某一個節(jié)點故障時，redis還可以繼續(xù)處理客戶端的請求。
一個 redis 集群包含 16384 個哈希槽（hash slot），數(shù)據(jù)庫中的每個數(shù)據(jù)都屬于這16384個哈希槽中的一個。集群使用公式 CRC16(key) % 16384 來計算鍵 key 屬于哪個槽。集群中的每一個節(jié)點負(fù)責(zé)處理一部分哈希槽。
集群中的主從復(fù)制
集群中的每個節(jié)點都有1個至N個復(fù)制品，其中一個為主節(jié)點，其余的為從節(jié)點，如果主節(jié)點下線了，集群就會把這個主節(jié)點的一個從節(jié)點設(shè)置為新的主節(jié)點，繼續(xù)工作。這樣集群就不會因為一個主節(jié)點的下線而無法正常工作
注意：
1、如果某一個主節(jié)點和他所有的從節(jié)點都下線的話，redis集群就會停止工作了。redis集群不保證數(shù)據(jù)的強一致性，在特定的情況下，redis集群會丟失已經(jīng)被執(zhí)行過的寫命令
2、使用異步復(fù)制（asynchronous replication）是redis 集群可能會丟失寫命令的其中一個原因，有時候由于網(wǎng)絡(luò)原因，如果網(wǎng)絡(luò)斷開時間太長，redis集群就會啟用新的主節(jié)點，之前發(fā)給主節(jié)點的數(shù)據(jù)就會丟失。
2. 主從切換原理
Redis的主從原理與MySQL相似，都是設(shè)置兩臺機器，一主一從。也就是常說的熱備與冷備。設(shè)置主從的同時，設(shè)置兩個哨兵進(jìn)程，用來檢測主節(jié)點是否宕機。若發(fā)現(xiàn)主節(jié)點宕機，立馬從從節(jié)點內(nèi)選取出合適的節(jié)點 作為新的主節(jié)點。這點與VIP(虛擬IP技術(shù)有點相似)。
3.Redis群集TCP端口
每個Redis群集的節(jié)點都需要打開兩個TCP連接，由于這兩個連接就需要兩個端口，分別是用于為客戶端提供服務(wù)的常規(guī)Redis TCP命令端口（例如6379）以及通過將10000和命令端口相加（10000+6379）而獲得的端口，就是集群端口（例如16379）。
第二個大號端口用于群集總線，即使用二進(jìn)制協(xié)議的節(jié)點到節(jié)點通信通道。 節(jié)點使用群集總線進(jìn)行故障檢測，配置更新，故障轉(zhuǎn)移授權(quán)等。 客戶端不應(yīng)嘗試與群集總線端口通信，為了保證Redis命令端口的正常使用，請確保在防火墻中打開這兩個端口，否則Redis群集節(jié)點將無法通信。
命令端口和集群總線端口偏移量是固定的，始終為10000。
請注意，為了讓Redis群集正常工作，您需要為每個節(jié)點：
1、用于與客戶端進(jìn)行通信的普通客戶端通信端口（通常為6379）對所有需要到達(dá)群集的客戶端以及所有其他群集節(jié)點（使用客戶端端口進(jìn)行密鑰遷移）都是開放的。
2、集群總線端口（客戶端端口+ 10000）必須可從所有其他集群節(jié)點訪問。
如果您不打開這兩個TCP端口，則您的群集將無法正常工作。
集群總線使用不同的二進(jìn)制協(xié)議進(jìn)行節(jié)點到節(jié)點的數(shù)據(jù)交換，這更適合于使用很少的帶寬和處理時間在節(jié)點之間交換信息。
4.Redis集群和Docker
目前，Redis群集不支持NAT地址環(huán)境，并且在IP地址或TCP端口被重新映射的一般環(huán)境中。
Docker使用一種叫做端口映射的技術(shù)：Docker容器中運行的程序可能會暴露在與程序認(rèn)為使用的端口不同的端口上。 這對于在同一服務(wù)器中同時使用相同端口運行多個容器很有用。
為了使Docker與Redis Cluster兼容，您需要使用Docker的主機聯(lián)網(wǎng)模式。 請查看Docker文檔中的–net = host選項以獲取更多信息。
5.Redis集群數(shù)據(jù)分片
Redis集群沒有使用一致的散列，而是一種不同的分片形式，其中每個 key 在概念上都是我們稱之為散列槽的部分。
Redis集群中有16384個散列槽，為了計算給定 key 的散列槽，我們簡單地取16384模的CRC16。
Redis集群中的每個節(jié)點負(fù)責(zé)哈希槽的一個子集，例如，您可能有一個具有3個節(jié)點的集群，其中：
1、節(jié)點A包含從0到5500的散列槽。
2、節(jié)點B包含從5501到11000的散列槽。
3、節(jié)點C包含從11001到16383的散列槽。
這允許輕松地添加和刪除集群中的節(jié)點。例如，如果我想添加一個新節(jié)點D，我需要將節(jié)點A，B，C中的一些散列槽移動到D。同樣，如果我想從集群中刪除節(jié)點A，我可以只移動由A使用的散列槽到B和C，當(dāng)節(jié)點A將為空時，我可以將它從群集中徹底刪除。
因為將散列槽從一個節(jié)點移動到另一個節(jié)點不需要停機操作，添加和移除節(jié)點或更改節(jié)點占用的散列槽的百分比也不需要任何停機時間。
只要涉及單個命令執(zhí)行（或整個事務(wù)或Lua腳本執(zhí)行）的所有 key 都屬于同一散列插槽，Redis群集就支持多個 key 操作。用戶可以使用稱為散列標(biāo)簽的概念強制多個 key 成為同一個散列槽的一部分。
Hash標(biāo)記記錄在Redis集群規(guī)范文檔中，但要點是如果在關(guān)鍵字{}括號內(nèi)有一個子字符串，那么只有該花括號“{}”內(nèi)部的內(nèi)容被散列，例如 this{foo}key 和 another{foo}key 保證在同一散列槽中，并且可以在具有多個 key 作為參數(shù)的命令中一起使用。
6.Redis集群之主從模型
為了在主服務(wù)器節(jié)點的子集失敗或不能與大多數(shù)節(jié)點通信時保持可用，Redis集群使用主從模型，其中每個散列槽從1（主服務(wù)器本身）到N個副本（N -1個附加從節(jié)點）。
在我們具有節(jié)點A，B，C的示例的群集中，如果節(jié)點B失敗，則群集無法繼續(xù)，因為我們沒有辦法再在5501-11000范圍內(nèi)提供散列槽。然而，當(dāng)創(chuàng)建集群時（或稍后），我們?yōu)槊總€主服務(wù)器節(jié)點添加一個從服務(wù)器節(jié)點，以便最終集群由作為主服務(wù)器節(jié)點的A，B，C以及作為從服務(wù)器節(jié)點的A1，B1，C1組成，如果節(jié)點B發(fā)生故障，系統(tǒng)能夠繼續(xù)運行。節(jié)點B1復(fù)制B，并且B失敗，則集群將促使節(jié)點B1作為新的主服務(wù)器節(jié)點并且將繼續(xù)正確地操作。
但請注意，如果節(jié)點B和B1在同一時間發(fā)生故障，則Redis群集無法繼續(xù)運行。
7.Redis集群一致性保證
Redis 集群無法保證很強的一致性。實際上，這意味著在某些情況下，Redis 集群可能會丟失系統(tǒng)向客戶確認(rèn)的寫入。
Redis集群可能會丟失寫入的第一個原因是因為它使用異步復(fù)制。這意味著在寫入期間會發(fā)生以下事情：
1、你的客戶端寫給主服務(wù)器節(jié)點 B
2、主服務(wù)器節(jié)點B向您的客戶端回復(fù)確認(rèn)。
3、主服務(wù)器節(jié)點B將寫入傳播到它的從服務(wù)器B1，B2和B3。
正如你可以看到主服務(wù)器節(jié)點 B 在回復(fù)客戶端之前不等待B1，B2，B3的確認(rèn)，因為這會對Redis造成嚴(yán)重的延遲損失，所以如果你的客戶端寫入了某些東西，主服務(wù)器節(jié)點 B 確認(rèn)寫入，就在將寫入發(fā)送給它的從服務(wù)器節(jié)點存儲之前系統(tǒng)崩潰了，其中一個從站（沒有收到寫入）可以提升為主站，永遠(yuǎn)丟失寫入。
這與大多數(shù)配置為每秒將數(shù)據(jù)刷新到磁盤的數(shù)據(jù)庫所發(fā)生的情況非常相似，因為過去的經(jīng)驗與傳統(tǒng)數(shù)據(jù)庫系統(tǒng)有關(guān)，不會涉及分布式系統(tǒng)，因此您已經(jīng)能夠推斷這種情況。同樣，通過強制數(shù)據(jù)庫在回復(fù)客戶端之前刷新磁盤上的數(shù)據(jù)，這樣可以提高一致性，但這通常會導(dǎo)致性能極低。這與Redis Cluster中的同步復(fù)制相當(dāng)。
基本上，性能和一致性之間需要權(quán)衡。
Redis集群在絕對需要時也支持同步寫入，通過WAIT命令實現(xiàn)，這使得丟失寫入的可能性大大降低，但請注意，即使使用同步復(fù)制，Redis集群也不可能實現(xiàn)完全的一致性：總是有可能會發(fā)生故常，在無法接受寫入的從設(shè)備被選為主設(shè)備的時候 。
還有另一個值得注意的情況，Redis集群也將丟失數(shù)據(jù)的寫入，這種情況發(fā)生在網(wǎng)絡(luò)分區(qū)的時候，客戶端與包含至少一個主服務(wù)器的少數(shù)實例隔離。
以A，B，C，A1，B1，C1三個主站和三個從站組成的6個節(jié)點集群為例。還有一個客戶，我們會調(diào)用Z1。
分區(qū)發(fā)生后，可能在分區(qū)的一側(cè)有A，C，A1，B1，C1，另一側(cè)有B和Z1。
Z1仍然能夠?qū)懭隑，它也會接受Z1的寫入。如果分區(qū)在很短的時間內(nèi)恢復(fù)，則群集將正常繼續(xù)。但是，如果分區(qū)使用比較長的時間將B1提升為多數(shù)側(cè)分區(qū)的主設(shè)備，則Z1發(fā)送給B的寫入操作將丟失。
請注意，Z1能夠發(fā)送給B的寫入量有一個大窗口（maximum window）：如果分區(qū)多數(shù)側(cè)有足夠的時間選擇一個從設(shè)備作為主設(shè)備，那么少數(shù)側(cè)的每個主節(jié)點將停止接受寫操作。
這個時間值是Redis集群非常重要的配置指令，稱為 node timeout (節(jié)點超時)。
在節(jié)點超時過后，主節(jié)點被認(rèn)為是失效的，并且可以被其副本之一替換。類似地，節(jié)點超時過后，主節(jié)點無法感知大多數(shù)其他主節(jié)點，它進(jìn)入錯誤狀態(tài)并停止接受寫入。
8.redis容錯機制
每個redis提供了節(jié)點之間相互發(fā)送ping命令，用于測試每個節(jié)點的健康狀態(tài)，集群中連接正常的節(jié)點收到其他接節(jié)點發(fā)送的ping命令時，會返回一個pong字符串
Redis投票機制：如果一個節(jié)點A給B發(fā)送ping沒有得到pong返回，那么A就會通知其他節(jié)點再次給B發(fā)送ping，如果集群中超過一半的節(jié)點給B發(fā)送ping都沒有得到返回，那么B就被坐實game over了，所以為了避免單點故障，一般都會為redis的每個節(jié)點提供了備份節(jié)點，B節(jié)點掛掉之后立馬啟動B的節(jié)點服務(wù)器。
以上是“Redis中cluster集群的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！
重慶分公司
重慶分公司
