Highly Available (Mirrored) Queues
預設情況下，RabbitMQ叢集中的佇列都是位於單個結點上的。這一點和exchanges、bindings是不同的，因為這些是位於所有結點之上的。可以在多個結點之間將佇列映象化。每一個被映象化的佇列由一個master和一個或多個映象組成，當master掛掉以後，最老的映象將會成為新的master。
釋出到佇列上的訊息會被複制到所有映象上。消費者都連線到master上。在master上被確認的訊息會從映象中刪除。佇列映象提供了可用性。
all participating nodes each do all the work（每個結點都要做所有的工作，也就是說，每個操作所有結點都要做一遍）
這種解決方案需要一個RabbitMQ叢集。不推薦在WAN（廣域網）上建立叢集。
在分散式系統中有很多名詞用來標識第一和第二副本。通常，典型的做法是用“master”表示佇列的主副本，用“mirror”表示第二副本。然而，你會發現也有用“slave”來表示第二副本的。這是因為RabbitMQ CLI工具的歷史原因造成的。
How Mirroring is Configured
映象引數用策略來配置。一個策略通過正規表示式按名稱匹配一個或多個佇列。
Queue Arguments that Control Mirroring
策略可以在任何時候改變。建立一個非映象的佇列，然後在隨後的某個時間點將它映象化，這是有效的（反之亦然）。
一個非映象佇列和一個映象佇列是不同的，前者沒有額外的映象基礎設施，並且可能提供更高的輸出。
為了讓佇列變成映象，你需要建立一個策略來匹配它們，並且設定策略key值ha-mode和（可選的）ha-params
To How Many Nodes to Mirror?
映象到所有佇列是最保守的情況，大多數情況下你不必這麼做。對於超過3結點的叢集來說推薦映象到結點的法定人數。比如：在3個結點的叢集中選2個結點，在5個結點的叢集中選3個結點。
Queue Master Location
所有佇列的操作都會首先經過master，然後再複製到mirrors。保證訊息的先進先出非常有必要。
Mirrored Queue Implementation and Semantics
每個映象佇列都有一個master和一個或多個mirrors，它們都分佈在不同的節點上。mirrors應用發生在master上的操作，並且以和master上相同的順序應用這些操作，因此維護它們之間有相同的狀態。除了釋出以為的其它操作都到master，master廣播這個操作的影響給mirrors。因此，客戶端從一個映象佇列那裡消費實際上是從master那裡消費。
如果master失敗的話，執行得最久的那個mirror會成為master，因為執行得最久的那個最有可能和master是完全同步的。如果沒有mirror和master是同步的，那麼那些只存在於master的訊息將會丟失。
關於映象佇列，我的理解是這樣的：
1、首先，映象佇列是建立在叢集基礎之上的。它產生的背景是，佇列位於單個結點上的，萬一某個結點不可用，則整個叢集變得不可用。映象佇列的出現就是要保證即使某個結點失敗了，不影響，依然可以提供服務。
2、通過策略決定叢集中的哪些結點被映象化，也就是說，並不是叢集中的所有結點都會被做成映象
3、客戶端向被映象化的佇列中釋出訊息以後，訊息會被複制到其它映象上
4、每個映象佇列由一個master和多個slave組成。slave失敗了不要緊。master失敗了會自動有slave成為新的master。
5、一般選取叢集中結點個數的法定人數個結點做一個映象佇列
6、我覺得，映象佇列是凌駕於被做成映象的那些佇列之上的
參考 http://www.rabbitmq.com/ha.html