為了提高訊息傳遞交付的可用性，rabbitMQ有幾種叢集的方案，不同的方案有不同的優缺點
1、普通的叢集
rabbitMQ中的exchange和queue都包含meta、contents、state等資訊,exchange在叢集中的每個節點都儲存一份資料，
但是queue不一樣，queue在叢集中對於contents只儲存一份，其他節點只儲存meta資訊
為什麼只在一個節點儲存queue的contents，官方是這麼說的：
a、 Storage space—If every cluster node had a full copy of every queue, adding nodes
wouldn’t give you more storage capacity. For example, if one node could store
1 GB of messages, adding two more nodes would just give you two more copies
of the same 1 GB of messages.
b、 Performance—Publishing messages would require replicating those messages to
every cluster node. For durable messages, that would require triggering disk
activity on all nodes for every message. Your network and disk load would
increase every time you added a node, keeping the performance of the cluster
the same (or possibly worse).

對於publish，客戶端任意連線叢集的一個節點，轉發給建立queue的節點儲存訊息的所有資訊； 對於consumer，客戶端任意連線叢集中的一個節點，如果資料不在該節點中，則從儲存該訊息data的節點拉取。 可見當儲存有queue內容的節點失效後，只要等待該節點恢復後，queue中存在的訊息才可以獲取消費的到。 顯然增加叢集的節點，可以提高整個叢集的吞吐量，但是在高可用方面要稍微差一些 2、mirror queue mirror queue是為rabbitMQ高可用的一種方案，相對於普通的叢集方案來講，queue中的訊息每個節點都會存在一份copy, 這個在單個節點失效的情況下，整個叢集仍舊可以提供服務。但是由於資料需要在多個節點複製，在增加可用性的同時，系統的吞吐量會有所下降。 在實現機制上，mirror queue內部實現了一套選舉演算法，有一個master和多個slave,queue中的訊息以master為主， 對於publish，可以選擇任意一個節點進行連線，rabbitmq內部若該節點不是master，則轉發給master，master向其他slave節點發送該訊息， 後進行訊息本地化處理，並組播複製訊息到其他節點儲存， 對於consumer，可以選擇任意一個節點進行連線，消費的請求會轉發給master,為保證訊息的可靠性，consumer需要進行ack確認， master收到ack後，才會刪除訊息，ack訊息會同步(預設非同步)到其他各個節點，進行slave節點刪除訊息。 若master節點失效，則mirror queue會自動選舉出一個節點（slave中訊息佇列最長者）作為master，作為訊息消費的基準參考; 在這種情況下可能存在ack訊息未同步到所有節點的情況(預設非同步)， 若slave節點失效，mirror queue叢集中其他節點的狀態無需改變。

以上兩種叢集的方案對於客戶端來講，都需要考慮節點的失效。 客戶端可以容錯性的方式連線rabbitMQ叢集，比如失效重連下一個節點等。 也可以在客戶端和mq之間加一個LoadBalancer,如HAProxy,做負載均衡，失效轉發用。 3、當然還有其他的方式，比如active/passive和shovel,
  主備方式(active,passive)只有一個節點處於服務狀態，可以結合pacemaker和ARBD，
  shovel簡單從一個broker的一個佇列中消費訊息，且轉發該訊息到另一個broker的交換機。
  這兩種方式用的比較少，這裡就不做介紹了。