Redis實現系列集群內部訊息

集群內部訊息

集群中的各個節點通過傳送和接收訊息（message）來進行通訊，我們稱傳送訊息的節點為傳送者（sender），接收訊息的節點為接收者（receiver）

節點傳送的訊息主要有以下五種：

一條訊息由訊息頭（header）和訊息正文（data）組成，接下來的內容將首先介紹訊息頭，然後再分別介紹上面提到的五種不同型別的訊息正文。

訊息頭節點傳送的所有訊息都由乙個訊息頭包裹，訊息頭除了包含訊息正文之外，還記錄了訊息傳送者自身的一些資訊，因為這些資訊也會被訊息接收者用到，所以嚴格來講，我們可以認為訊息頭本身也是訊息的一部分。

每個訊息頭都由乙個cluster.h/clustermsg結構表示：

typedef
struct
clustermsg;

clustermsg.data屬性指向聯合cluster.h/clustermsgdata，這個聯合就是訊息的正文：

union clustermsgdata  ping;
// fail訊息的正文
struct
fail;
// publish訊息的正文
struct
publish;
// 其他訊息的正文... 
};

clustermsg結構的currentepoch、sender、myslots等屬性記錄了傳送者自身的節點資訊，接收者會根據這些資訊，在自己的clusterstate.nodes字典裡找到傳送者對應的clusternode結構，並對結構進行更新。

meet、ping、pong

redis集群中的各個節點通過gossip協議來交換各自關於不同節點的狀態資訊，其中gossip協議由meet、ping、pong三種訊息實現，這三種訊息的正文都由兩個cluster.h/clustermsgdatagossip結構組成：

union clustermsgdata  ping;
// 其他訊息的正文... 
};

每次傳送meet、ping、pong訊息時，傳送者都從自己的已知節點列表中隨機選出兩個節點（可以是主節點或者從節點），並將這兩個被選中節點的資訊分別儲存到兩個clustermsgdatagossip結構裡面。

typedef
struct
clustermsgdatagossip;

當接收者收到meet、ping、pong訊息時，接收者會訪問訊息正文中的兩個clustermsgdatagossip結構，並根據自己是否認識clustermsgdatagossip結構中記錄的被選中節點來選擇進行哪種操作：

舉個傳送ping訊息和返回pong訊息的例子，假設在乙個包含a、b、c、d、e、f六個節點的集群裡：

當集群裡的主節點a將主節點b標記為已下線（fail）時，主節點a將向集群廣播一條關於主節點b的fail訊息，所有接收到這條fail訊息的節點都會將主節點b標記為已下線。

fail訊息的正文由cluster.h/clustermsgdatafail結構表示，這個結構只包含乙個nodename屬性，該屬性記錄了已下線節點的名字：

typedef
struct
clustermsgdatafail;

因為集群裡的所有節點都有乙個獨一無二的名字，所以fail訊息裡面只需要儲存下線節點的名字，接收到訊息的節點就可以根據這個名字來判斷是哪個節點下線了。

publish

當客戶端向集群中的某個節點傳送命令：

publish

那麼接收到publish命令的節點不僅會向channel頻道傳送訊息message，它還會向集群廣播一條publish訊息，所有接收到這條publish訊息的節點都會向channel頻道傳送message訊息。

publish訊息的正文由cluster.h/clustermsgdatapublish結構表示：

typedef
struct
clustermsgdatapublish;

示例：publish "news.it" "hello"

為什麼不直接向節點廣播publish命令小結

節點通過握手來將其他節點新增到自己所處的集群當中。

集群中的16384個槽可以分別指派給集群中的各個節點，每個節點都會記錄哪些槽指派給了自己，而哪些槽又被指派給了其他節點。

對redis集群的重新分片工作是由redis-trib負責執行的，重新分片的關鍵是將屬於某個槽的所有鍵值對從乙個節點轉移至另乙個節點。

集群裡的從節點用於複製主節點，並在主節點下線時，代替主節點繼續處理命令請求。

集群中的節點通過傳送和接收訊息來進行通訊，常見的訊息包括meet、ping、pong、publish、fail五種。

Redis實現系列 集群內部訊息