轉至：http://blog.csdn.net/yangbutao/article/details/10982391
下面介紹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,做負載均衡，失效轉發用。
