前言

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

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

目錄

• 主從數據同步原理分析。
• Redis 集群工作原理剖析。
• 集群槽指派機制。
• 集群服務自動檢測 & 故障轉移恢復操作。

主從數據同步原理分析

主從數據同步分為兩種同步情況，分為完整重同步和部分重同步兩種。

完整重同步流程

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

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

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

部分重同步

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

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

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

Redis 集群工作原理剖析

Redis 集群在生產環(huán)境中通常是由多個節(jié)點服務器所組成，那么多個節(jié)點是如何建立起連接的呢？起初 Redis 集群是由各個節(jié)點各自為一個集群的，通過執(zhí)行 CLUSTER MEET 目標機IP 目標機端口 命令，使得兩臺機器建立連接，從而構成集群。舉個例子，假設現在有 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é)點互聯的集群，其如下圖所示：

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

1. 首先節(jié)點 1 會創(chuàng)建一個 Node 結構體，用于存儲節(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 命令，表示自己已經成功接收到了節(jié)點 1 的信息。
5. 節(jié)點 1 收到節(jié)點 2 返回的 PONG 命令后，然后節(jié)點 1 再向節(jié)點 2 發(fā)送 PING 命令，表示節(jié)點 1 知道節(jié)點 2 成功接收到節(jié)點 1 發(fā)送的消息了，至此兩個節(jié)點完成建連。

Redis 集群槽指派流程

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

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

集群服務自動檢測 & 故障轉移恢復操作

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

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

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

總結

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

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