当单台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
网友评论