前言

插播一個(gè)小插曲，本來(lái)文章已經(jīng)寫(xiě)好準(zhǔn)備發(fā)布了，手賤清理了緩存導(dǎo)致文本內(nèi)容全部丟失，以至于重新寫(xiě)稿。借此提醒廣大粉絲朋友，平時(shí)一定要養(yǎng)成備份的好習(xí)慣，謹(jǐn)防出現(xiàn)博主這種愚蠢的行為。

上篇文章講解了緩存剔除的流程，以及 RDB 文件和 AOF 文件的原理介紹，本文我們來(lái)講講數(shù)據(jù)復(fù)制和集群工作的原理。

目錄

• 主從數(shù)據(jù)同步原理分析。
• Redis 集群工作原理剖析。
• 集群槽指派機(jī)制。
• 集群服務(wù)自動(dòng)檢測(cè) & 故障轉(zhuǎn)移恢復(fù)操作。

主從數(shù)據(jù)同步原理分析

主從數(shù)據(jù)同步分為兩種同步情況，分為完整重同步和部分重同步兩種。

完整重同步流程

完整重同步是指：在從服務(wù)器第一次啟動(dòng)時(shí)，其內(nèi)部沒(méi)有任何數(shù)據(jù)的時(shí)候，通過(guò)向從服務(wù)器發(fā)送 slaveof master_ip port 命令，通知從服務(wù)器向指定的主服務(wù)器發(fā)起完整的數(shù)據(jù)備份請(qǐng)求。具體流程如下：

1. 客戶端向從服務(wù)器發(fā)送數(shù)據(jù)同步請(qǐng)求，從服務(wù)器接收到命令后，便通過(guò)指定的主服務(wù)器 ip 和 port 向主服務(wù)器發(fā)送 PSYNC 請(qǐng)求數(shù)據(jù)同步。
2. 主服務(wù)器接收到 PSYNC 后，判斷是要求進(jìn)行全量數(shù)據(jù)同步，此時(shí)主服務(wù)器生成當(dāng)前服務(wù)器對(duì)應(yīng)的 RDB 文件，然后將其返回給從服務(wù)器。
3. 在從服務(wù)器進(jìn)行數(shù)據(jù)完整重同步的過(guò)程中，主服務(wù)器接收到的寫(xiě)請(qǐng)求在自己的服務(wù)器中完成命令操作之后，同時(shí)將寫(xiě)命令也發(fā)送到從服務(wù)器中。
4. 從服務(wù)器接收到 RDB 文件后，開(kāi)始解析 RDB 文件，對(duì) RDB 文件解析完成和主服務(wù)器寫(xiě)命令的操作之后，也就意味著數(shù)據(jù)完成完整重同步流程。

以上整個(gè)流程便是數(shù)據(jù)完整重同步的具體執(zhí)行流程，額外需要注意的一點(diǎn)是，完整重同步其實(shí)就是將主服務(wù)器的整個(gè)完整數(shù)據(jù)進(jìn)行一次完整的備份。

部分重同步

部分重同步是指：從服務(wù)器在復(fù)制了一部分?jǐn)?shù)據(jù)后發(fā)生了斷線重連后繼續(xù)復(fù)制的情形。在從服務(wù)器由于網(wǎng)絡(luò)等原因?qū)е聰?shù)據(jù)同步終止，當(dāng)網(wǎng)絡(luò)恢復(fù)后，從服務(wù)器繼續(xù)向主服務(wù)器進(jìn)行數(shù)據(jù)同步操作。Redis 通過(guò)偏移量的機(jī)制來(lái)實(shí)現(xiàn)數(shù)據(jù)部分重同步操作，即主服務(wù)器和從服務(wù)器都維護(hù)著一個(gè)執(zhí)行命令的偏移量，同時(shí)在主服務(wù)器內(nèi)部維護(hù)著一個(gè)復(fù)制積壓緩沖區(qū)（復(fù)制積壓緩沖區(qū)是可以調(diào)節(jié)大小的，默認(rèn)大小 1M，通過(guò)修改 repl-backlog-size 配置進(jìn)行修改），該緩沖區(qū)中緩存著部分寫(xiě)命令和寫(xiě)命令對(duì)應(yīng)的偏移量。當(dāng)從服務(wù)器斷線重連后，從服務(wù)器在發(fā)送數(shù)據(jù)同步請(qǐng)求的時(shí)候會(huì)帶著從服務(wù)器當(dāng)前同步的偏移量，如果從服務(wù)器發(fā)送的偏移量在復(fù)制積壓緩沖區(qū)中存在，則從復(fù)制積壓緩沖區(qū)中對(duì)應(yīng)的偏移量位置繼續(xù)復(fù)制往后位置的命令，如果從服務(wù)器發(fā)送的偏移量和主服務(wù)器維護(hù)的偏移量相等，則表示主從數(shù)據(jù)是一致的。部分重同步流程如下圖所示：

