rabbitmq在高可用HA方面的方案總結

爲了提升消息傳遞交付的可用性，rabbitMQ有幾種集羣的方案，不一樣的方案有不一樣的優缺點
一、普通的集羣
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中存在的消息才能夠獲取消費的到。

顯然增長集羣的節點，能夠提升整個集羣的吞吐量，可是在高可用方面要稍微差一些

 

二、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,作負載均衡，失效轉發用。

 

三、固然還有其餘的方式，好比active/passive和shovel,  主備方式(active,passive)只有一個節點處於服務狀態，能夠結合pacemaker和ARBD，  shovel簡單從一個broker的一個隊列中消費消息，且轉發該消息到另外一個broker的交換機。  這兩種方式用的比較少，這裏就不作介紹了。