今天主要分享RabbitMQ常見的4種集群架構，有待改進，大家一起看看吧！

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

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

HaProxy配置:

注意了，上面的rabbitMQ集群節點配置#inter每隔5秒對mq集群做健康檢查，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比較早期的架構模型了，現在很少使用了。

非常經典的mirror鏡像模式，保證100%數據不丟失。在實際工作中也是用得最多的，并且實現非常的簡單，一般互聯網大廠都會構建這種鏡像集群模式。

mirror鏡像隊列，目的是為了保證rabbitMQ數據的高可靠性解決方案，主要就是實現數據的同步，一般來講是2-3個節點實現數據同步。對于100%數據可靠性解決方案，一般是采用3個節點。

集群架構如下

mirror鏡像隊列

如上圖所示，用KeepAlived做了HA-Proxy的高可用，然后有3個節點的MQ服務，消息發送到主節點上，主節點通過mirror隊列把數據同步到其他的MQ節點，這樣來實現其高可靠。

這個也是實現異地數據復制的主流模式，因為shovel模式配置比較復雜，所以一般來說，實現異地集群的都是采用這種雙活或者多活模型來實現的。這種模式需要依賴rabbitMQ的federation插件，可以實現持續的，可靠的AMQP數據通信，多活模式在實際配置與應用非常的簡單。

rabbitMQ部署架構采用雙中心模式(多中心)，那么在兩套(或多套)數據中心各部署一套rabbitMQ集群，各中心的rabbitMQ服務除了需要為業務提供正常的消息服務外，中心之間還需要實現部分隊列消息共享。

多活集群架構如下:

federation插件是一個不需要構建cluster，而在brokers之間傳輸消息的高性能插件，federation插件可以在brokers或者cluster之間傳輸消息，連接的雙方可以使用不同的users和virtualhosts，雙方也可以使用不同版本的rabbitMQ和erlang。federation插件使用AMQP協議通信，可以接受不連續的傳輸。federation不是建立在集群上的，而是建立在單個節點上的，如圖上黃色的rabbitnode3可以與綠色的node1、node2、node3中的任意一個利用federation插件進行數據同步。

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

它使用AMQP協議實現代理間通信，downstream會將綁定關系組合在一起，綁定/解綁命令將發送到upstream交換機。因此，federationexchange只接收具有訂閱的消息。

其實四種模式建議大家重點掌握第三種，鏡像模式屬于標準的集群鏡像模式。其他幾種模式都存在出現臟數據問題的可能，后面會分享更多devops和DBA方面內容，感興趣的朋友可以關注下！