Redis cluster集群的介紹

1.前言

Redis集群模式主要有2種:

主從集群、分布式集群。

前者主要是為了高可用或是讀寫(xiě)分離，后者為了更好的存儲(chǔ)數(shù)據(jù)，負(fù)載均衡。

redis集群提供了以下兩個(gè)好處

1、將數(shù)據(jù)自動(dòng)切分(split)到多個(gè)節(jié)點(diǎn)

2、當(dāng)集群中的某一個(gè)節(jié)點(diǎn)故障時(shí)，redis還可以繼續(xù)處理客戶(hù)端的請(qǐng)求。

一個(gè) redis 集群包含 16384 個(gè)哈希槽（hash slot），數(shù)據(jù)庫(kù)中的每個(gè)數(shù)據(jù)都屬于這16384個(gè)哈希槽中的一個(gè)。集群使用公式 CRC16(key) % 16384 來(lái)計(jì)算鍵 key 屬于哪個(gè)槽。集群中的每一個(gè)節(jié)點(diǎn)負(fù)責(zé)處理一部分哈希槽。

集群中的主從復(fù)制

集群中的每個(gè)節(jié)點(diǎn)都有1個(gè)至N個(gè)復(fù)制品，其中一個(gè)為主節(jié)點(diǎn)，其余的為從節(jié)點(diǎn)，如果主節(jié)點(diǎn)下線(xiàn)了，集群就會(huì)把這個(gè)主節(jié)點(diǎn)的一個(gè)從節(jié)點(diǎn)設(shè)置為新的主節(jié)點(diǎn)，繼續(xù)工作。這樣集群就不會(huì)因?yàn)橐粋€(gè)主節(jié)點(diǎn)的下線(xiàn)而無(wú)法正常工作

注意：

1、如果某一個(gè)主節(jié)點(diǎn)和他所有的從節(jié)點(diǎn)都下線(xiàn)的話(huà)，redis集群就會(huì)停止工作了。redis集群不保證數(shù)據(jù)的強(qiáng)一致性，在特定的情況下，redis集群會(huì)丟失已經(jīng)被執(zhí)行過(guò)的寫(xiě)命令

2、使用異步復(fù)制（asynchronous replication）是redis 集群可能會(huì)丟失寫(xiě)命令的其中一個(gè)原因，有時(shí)候由于網(wǎng)絡(luò)原因，如果網(wǎng)絡(luò)斷開(kāi)時(shí)間太長(zhǎng)，redis集群就會(huì)啟用新的主節(jié)點(diǎn)，之前發(fā)給主節(jié)點(diǎn)的數(shù)據(jù)就會(huì)丟失。

2. 主從切換原理

Redis的主從原理與MySQL相似，都是設(shè)置兩臺(tái)機(jī)器，一主一從。也就是常說(shuō)的熱備與冷備。設(shè)置主從的同時(shí)，設(shè)置兩個(gè)哨兵進(jìn)程，用來(lái)檢測(cè)主節(jié)點(diǎn)是否宕機(jī)。若發(fā)現(xiàn)主節(jié)點(diǎn)宕機(jī)，立馬從從節(jié)點(diǎn)內(nèi)選取出合適的節(jié)點(diǎn) 作為新的主節(jié)點(diǎn)。這點(diǎn)與VIP(虛擬IP技術(shù)有點(diǎn)相似)。

3.Redis群集TCP端口

每個(gè)Redis群集的節(jié)點(diǎn)都需要打開(kāi)兩個(gè)TCP連接，由于這兩個(gè)連接就需要兩個(gè)端口，分別是用于為客戶(hù)端提供服務(wù)的常規(guī)Redis TCP命令端口（例如6379）以及通過(guò)將10000和命令端口相加（10000+6379）而獲得的端口，就是集群端口（例如16379）。

第二個(gè)大號(hào)端口用于群集總線(xiàn)，即使用二進(jìn)制協(xié)議的節(jié)點(diǎn)到節(jié)點(diǎn)通信通道。 節(jié)點(diǎn)使用群集總線(xiàn)進(jìn)行故障檢測(cè)，配置更新，故障轉(zhuǎn)移授權(quán)等。 客戶(hù)端不應(yīng)嘗試與群集總線(xiàn)端口通信，為了保證Redis命令端口的正常使用，請(qǐng)確保在防火墻中打開(kāi)這兩個(gè)端口，否則Redis群集節(jié)點(diǎn)將無(wú)法通信。