部分重同步機(jī)制的優(yōu)勢(shì)：

1. 相比于全量重同步，減少了數(shù)據(jù)同步量
2. 由于部分重同步數(shù)據(jù)量小，可以更快速的達(dá)到主從數(shù)據(jù)一致的目的
3. 由于數(shù)據(jù)同步量少，從而節(jié)省了帶寬資源，同時(shí)也節(jié)省了主服務(wù)器生成 RDB 文件而產(chǎn)生的 CPU 浪費(fèi)情況

Redis 集群工作原理剖析

Redis 集群在生產(chǎn)環(huán)境中通常是由多個(gè)節(jié)點(diǎn)服務(wù)器所組成，那么多個(gè)節(jié)點(diǎn)是如何建立起連接的呢？起初 Redis 集群是由各個(gè)節(jié)點(diǎn)各自為一個(gè)集群的，通過(guò)執(zhí)行 CLUSTER MEET 目標(biāo)機(jī)IP 目標(biāo)機(jī)端口 命令，使得兩臺(tái)機(jī)器建立連接，從而構(gòu)成集群。舉個(gè)例子，假設(shè)現(xiàn)在有 3 個(gè)節(jié)點(diǎn)要組成一個(gè) Redis 集群。

1. 起初，Redis 有 3 個(gè)節(jié)點(diǎn)且各自為一個(gè)偽集群，其如下圖：

2. 通過(guò)客戶端向節(jié)點(diǎn) 2 發(fā)送 CLUSTER MEET 節(jié)點(diǎn)1IP 節(jié)點(diǎn)1端口 命令，此時(shí)節(jié)點(diǎn) 2 加入了節(jié)點(diǎn) 1 所在的集群，其如下圖：

3. 同理，通過(guò)客戶端向節(jié)點(diǎn) 3 發(fā)送 CLUSTER MEET 節(jié)點(diǎn)1IP 節(jié)點(diǎn)1端口 命令，此時(shí)節(jié)點(diǎn) 3 加入了節(jié)點(diǎn) 1 所在的集群，在節(jié)點(diǎn) 1 和節(jié)點(diǎn) 3 建連完成后，節(jié)點(diǎn) 2 也會(huì)和節(jié)點(diǎn) 3 完成相同的操作，最終形成了 3 個(gè)節(jié)點(diǎn)互聯(lián)的集群，其如下圖所示：

上述流程展示了一個(gè)集群建連的過(guò)程，那么兩個(gè)節(jié)點(diǎn)在建連的時(shí)候到底是怎么實(shí)現(xiàn)的呢？舉個(gè)例子，以節(jié)點(diǎn) 1 和節(jié)點(diǎn) 2 建連為例：

