RabbitMQ叢集

RabbitMQ最優秀的功能之一就是內建叢集，這個功能涉及的目的是允許消費者和生產者在節點崩潰的情況下繼續執行，以及通過新增更多的節點來線性擴充套件訊息通訊吞吐量。RabbitMQ內部利用Erlang提供的分散式通訊框架OTP來滿足上述需求，使客戶端在失去一個RabbitMQ節點連線的情況下，還是能夠重新連線到叢集中的其他節點繼續勝場、消費資訊。

RabbitMQ會始終記錄以下四中型別的內部元資料：

• 佇列元資料：包括佇列名稱和他們的屬性，比如是否可持久化，是否可持久化，是否自動刪除。

• 交換器元資料：交換器名稱、型別、屬性。

• 繫結元資料：內部是一張表格，記錄如何將訊息路由到佇列。

• vhost元資料：為vhost內部的佇列、交換器、繫結提供名稱空間和安全屬性。

在單一節點中，RabbitMQ會將所有這些資訊儲存在記憶體中，同時將標記為可持久化的佇列、交換器、 繫結儲存在硬碟上。存到硬碟上可以確保佇列和交換器在節點重啟後能夠重建。而在叢集模式下，同樣也提供了兩種選擇：存到硬碟上(獨立節點的預設配置)，存在記憶體中。

如果在叢集中建立佇列，叢集只會在單個節點而不是所有節點上建立完整的佇列資訊（元資料、狀態、內容）。結果是隻有佇列的所有者節點知道有關佇列的所有資訊，因此當叢集節點崩潰時，該節點的佇列和繫結就消失了，並且任何匹配該佇列的繫結的新訊息也丟失了。還好RabbitMQ 2.6.0之後提供了映象佇列以避免叢集節點故障導致的佇列內容不可用。

RabbitMQ 叢集中可以共享 user、vhost、exchange等，所有的資料和狀態都是必須在所有節點上覆制的，例外就是上面所說的訊息佇列。RabbitMQ 節點可以動態的加入到叢集中。

當在叢集中宣告佇列、交換器、繫結的時候，這些操作會直到所有叢集節點都成功提交元資料變更後才返回。叢集中有記憶體節點和磁碟節點兩種型別，記憶體節點雖然不寫入磁碟，但是它的執行比磁碟節點要好。記憶體節點可以提供出色的效能，磁碟節點能保障配置資訊在節點重啟後仍然可用，那叢集中如何平衡這兩者呢？

RabbitMQ 只要求叢集中至少有一個磁碟節點，所有其他節點可以是記憶體節點，當節點加入或離開叢集時，它們必須要將該變更通知到至少一個磁碟節點。如果只有一個磁碟節點，剛好又是該節點崩潰了，那麼叢集可以繼續路由訊息，但不能建立佇列、建立交換器、建立繫結、新增使用者、更改許可權、新增或刪除叢集節點。換句話說叢集中的唯一磁碟節點崩潰的話，叢集仍然可以執行，但直到該節點恢復，否則無法更改任何東西。

RabbitMQ 的4種叢集架構

1. 主備模式

也稱為 Warren (兔子窩) 模式。實現 rabbitMQ 的高可用叢集，一般在併發和資料量不高的情況下，這種模式非常的好用且簡單。

也就是一個主/備方案，主節點提供讀寫，備用節點不提供讀寫。如果主節點掛了，就切換到備用節點，原來的備用節點升級為主節點提供讀寫服務，當原來的主節點恢復執行後，原來的主節點就變成備用節點，和 activeMQ 利用 zookeeper 做主/備一樣，也可以一主多備。

HaProxy 配置:

listen rabbitmq_cluster

bind 0.0.0.0:567 # 配置 tcp 模式

mode tcp # 簡單的輪詢

balance roundrobin # 主節點 roundrobin 隨機

server 你的76機器 hostname 192.168.11.76:5672 check inter 5000 rise 2 fall 2

server 你的77機器 hostname 192.168.11.77:5672 backup check inter 5000 rise 2 fall 2 # 備用節點

注意了，上面的 rabbitMQ 叢集節點配置 # inter 每隔 5 秒對 mq 叢集做健康檢查， 2 次正確證明服務可用，2 次失敗證明伺服器不可用，並且配置主備機制

2. 遠端模式