命令端口和集群總線(xiàn)端口偏移量是固定的，始終為10000。

請(qǐng)注意，為了讓Redis群集正常工作，您需要為每個(gè)節(jié)點(diǎn)：

1、用于與客戶(hù)端進(jìn)行通信的普通客戶(hù)端通信端口（通常為6379）對(duì)所有需要到達(dá)群集的客戶(hù)端以及所有其他群集節(jié)點(diǎn)（使用客戶(hù)端端口進(jìn)行密鑰遷移）都是開(kāi)放的。

2、集群總線(xiàn)端口（客戶(hù)端端口+ 10000）必須可從所有其他集群節(jié)點(diǎn)訪(fǎng)問(wèn)。

如果您不打開(kāi)這兩個(gè)TCP端口，則您的群集將無(wú)法正常工作。

集群總線(xiàn)使用不同的二進(jìn)制協(xié)議進(jìn)行節(jié)點(diǎn)到節(jié)點(diǎn)的數(shù)據(jù)交換，這更適合于使用很少的帶寬和處理時(shí)間在節(jié)點(diǎn)之間交換信息。

4.Redis集群和Docker

目前，Redis群集不支持NAT地址環(huán)境，并且在IP地址或TCP端口被重新映射的一般環(huán)境中。

Docker使用一種叫做端口映射的技術(shù)：Docker容器中運(yùn)行的程序可能會(huì)暴露在與程序認(rèn)為使用的端口不同的端口上。 這對(duì)于在同一服務(wù)器中同時(shí)使用相同端口運(yùn)行多個(gè)容器很有用。

為了使Docker與Redis Cluster兼容，您需要使用Docker的主機(jī)聯(lián)網(wǎng)模式。 請(qǐng)查看Docker文檔中的–net = host選項(xiàng)以獲取更多信息。

5.Redis集群數(shù)據(jù)分片

Redis集群沒(méi)有使用一致的散列，而是一種不同的分片形式，其中每個(gè) key 在概念上都是我們稱(chēng)之為散列槽的部分。

Redis集群中有16384個(gè)散列槽，為了計(jì)算給定 key 的散列槽，我們簡(jiǎn)單地取16384模的CRC16。

Redis集群中的每個(gè)節(jié)點(diǎn)負(fù)責(zé)哈希槽的一個(gè)子集，例如，您可能有一個(gè)具有3個(gè)節(jié)點(diǎn)的集群，其中：

• 1、節(jié)點(diǎn)A包含從0到5500的散列槽。
• 2、節(jié)點(diǎn)B包含從5501到11000的散列槽。
• 3、節(jié)點(diǎn)C包含從11001到16383的散列槽。

這允許輕松地添加和刪除集群中的節(jié)點(diǎn)。例如，如果我想添加一個(gè)新節(jié)點(diǎn)D，我需要將節(jié)點(diǎn)A，B，C中的一些散列槽移動(dòng)到D。同樣，如果我想從集群中刪除節(jié)點(diǎn)A，我可以只移動(dòng)由A使用的散列槽到B和C，當(dāng)節(jié)點(diǎn)A將為空時(shí)，我可以將它從群集中徹底刪除。

因?yàn)閷⑸⒘胁蹚囊粋€(gè)節(jié)點(diǎn)移動(dòng)到另一個(gè)節(jié)點(diǎn)不需要停機(jī)操作，添加和移除節(jié)點(diǎn)或更改節(jié)點(diǎn)占用的散列槽的百分比也不需要任何停機(jī)時(shí)間。

只要涉及單個(gè)命令執(zhí)行（或整個(gè)事務(wù)或Lua腳本執(zhí)行）的所有 key 都屬于同一散列插槽，Redis群集就支持多個(gè) key 操作。用戶(hù)可以使用稱(chēng)為散列標(biāo)簽的概念強(qiáng)制多個(gè) key 成為同一個(gè)散列槽的一部分。