1. 首先節(jié)點(diǎn) 1 會(huì)創(chuàng)建一個(gè) Node 結(jié)構(gòu)體，用于存儲(chǔ)節(jié)點(diǎn) 2 的信息，比如節(jié)點(diǎn) 2 的名字、IP、Port 等等信息。
2. 然后節(jié)點(diǎn) 1 發(fā)送 CLUSTER MEET IP PORT 命令到節(jié)點(diǎn) 2。
3. 節(jié)點(diǎn) 2 接收到節(jié)點(diǎn) 1 的命令后，在其節(jié)點(diǎn)上創(chuàng)建一個(gè) Node 用于存儲(chǔ)節(jié)點(diǎn) 1 的信息。
4. 節(jié)點(diǎn) 2 存儲(chǔ)完成節(jié)點(diǎn) 1 的信息后，向節(jié)點(diǎn) 1 發(fā)送 PONG 命令，表示自己已經(jīng)成功接收到了節(jié)點(diǎn) 1 的信息。
5. 節(jié)點(diǎn) 1 收到節(jié)點(diǎn) 2 返回的 PONG 命令后，然后節(jié)點(diǎn) 1 再向節(jié)點(diǎn) 2 發(fā)送 PING 命令，表示節(jié)點(diǎn) 1 知道節(jié)點(diǎn) 2 成功接收到節(jié)點(diǎn) 1 發(fā)送的消息了，至此兩個(gè)節(jié)點(diǎn)完成建連。

Redis 集群槽指派流程

通過(guò)上面的流程明白了 Redis 集群是如何構(gòu)建起來(lái)的，現(xiàn)在有個(gè)問(wèn)題是假設(shè)有一條寫(xiě)命令發(fā)送到集群中，那么最終應(yīng)該由那個(gè)節(jié)點(diǎn)實(shí)際執(zhí)行呢？舉個(gè)例子，集群由三個(gè)主節(jié)點(diǎn)組成，執(zhí)行 set key1 value1 命令。Redis 集群通過(guò)槽指派機(jī)制來(lái)決定寫(xiě)命令應(yīng)該被分配到那個(gè)節(jié)點(diǎn)。整個(gè)集群對(duì)應(yīng)的槽是由 16384 大小的二進(jìn)制數(shù)組組成，集群中每個(gè)主節(jié)點(diǎn)分配一部分槽，每條寫(xiě)命令落到二級(jí)制數(shù)組中的某個(gè)位置，該位置被分配給了那個(gè)節(jié)點(diǎn)則對(duì)應(yīng)的命令就由該節(jié)點(diǎn)去執(zhí)行。槽指派對(duì)應(yīng)的二進(jìn)制數(shù)組如下圖所示：

舉個(gè)例子：假設(shè)節(jié)點(diǎn) 1 執(zhí)行 0 - 4999，節(jié)點(diǎn) 2 執(zhí)行 5000 - 9999，節(jié)點(diǎn) 3 執(zhí)行 10000 - 16383， set key1 value1 命令通過(guò) CRC16(key1) & 16383 = 8876，即認(rèn)為該命令最后落到二級(jí)制數(shù)組的 8876 位置，則該命令最終由節(jié)點(diǎn) 2 執(zhí)行。在比如在節(jié)點(diǎn) 2 執(zhí)行一條命令時(shí)，假設(shè)通過(guò) CRC 計(jì)算后得到的值為 889，則其應(yīng)該有節(jié)點(diǎn) 1 執(zhí)行，此時(shí)命令會(huì)發(fā)生一個(gè)轉(zhuǎn)向操作，將要執(zhí)行的命令轉(zhuǎn)向到節(jié)點(diǎn) 1 上去執(zhí)行，其具體工作原理如下：

集群服務(wù)自動(dòng)檢測(cè) & 故障轉(zhuǎn)移恢復(fù)操作

通過(guò)上述文章介紹，我們基本明白了 Redis 集群的基本工作原理，現(xiàn)在我們來(lái)看看集群節(jié)點(diǎn)自動(dòng)檢測(cè)，以及當(dāng)節(jié)點(diǎn)發(fā)生故障時(shí)該如何進(jìn)行故障轉(zhuǎn)移恢復(fù)。假設(shè)現(xiàn)在集群由如下圖所示，其總共由 3 個(gè)主節(jié)點(diǎn)和 6 個(gè)從節(jié)點(diǎn)構(gòu)成。

