1.單機模式
這是個demo級別的，一般就是你本地啓動了玩玩的，沒人生產用單機模式
2.普通集羣模式
在多臺機器上啓動多個rabbitmq實例，每個機器啓動一個。但是你創建的queue，只會放在一個rabbtimq實例上，但是每個實例都同步queue的元數據(存放真正實例位置)。消費的時候，實際上如果連接到了另外一個實例，那麼那個實例會從queue所在實例上拉取數據過來。
因爲這導致你要麼消費者每次隨機連接一個實例然後拉取數據，要麼固定連接那個queue所在實例消費數據，前者有數據拉取的開銷，後者導致單實例性能瓶頸。而且如果那個放queue的實例宕機了，會導致接下來其他實例就無法從那個實例拉取，如果你開啓了消息持久化，讓rabbitmq落地存儲消息的話，消息不一定會丟，得等這個實例恢復了，然後纔可以繼續從這個queue拉取數據。所以這個普通集羣比較尷尬了，這就沒有什麼所謂的高可用性可言了，這方案主要是提高吞吐量的，就是說讓集羣中多個節點來服務某個queue的讀寫操作。
3.鏡像集羣模式
此模式纔是所謂的RabbitMQ的高可用模式，跟普通集羣模式不一樣的是，創建的queue，無論元數據還是queue裏的消息都會存在於多個實例上，然後每次寫消息到queue的時候，都會自動把消息到多個實例的queue裏進行消息同步。
優點：
任何一個機器宕機了，沒事兒，別的機器都可以用。
缺點：
1.這個性能開銷也太大，消息同步所有機器，導致網絡帶寬壓力和消耗很重！
2.沒有擴展性可言，如果某個queue負載很重，你加機器，新增的機器也包含了這個queue的所有數據，並沒有辦法線性擴展queue。那麼怎麼開啓這個鏡像集羣模式呢？其實很簡單rabbitmq有很好的管理控制檯，可以在後臺新增一個策略，這個策略是鏡像集羣模式的策略，可以指定要求數據同步到所有節點，也可以要求同步到指定數量的節點，然後再次創建queue的時候，應用這個策略，就會自動將數據同步到其他的節點上去了。