Hash標(biāo)記記錄在Redis集群規(guī)范文檔中，但要點(diǎn)是如果在關(guān)鍵字{}括號(hào)內(nèi)有一個(gè)子字符串，那么只有該花括號(hào)“{}”內(nèi)部的內(nèi)容被散列，例如 this{foo}key 和 another{foo}key 保證在同一散列槽中，并且可以在具有多個(gè) key 作為參數(shù)的命令中一起使用。

6.Redis集群之主從模型

為了在主服務(wù)器節(jié)點(diǎn)的子集失敗或不能與大多數(shù)節(jié)點(diǎn)通信時(shí)保持可用，Redis集群使用主從模型，其中每個(gè)散列槽從1（主服務(wù)器本身）到N個(gè)副本（N -1個(gè)附加從節(jié)點(diǎn)）。

在我們具有節(jié)點(diǎn)A，B，C的示例的群集中，如果節(jié)點(diǎn)B失敗，則群集無(wú)法繼續(xù)，因?yàn)槲覀儧](méi)有辦法再在5501-11000范圍內(nèi)提供散列槽。然而，當(dāng)創(chuàng)建集群時(shí)（或稍后），我們?yōu)槊總€(gè)主服務(wù)器節(jié)點(diǎn)添加一個(gè)從服務(wù)器節(jié)點(diǎn)，以便最終集群由作為主服務(wù)器節(jié)點(diǎn)的A，B，C以及作為從服務(wù)器節(jié)點(diǎn)的A1，B1，C1組成，如果節(jié)點(diǎn)B發(fā)生故障，系統(tǒng)能夠繼續(xù)運(yùn)行。節(jié)點(diǎn)B1復(fù)制B，并且B失敗，則集群將促使節(jié)點(diǎn)B1作為新的主服務(wù)器節(jié)點(diǎn)并且將繼續(xù)正確地操作。

但請(qǐng)注意，如果節(jié)點(diǎn)B和B1在同一時(shí)間發(fā)生故障，則Redis群集無(wú)法繼續(xù)運(yùn)行。

7.Redis集群一致性保證

Redis 集群無(wú)法保證很強(qiáng)的一致性。實(shí)際上，這意味著在某些情況下，Redis 集群可能會(huì)丟失系統(tǒng)向客戶(hù)確認(rèn)的寫(xiě)入。

Redis集群可能會(huì)丟失寫(xiě)入的第一個(gè)原因是因?yàn)樗褂卯惒綇?fù)制。這意味著在寫(xiě)入期間會(huì)發(fā)生以下事情：

• 1、你的客戶(hù)端寫(xiě)給主服務(wù)器節(jié)點(diǎn) B
• 2、主服務(wù)器節(jié)點(diǎn)B向您的客戶(hù)端回復(fù)確認(rèn)。
• 3、主服務(wù)器節(jié)點(diǎn)B將寫(xiě)入傳播到它的從服務(wù)器B1，B2和B3。

正如你可以看到主服務(wù)器節(jié)點(diǎn) B 在回復(fù)客戶(hù)端之前不等待B1，B2，B3的確認(rèn)，因?yàn)檫@會(huì)對(duì)Redis造成嚴(yán)重的延遲損失，所以如果你的客戶(hù)端寫(xiě)入了某些東西，主服務(wù)器節(jié)點(diǎn) B 確認(rèn)寫(xiě)入，就在將寫(xiě)入發(fā)送給它的從服務(wù)器節(jié)點(diǎn)存儲(chǔ)之前系統(tǒng)崩潰了，其中一個(gè)從站（沒(méi)有收到寫(xiě)入）可以提升為主站，永遠(yuǎn)丟失寫(xiě)入。

這與大多數(shù)配置為每秒將數(shù)據(jù)刷新到磁盤(pán)的數(shù)據(jù)庫(kù)所發(fā)生的情況非常相似，因?yàn)檫^(guò)去的經(jīng)驗(yàn)與傳統(tǒng)數(shù)據(jù)庫(kù)系統(tǒng)有關(guān)，不會(huì)涉及分布式系統(tǒng)，因此您已經(jīng)能夠推斷這種情況。同樣，通過(guò)強(qiáng)制數(shù)據(jù)庫(kù)在回復(fù)客戶(hù)端之前刷新磁盤(pán)上的數(shù)據(jù)，這樣可以提高一致性，但這通常會(huì)導(dǎo)致性能極低。這與Redis Cluster中的同步復(fù)制相當(dāng)。

