rabbitMq 集羣知識

參考資料： www.cnblogs.com/xishuai/p/r… www.ywnds.com/?p=4741 blog.csdn.net/zhu_tianwei… 對異常狀況解釋的比較多

爲何須要集羣

1. 擺脫單機資源上的限制，提供更大的吞吐量
2. 提供更加穩定的更高可用的服務

集羣中節點之間須要同步的信息rabbitmq的元數據

a. 隊列元數據：隊列名稱和它的屬性； b. 交換器元數據：交換器名稱、類型和屬性； c. 綁定元數據：一張簡單的表格展現瞭如何將消息路由到隊列； d. vhost元數據：爲vhost內的隊列、交換器和綁定提供命名空間和安全屬性； e. 元數據信息須要保存的磁盤中，因此每一個集羣中至少須要一個disk節點

所以，當用戶訪問其中任何一個RabbitMQ節點時，經過rabbitmqctl查詢到的queue／user／exchange/vhost等信息都是相同的。

rabbitmq 的集羣模式

集羣內節點的類型

磁盤節點

保存數據到磁盤和內存中，若是集羣中羣都是內存節點，那就不能中止他們，不然元數據就會丟。

RabbitMQ只要求集羣中至少有一個磁盤節點，若是隻有一個磁盤節點，恰好又崩潰了，集羣能夠繼續路由消息，但不能建立隊列、交換器、綁定、添加用戶、更改權限等操做。因此，建議設置兩個磁盤節點，當內存節點重啓後，會鏈接到預先配置的磁盤節點，下載當前集羣元數據拷貝，因此要將全部磁盤節點告訴內存節點。

內存節點

數據只保存到內存中，除非遇到

1. publish消息的時候指定須要持久化
2. 內存吃緊的時候，會把部分消息持久化到磁盤

內存節點的特色就是執行效率高

普通模式

不是每一個節點都有全部隊列的徹底拷貝，若是在集羣中建立隊列，只會在單個節點上建立完整的隊列信息（元數據、狀態、內容），全部其餘節點只知道隊列的元數據和指向該隊列的節點指針。

既然一個隊列的數據只存在一個節點上，那麼在鏈接集羣內其餘節點的時候，是如何進行發佈消息和消費消息的呢？ 若是消息生產者所鏈接的是節點2或者節點3，此時隊列1的完整數據不在該兩個節點上，那麼在發送消息過程當中這兩個節點主要起了一個路由轉發做用，根據這兩個節點上的元數據（也就是上文提到的：指向queue的owner node的指針）轉發至節點1上，最終發送的消息仍是會存儲至節點1的隊列1上。 一樣，若是消息消費者所鏈接的節點2或者節點3，那這兩個節點也會做爲路由節點起到轉發做用，將會從節點1的隊列1中拉取消息進行消費。

若是節點崩潰了，附加在隊列上的消費者也就沒法接收新的消息了。可讓消費者重連到集羣並從新建立隊列，這種作法僅當隊列沒設置持久化時纔可行，若是作了隊列持久化或消息持久化,必須等到對應的節點恢復了才能被消費，這是爲了確保當失敗的節點恢復後加入集羣，節點上的隊列消息不會丟失。

爲何不將隊列內容和狀態複製到全部節點：

1. 存儲空間，若是每一個集羣節點都擁有全部隊列的徹底拷貝，添加新節點不會帶來更多存儲空間；
2. 性能，消息的發佈者須要將消息複製到每個集羣節點，對於持久化消息，網絡和磁盤複製都會增長。

優勢：

1. 使用集羣能很好的實現服務能力的水平拓展

缺點：

1. 由於單個隊列只維持在單個節點上，也很難認爲是高可用
2. 若是是不持久化的消息和隊列，單機宕機後消息會丟失

鏡像模式 把須要的隊列作成鏡像隊列，存在於多個節點，屬於RabbitMQ的HA方案

根據策略能夠爲節點定義鏡像節點，鏡像節點之間能夠實現隊列中消息實體的同步。 對於發送方確認消息，Rabbit會在全部隊列和隊列的從拷貝安全地接收到消息時，纔會通知發送方。

優勢：

1. 由於能對節點維護的隊列中的消息實體作了同步，能夠保證

缺點：

1. 由於要進行消息實體的複製，因此勢必會影響系統的性能
2. 網絡通訊也會加大，若是消息量比較大話