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 只接收具有訂閱的消息。