基本上，性能和一致性之間需要權(quán)衡。

Redis集群在絕對(duì)需要時(shí)也支持同步寫(xiě)入，通過(guò)WAIT命令實(shí)現(xiàn)，這使得丟失寫(xiě)入的可能性大大降低，但請(qǐng)注意，即使使用同步復(fù)制，Redis集群也不可能實(shí)現(xiàn)完全的一致性：總是有可能會(huì)發(fā)生故常，在無(wú)法接受寫(xiě)入的從設(shè)備被選為主設(shè)備的時(shí)候 。

還有另一個(gè)值得注意的情況，Redis集群也將丟失數(shù)據(jù)的寫(xiě)入，這種情況發(fā)生在網(wǎng)絡(luò)分區(qū)的時(shí)候，客戶(hù)端與包含至少一個(gè)主服務(wù)器的少數(shù)實(shí)例隔離。

以A，B，C，A1，B1，C1三個(gè)主站和三個(gè)從站組成的6個(gè)節(jié)點(diǎn)集群為例。還有一個(gè)客戶(hù)，我們會(huì)調(diào)用Z1。

分區(qū)發(fā)生后，可能在分區(qū)的一側(cè)有A，C，A1，B1，C1，另一側(cè)有B和Z1。

Z1仍然能夠?qū)懭隑，它也會(huì)接受Z1的寫(xiě)入。如果分區(qū)在很短的時(shí)間內(nèi)恢復(fù)，則群集將正常繼續(xù)。但是，如果分區(qū)使用比較長(zhǎng)的時(shí)間將B1提升為多數(shù)側(cè)分區(qū)的主設(shè)備，則Z1發(fā)送給B的寫(xiě)入操作將丟失。

請(qǐng)注意，Z1能夠發(fā)送給B的寫(xiě)入量有一個(gè)最大窗口（maximum window）：如果分區(qū)多數(shù)側(cè)有足夠的時(shí)間選擇一個(gè)從設(shè)備作為主設(shè)備，那么少數(shù)側(cè)的每個(gè)主節(jié)點(diǎn)將停止接受寫(xiě)操作。

這個(gè)時(shí)間值是Redis集群非常重要的配置指令，稱(chēng)為 node timeout (節(jié)點(diǎn)超時(shí))。

在節(jié)點(diǎn)超時(shí)過(guò)后，主節(jié)點(diǎn)被認(rèn)為是失效的，并且可以被其副本之一替換。類(lèi)似地，節(jié)點(diǎn)超時(shí)過(guò)后，主節(jié)點(diǎn)無(wú)法感知大多數(shù)其他主節(jié)點(diǎn)，它進(jìn)入錯(cuò)誤狀態(tài)并停止接受寫(xiě)入。

8.redis容錯(cuò)機(jī)制

每個(gè)redis提供了節(jié)點(diǎn)之間相互發(fā)送ping命令，用于測(cè)試每個(gè)節(jié)點(diǎn)的健康狀態(tài)，集群中連接正常的節(jié)點(diǎn)收到其他接節(jié)點(diǎn)發(fā)送的ping命令時(shí)，會(huì)返回一個(gè)pong字符串

Redis投票機(jī)制：如果一個(gè)節(jié)點(diǎn)A給B發(fā)送ping沒(méi)有得到pong返回，那么A就會(huì)通知其他節(jié)點(diǎn)再次給B發(fā)送ping，如果集群中超過(guò)一半的節(jié)點(diǎn)給B發(fā)送ping都沒(méi)有得到返回，那么B就被坐實(shí)game over了，所以為了避免單點(diǎn)故障，一般都會(huì)為redis的每個(gè)節(jié)點(diǎn)提供了備份節(jié)點(diǎn)，B節(jié)點(diǎn)掛掉之后立馬啟動(dòng)B的節(jié)點(diǎn)服務(wù)器。

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。如果你想了解更多相關(guān)內(nèi)容請(qǐng)查看下面相關(guān)鏈接