由于業務的需要用到隊列，并保證隊列的高可用性，我們選擇了RabbitMQ的鏡像集群模式。這種集群模式在隊列節點宕機或故障時也能正常使用，因為它支持復制隊列內容到集群里的每個節點。

OK，關于RabbitMQ的基本知識就不在這里普及了，直接看我們總結的需要關注的幾個可用性測試點：

1. 在集群工作中如果一個或幾個節點宕機會不會導致隊列數據的丟失？

2. DISC的節點可以在其宕機重啟后保存隊列數據嗎？

3. RAM和DISC模式的速度差有多大？有沒有必要所有節點都采用DISC模式？

4. 影響上游生產者和下游消費者的發送和接收的情況會有哪些？何時會導致連接問題？

有了以上的問題，我們就可以部署我們的測試了，首先當然是集群環境搭建，這里不會花篇幅在搭建上，網上的例子很多，比如：環境搭建?

我們測試用會有三臺機器，1臺為DISC模式（磁盤），另外兩臺為RAM模式（內存）。在完成了環境搭建后，我們的集群應該滿足下列的條件：

a. 在3臺物理機的控制臺分別輸入rabbitmqctl cluster_status后：

可以看到三個控制臺的輸出都是差不多的，而且一臺為disc模式：rabbit@7-2；另外兩臺是ram模式：rabbit@7-3和rabbit@7-15

b. 分別打開三個RabbitMQ的網頁管理端并創建和配置vHost，Queue，Policy等（具體步驟省略，可參考上面環境配置網頁），展示為：

Overview頁面（顯示的集群中各節點的狀態都是正確的）

Queue頁面（我們可以看到在Node項下有一個“+2”，表示集群還有兩個節點和本節點是鏡像同步模式）

滿足了上面的條件，我們就可以開始測試集群了。

1. 在集群工作中如果一個或幾個節點宕機會不會導致隊列數據的丟失？

我們可以先往某一個隊列里寫1000個數據：

然后查看3個RabbitMQ的網頁管理端的Queue頁面，Messages里面Ready的數據為1000個：

通過查詢3個RabbitMQ的網頁管理端的Queue頁面，可以看到3個端中Queue頁面的數據都是一樣的（如上圖），全部都是有1000個數據，單從頁面上看，幾個節點應該是完成了數據的鏡像復制，就是說現在任何一個節點或者多個節點宕機，只要還剩一個節點存活，我們的數據就還是可以被消費了，那好，我們就關掉兩臺節點：rabbit@7-3和rabbit@7-15

ps：關掉節點的語句是 rabbitmqctl stop_app

兩個節點關閉后么可以看到網頁管理端的Queue頁面的變化：

可以看到，Node里面的“+2”標志消失了，代表現在集群中只有一個節點rabbit@7-2了；從圖上也可以看到，Messages里面的消息數量還是1000沒有變，我們現在就寫個消費者獲取下，看看是不是能夠獲得這1000個消息數據。

通過試驗，我們發現發送的1000個消息都可以收到，所以，在集群工作中如果一個或幾個節點宕機是不會導致隊列數據的丟失的。

2. DISC的節點可以在其宕機重啟后保存隊列數據嗎？

我們搭建的集群的DISC節點是rabbit@7-2，那我們就針對它進行這個測試。

還是先發送1000個消息給集群：

確認將三個節點全部掛掉（沒有running nodes）：

確認后將三個節點打開并通過網頁管理端的Queue頁面查看：

可以看到，消息還是1000個，沒有丟。但是有個細節，Node下面有了些變化。有了一個紅色的“+2”出現，它的意思是現在集群中有兩個節點（rabbit@7-3和rabbit@7-15）還沒有實現鏡像同步，因為之前有1000個消息它們兩個節點不知道（因為是RAM的，重啟后就消失了）。但是我們可以從rabbit@7-3和rabbit@7-15獲得這1000個消息嗎？試試看的結果是：可以！

消息都消費完后，網頁管理端的Queue頁面變為了：

3. RAM和DISC模式的速度差有多大？有沒有必要所有節點都采用DISC模式？

為了測試這個，我們單獨選出來了兩個Node進行點對點的測試：rabbit@7-3（RAM）和rabbit@7-2（RAM），并采用1000/s的頻率發送消息，計算速度的方式為：AVERAGE（消費者接收到消息的時間 - 生產者發送消息的時間）

將生產者和消費者程序中的Node節點統一變為rabbit@7-2的IP后，先打開消費者，再打開生產者，此種情況下計算出的消息速度為：8.33ms

將生產者和消費者程序中的Node節點統一變為rabbit@7-3的IP后，先打開消費者，再打開生產者，此種情況下計算出的消息速度為：3.36ms

可以看到，RAM節點的消息速度比DISC的速度快2.5~3倍。而且隨著發送頻率的增加，這個速度差距會越來越大。所以，在實際應用中，如果對消息的速度要求很高，建議還是以RAM節點為主。

4. 影響上游生產者和下游消費者的發送和接收的情況會有哪些？何時會導致連接問題？

其實，影響生產者和消費者發送和接收消息的情況很多，根據我們之前做的測試，RabbitMQ集群中只要不是全部節點全掛掉，我們就不會停止傳輸消息。但這并不意味著你的系統就完全的高枕無憂了，因為你如何和RabbitMQ集群連接是個關鍵問題，比如如果在程序中寫死了連接的節點IP，這個節點掛掉的話那就是連不上了，集群也無能為力。

目前應該有兩個可行的方法使集群起到作用：

1. 在集群前端加一個LB，統一為一個IP和端口，負載均衡和節點輪詢全都交給它就好了，但是要注意DISC的分配問題，不使用或優先級降低。

2. 自己的程序實現節點輪詢。這個需要程序人員自己寫了，來實現上述LB的功能。