前言

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

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

目錄

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

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

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

完整重同步流程

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

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

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

部分重同步

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

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

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

Redis 集群工作原理剖析

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

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

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

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

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

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

Redis 集群槽指派流程

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

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

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

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

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

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

總結(jié)

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

本來準備接著來講講集群的搭建，礙于文章篇幅，準備在下篇文章來專門講述，本文干貨滿滿，不懂的地方歡迎隨時交流溝通。下篇文章再見，拜拜。