遠端模式可以實現雙活的一種模式，簡稱 shovel 模式，所謂的 shovel 就是把訊息進行不同資料中心的複製工作，可以跨地域的讓兩個 MQ 叢集互聯，遠距離通訊和複製。

Shovel 就是我們可以把訊息進行資料中心的複製工作，我們可以跨地域的讓兩個 MQ 叢集互聯。

遠端模式

如圖所示，有兩個異地的 MQ 叢集（可以是更多的叢集），當用戶在地區 1 這裡下單了，系統發訊息到 1 區的 MQ 伺服器，發現 MQ 服務已超過設定的閾值，負載過高，這條訊息就會被轉到 地區 2 的 MQ 伺服器上，由 2 區的去執行後面的業務邏輯，相當於分攤我們的服務壓力。

在使用了 shovel 外掛後，模型變成了近端同步確認，遠端非同步確認的方式，大大提高了訂單確認速度，並且還能保證可靠性。

shovel 模式拓撲圖

如上圖所示，當我們的訊息到達 exchange，它會判斷當前的負載情況以及設定的閾值，如果負載不高就把訊息放到我們正常的 warehouse_goleta 佇列中，如果負載過高了，就會放到 backup_orders 佇列中。backup_orders 佇列通過 shovel 外掛與另外的 MQ 叢集進行同步資料，把訊息發到第二個 MQ 叢集上。

這是 rabbitMQ 比較早期的架構模型了，現在很少使用了。

shovel 叢集的配置，首先啟動 rabbitmq 外掛，命令如下:

rabbitmq-plugins enable amqp_client

rabbitmq-plugins enable rabbitmq_shovel

在 /etc/rabbitmq/ 目錄下建立 rabbitmq.config 檔案。注意，我們源伺服器和目的地伺服器都使用這個相同的配置檔案。

具體配置如下

3. 映象模式

非常經典的 mirror 映象模式，保證 100% 資料不丟失。在實際工作中也是用得最多的，並且實現非常的簡單，一般網際網路大廠都會構建這種映象叢集模式。

mirror 映象佇列，目的是為了保證 rabbitMQ 資料的高可靠性解決方案，主要就是實現資料的同步，一般來講是 2 - 3 個節點實現資料同步。對於 100% 資料可靠性解決方案，一般是採用 3 個節點。

叢集架構如下

mirror 映象佇列

如上圖所示，用 KeepAlived 做了 HA-Proxy 的高可用，然後有 3 個節點的 MQ 服務，訊息傳送到主節點上，主節點通過 mirror 佇列把資料同步到其他的 MQ 節點，這樣來實現其高可靠。

4. 多活模式

也是實現異地資料複製的主流模式，因為 shovel 模式配置比較複雜，所以一般來說，實現異地叢集的都是採用這種雙活 或者 多活模型來實現的。這種模式需要依賴 rabbitMQ 的 federation 外掛，可以實現持續的，可靠的 AMQP 資料通訊，多活模式在實際配置與應用非常的簡單。

rabbitMQ 部署架構採用雙中心模式(多中心)，那麼在兩套(或多套)資料中心各部署一套 rabbitMQ 叢集，各中心的rabbitMQ 服務除了需要為業務提供正常的訊息服務外，中心之間還需要實現部分佇列訊息共享。

多活叢集架構如下:

federation 外掛是一個不需要構建 cluster ，而在 brokers 之間傳輸訊息的高效能外掛，federation 外掛可以在 brokers 或者 cluster 之間傳輸訊息，連線的雙方可以使用不同的 users 和 virtual hosts，雙方也可以使用不同版本的 rabbitMQ 和 erlang。federation 外掛使用 AMQP 協議通訊，可以接受不連續的傳輸。federation 不是建立在叢集上的，而是建立在單個節點上的，如圖上黃色的 rabbit node 3 可以與綠色的 node1、node2、node3 中的任意一個利用 federation 外掛進行資料同步。

如上圖所示，federation exchanges 可以看成 downstream 從 upstream 主動拉取訊息，但是並不是拉取所有訊息，必須是在 downstream 上已經明確定義 Bingdings 關係的 exchange，也就是有實際的物理 queue 來接收訊息，才會從 upstream 拉取訊息到 downstream 。

它使用 AMQP 協議實現代理間通訊，downstream 會將繫結關係組合在一起，繫結/解綁命令將傳送到 upstream 交換機。因此，federation exchange 只接收具有訂閱的訊息。