RabbitMQ集群模式之Mirror模式與Federation模式介紹

1. 前言

Hello，大家好。本小節會為大家介紹 RabbitMQ 中的最后兩種集群模式，分別是 Mirror 模式和 Federation 模式。

本小節會對 RabbitMQ 中的 Mirror 集群模式和 Federation 集群模式的基礎概念做詳細的介紹，并且會對這兩種模式的基本使用流程做一個簡要的概述，本小節不會對這兩種集群模式進行代碼層面的實操講解，同學們注意。

本節主要內容：

• Mirror 集群模式與 Federation 集群模式概述

• Mirror 集群模式與 Federation 集群模式使用流程概述

2. Mirror 集群模式與 Federation 集群模式概述

Mirror 集群模式：

Mirror 集群模式，其中文含義為鏡像集群模式。主要就是通過鏡像的概念來實現集群的搭建。

鏡像這一概念，相信大家都不陌生，所以在本節中不做介紹，我們直接來看什么是 RabbitMQ 的鏡像集群模式。

鏡像集群模式的核心就是其中的 Mirror 鏡像隊列， Mirror 鏡像隊列和其他普通的消息隊列一樣，只不過在不同的場景中所叫的名稱不同罷了。每一個鏡像隊列中存儲消息的方式也和普通隊列相同，都需要生產者將消息推送到隊列中，從而供消費者獲取并消費消息。

正式由于 Mirror 鏡像隊列的存在，才使得在 RabbitMQ 集群環境下，數據可以達到 100% 的投遞可靠性，因此，Mirror 鏡像集群模式也成為了 RabbitMQ 眾多集群模式中的經典集群模式，在互聯網大廠，以及其他一線互聯網公司中，Mirror 鏡像集群模式一直都被推崇，成為了搭建 RabbitMQ 集群的首選方案。 Mirror 鏡像集群模式的架構如下圖所示：

從上圖中我們可以看到，我們的應用程序或者是消息的生產者，需要請求我們的 RabbitMQ Server 時，請求首先會被發送到一個虛擬主機上，這個虛擬主機是實現 Mirror 鏡像集群模式所必須的組件或者說是工具，該虛擬主機可以通過當下主流的 KeepAlived ，以及 HaProxy 組件來實現。

在通過 KeepAlived 和 HaProxy 組件配置好我們所需的虛擬主機，即 Virtual Host 之后，虛擬主機會根據我們的請求所在的 ip 地址，來將請求分發到不同的 RabbitMQ Server 中，接著，RabbitMQ Server 就會根據我們請求的具體內容，來使用其中相應的鏡像隊列，最后，消費者再從這些鏡像隊列中獲取并消費消息。

Tips:
1. 可以看到，在上述的架構圖中，我們的 RabbitMQ Server 有 3 個節點，這個節點的數量不是隨便憑空指定的，如果我們想確保消息在鏡像模式的集群中需要做到 100% 投遞，那么我們鏡像模式中的 RabbitMQ Server 節點的數量最少應該部署 3 個；
2. KeepAlived 和 HaProxy 組件我們會在后續的小節中進行詳細的介紹，本小節同學們只需要知道我們會用到這些工具組件即可。

Federation 集群模式：

Federation 模式，在 RabbitMQ 中，被稱為多活的集群模式。Federation 這一單詞本身的意思是表示一種聯盟、結盟的含義，本義其實并沒有多活的意思，多活則是根據這一集群模式的特點轉義而來的。

為什么稱 Federation 模式為多活的集群模式呢？其實，我們可以將 Federation 模式理解為是上一小節中 Shovel 遠程模式的進化版本。

通過學習上一小節內容，我們可以知道，Shovel 遠程模式其實就是將 RabbitMQ Server 根據不同的地域，部署到了不同的地域位置，從而實現對 RabbitMQ Server 的遠程調用，但是，這種遠程調用方式配置起來過于繁瑣，會花費很長的時間，這有點得不償失。

所以，RabbitMQ 官方考慮到了這一弊端，才會有今天的 Federation 多活集群模式，我們先來看一下這個 Federation 多活集群模式的架構圖：

從上圖中我們可以看到，我們根據不同的地里位置，分別聲明了三個節點區域，并且在不同的區域節點中，我們分別部署了兩臺 RabbitMQ Server 節點，在不同的地域節點之間，我們通過 Federation 插件進行連接，實現不同地域節點間的通信。

當我們的應用程序，或者生產者需要使用我們的 RabbitMQ Server 時，就會向我們的 RabbitMQ Server 發送請求，由圖可知，該請求會被我們所配置的負載均衡策略所截獲，同時，負載均衡策略會根據請求的內容，來將請求分發到相應的地域節點中的 RabbitMQ Server 中。

Federation 多活集群模式與 Shovel 遠程調用集群模式最大的不同之處在于，Shovel 遠程調用集群模式需要指定主區域，即可以理解為主節點，但是 Federation 多活集群模式不需要指定，它的每一個節點都相當于是主節點，每一個節點都是活躍的， 請求只會根據不同的負載均衡策略來分發到不同的地域節點上而已。

正式由于 Federation 多活集群模式的這一特點，才廣泛被人們稱之為是多活的集群模式。

Tips:
1. Federation 多活集群模式需要我們首先對 Federation 插件有所了解，因為在不同的地域節點之間，我們需要使用 Federation 插件進行連接和通信，這個插件我們會在后續的實操小節進行介紹；
2. Federation 多活集群模式支持我們配置較遠距離的 RabbitMQ Server 節點，這對我們的業務拓展來說提供了一定的便利性，如果我們的業務是在較遠的異地，則可以考慮使用該集群模式來搭建我們的 RabbitMQ Server 集群。

3. Mirror 集群模式與 Federation 集群模式使用流程概述

Mirror 集群模式使用流程概述

要想搭建 Mirror 集群模式，需要我們首先了解兩個工具組件，他們分別是 KeepAlived 和 HaProxy 組件，這兩個組件分別發揮著不同的作用，在搭建 Mirror 集群模式時，我們首先要將 KeepAlived 和 HaProxy 組件搭建好，形成一組虛擬的網絡，之后才可以將我們的 RabbitMQ Server 節點與之相連接，才可完成 Mirror 集群的搭建。

Federation 集群模式使用流程概述

由于 Federation 集群模式是一種多活的集群模式，所以我們也需要用到我們的 KeepAlived 和 HaProxy 組件，只不過這次所使用的組件搭建方式，與 Mirror 鏡像模式的搭建有所不同，所發揮的作用也不相同，但是都需要先將這兩個組件搭建好后，方可接入我們的 RabbitMQ Server 節點。

Tips: 本小節只是對 RabbitMQ 中的 Mirror 集群模式和 Federation 集群模式的使用流程或搭建方式做一個簡單的介紹，并不會詳細介紹集群模式搭建的流程和步驟，我們會在后續小節中專門介紹不同集群模式的詳細搭建流程和步驟，以及 KeepAlived 和 HaProxy 組件的使用方法，讓我們一起期待吧。

4. 小結

本小節介紹了 RabbitMQ 中最后兩種集群模式，即 Mirror 鏡像集群模式，以及 Federation 多活集群模式，對于這兩種集群模式的概念和地位，我們通過集群架構圖的方式進行了詳細介紹，并簡要介紹了這兩種集群模式的使用流程。