RabbitMQ 默認的集群模式,也就是普通模式,最大的問題就在於存儲隊列完整數據的節點一旦宕機,

如果是非持久化隊列,則消息丟失;如果是持久化隊列+持久化消息,則必須等該節點恢復.

所以後來 RabbitMQ 開始支持隊列(完整數據)復制.比如在有5個節點的集群裏,可以指定某個隊列的完整數據在2個節點上進行存儲,從而在性能與高可用之間取得一個平衡,這就是鏡像模式,它屬於 RabbitMQ 的HA方案.

鏡像模式解決了普通模式的問題,消息實體會主動在鏡像節點間同步,而不是在消費者獲取數據的時候臨時從其他節點拉取.當然,該模式的副作用也很明顯:

• 消息需要復制到每一個節點,對於持久化消息,網絡和磁盤同步復制的開銷都會明顯增加;
• 如果鏡像隊列數量過多,大量的消息進入,集群內部的網絡帶寬將會被這種同步通訊大大消耗掉.

所以鏡像模式適合在對可靠性要求較高的場合中使用.

綜上所述,鏡像模式的實質是鏡像隊列,一個隊列想做成鏡像隊列,需要先設置 policy,然後客戶端創建隊列的時候,RabbitMQ 集群根據“隊列名稱”自動設置是普通集群模式或鏡像模式.

下面我們通過管理後臺將前面搭建的單機集群模式修改成鏡像模式.

第一步

第二步

• Virtual host : 虛擬主機.
• Name : 策略名稱.
• Pattern : ^ 表示匹配所有隊列名稱.
• Apply to : 這裏選擇的是同時應用到交換機和隊列.
• ha-mode 和 ha-params 見下表(原貼:http://www.ywnds.com/?p=4741)

然後我們可以看到,該虛擬主機下面的交換機和隊列都被打上了 test_mirror 標簽

+1 表示同步了1個節點.

進入該隊列詳情,可以清晰的看到 : 策略名稱,隊列所屬節點以及鏡像節點等.

驗證功能

將就上一篇普通集群的代碼.

1.生產者連接到 node1 (5672) 發送消息,然後關閉 node1.

通過 node2 的管理後臺可以看到隊列依然在.

但是有個細節,Node 從 rabbit1@node1 變成了 rabbit2@node2.

進入該隊列詳情,節點歸屬已經變成了 rabbit2@node2 , 而鏡像節點是空.

2.消費者連接到 node2 接收消息

一切正常.

3.重新啟動 node1

可以看到,隊列的歸屬節點不會再還原回去了.

參考:http://www.ywnds.com/?p=4741

RabbitMQ (十五) 鏡像集群