當單臺RabbitMQ的性能不能滿足我們的要求時，我們需要對其進行分佈式部署，官方提供了三種方式來實現RabbitMQ的分佈式部署，他們之間可以多種組合共同部署，我們分別介紹下
Clustering
這種方式屬於原生的“集羣”，該種方式在邏輯上將多臺機器聯合到一起，對外只相當於一個broker，集羣中的所有機器必須運行RabbitMQ和Erlang的相同版本。除了queue以外所有的數據將在集羣中複製，queue默認只駐留在一個節點上，但是連接到集羣中任何節點的client都可以看到集羣中的所有隊列，即使它們不在該節點上。要使隊列實現高可用，可以使用鏡像隊列。
不像其他軟件的集羣方案，RabbitMQ集羣中節點之間沒有主從節點之分。
Federation
這種方式利用插件的機制實現集羣，它的目標是不通過集羣在broker之間傳遞消息，倆個broker可以有不同的 virtual hosts和用戶，也可以運行在不同版本的RabbitMQ和Erlang上，broker之間通過AMQP協議進行通訊。Federation使exchange和queue聯合起來，Federation exchange和 Federation queue可以從其他broker上的exchanges和queues接收消息。Federation exchange可以將消息路由到本地的queue，Federation queue允許本地消費者從其他broker獲取消息。
Shovel
它也是利用插件的機制實現集羣，它將消息可靠的從broker中的queue移動到broker中的exchange，源和目的的broker可以相同或者不同，與Federation類似，使用WAN連接，broker可以運行在不同的Erlang與RabbitMQ版本上，連功能都大致相同，只不過Shovel相比於Federation粒度更細。
三者對比
由於Federation和Shovel類似，這裏把他倆歸爲一類。
Federation/Shovel：每個broker在邏輯上是獨立的；每個節點可以運行在不同的Erlang和RabbitMQ版本；broker之間通過廣域網進行連接，消息傳遞使用AMQP協議；broker之間可以以各種拓撲形式連接，連接可以是雙向或者單向；在CAP理論中更側重於A（可用性）P（分區容錯性）；連接到集羣中的一個節點只能看見該節點上的queue。
Clustering：邏輯上是相當於一個broker；每個節點Erlang和RabbitMQ版本必須相同；broker之間通過LAN連接，broker之間的消息傳遞使用Erlang；在CAP理論中側重於C（一致性）P（分區容錯性）；連接到其中一個節點即可看到所有節點上的queue。
最後
最後關於在選擇Federation和Shovel之間做出選擇，推薦大家看一下stackoverflow上的這篇回答。https://stackoverflow.com/questions/19357272/when-to-use-rabbitmq-shovels-and-when-federation-plugin