集群中每個(gè)主節(jié)點(diǎn)都會(huì)定時(shí)發(fā)送信息到其他主節(jié)點(diǎn)，如果其他主節(jié)點(diǎn)在規(guī)定時(shí)間內(nèi)響應(yīng)了發(fā)送消息的主節(jié)點(diǎn)，則發(fā)送消息的主節(jié)點(diǎn)認(rèn)為響應(yīng)了消息的這些主節(jié)點(diǎn)在正常工作，反之則認(rèn)為響應(yīng)消息的主節(jié)點(diǎn)疑似下線，則發(fā)送消息的主節(jié)點(diǎn)在其節(jié)點(diǎn)上將其標(biāo)記疑似下線；當(dāng)集群中超過(guò)半數(shù)的節(jié)點(diǎn)認(rèn)為某個(gè)主節(jié)點(diǎn)被標(biāo)記為疑似下線，則其中某個(gè)主節(jié)點(diǎn)將疑似下線節(jié)點(diǎn)標(biāo)記為下線狀態(tài)，并向集群廣播一條下線消息，當(dāng)下線節(jié)點(diǎn)對(duì)應(yīng)的從節(jié)點(diǎn)接收到該消息時(shí)，則從從節(jié)點(diǎn)中選舉出一個(gè)節(jié)點(diǎn)作為主節(jié)點(diǎn)繼續(xù)對(duì)外提供服務(wù)。

舉個(gè)例子：如下圖所示，假設(shè)節(jié)點(diǎn) 1 發(fā)送消息給節(jié)點(diǎn) 2 節(jié)點(diǎn) 3，然后節(jié)點(diǎn) 2 在規(guī)定時(shí)間內(nèi)響應(yīng)了節(jié)點(diǎn) 1 的信息，而節(jié)點(diǎn) 3 沒(méi)有響應(yīng)，此時(shí)節(jié)點(diǎn) 1 將節(jié)點(diǎn) 3 標(biāo)記為疑似下線，然后節(jié)點(diǎn) 2 給節(jié)點(diǎn) 1 和節(jié)點(diǎn) 3 發(fā)送消息，節(jié)點(diǎn) 1 在規(guī)定時(shí)間內(nèi)響應(yīng)了節(jié)點(diǎn) 2，但是節(jié)點(diǎn) 3 沒(méi)有響應(yīng)節(jié)點(diǎn) 3，此時(shí)節(jié)點(diǎn) 2 先將其標(biāo)記沒(méi)疑似下線，同時(shí)發(fā)現(xiàn)節(jié)點(diǎn) 3 被標(biāo)記的疑似下線個(gè)數(shù)超過(guò)集群總數(shù)的一半，所以節(jié)點(diǎn) 2 便將節(jié)點(diǎn) 3 標(biāo)記為已下線狀態(tài)，并將該消息廣播給集群中所有的節(jié)點(diǎn)，節(jié)點(diǎn) 3 對(duì)應(yīng)的從節(jié)點(diǎn) 5 和從節(jié)點(diǎn) 6 接收到該消息后，停止從節(jié)點(diǎn) 3 復(fù)制數(shù)據(jù)且節(jié)點(diǎn) 5 被選舉為新的主節(jié)點(diǎn)，從節(jié)點(diǎn) 6 轉(zhuǎn)而復(fù)制節(jié)點(diǎn) 5 的數(shù)據(jù)。

總結(jié)

本文首先講解了 Redis 主從復(fù)制的相關(guān)細(xì)節(jié)實(shí)現(xiàn)，然后接著講解了 Redis 集群組成及相應(yīng)的工作原理，最后講解了集群自動(dòng)檢查及故障原理的實(shí)現(xiàn)。

本來(lái)準(zhǔn)備接著來(lái)講講集群的搭建，礙于文章篇幅，準(zhǔn)備在下篇文章來(lái)專(zhuān)門(mén)講述，本文干貨滿滿，不懂的地方歡迎隨時(shí)交流溝通。下篇文章再見(jiàn)，拜拜。