文章目录
RabbitMQ四种架构模式
主备模式
主备模式也被称为warren（兔子窝），一个主/备方案（主节点挂掉后，从节点提供服务，和ActiveMQ利用Zookeeper做主/备一样，只不过RabbitMQ使用的是HAproxy做的主/备）。主节点提供读写，从节点不提供读写服务，只是负责提供备份服务。
主节点宕机后，启用备份节点。当主节点恢复后，成为当前主节点的备份节点。
HAproxy配置如下：
listen rabbitmq_cluster #主/备的集群名字
bind 0.0.0.0:5672
mode tcp #配置TCP模式
balance roundrobin #简单的轮询
server bhz76 192.168.11.12:5672 check inter 5000 rise 2 fall 3 #主节点
server bhz77 192.168.11.13:5672 backup check inter 5000 rise 2 fall 3 #备用节点
rabbitmq集群节点配置 inter 每隔5秒对mq集群做健康检查，2次正确证明服务器可用，3次失败证明服务器不可用，并且配置主备机制
远程模式
实现远距离通信和复制，也就是双活的一种模式，简称Shovel模式。现在这种模式使用的不是很多了，因为它的可靠性有待提高，并且配置非常的麻烦。
所谓的Shovel就是我们可以把消息进行不同数据中心的复制工作，可以跨地域的让两个mq进行互联。怎么理解呢？上游的消息序列太大了，处理不过来了，可以堆积到下游进行处理，然后让两个集群进行互联的这样一个操作。
在使用了shovel插件后，模型变成了近端同步确认，远端异步确认方式，大大提高了订单确认速度，并且还能保证可靠性。
这样就是一个多活的方式。
镜像模式
这是业内使用的最主流的一种方式，集群模式非常经典的就是Mirror镜像模式，保证100%数据不丢失，并且实现集群非常的简单，一般互联网大厂都会构建这种镜像集群模式。
Mirror镜像队列，目的是为了保证rabbitmq数据的高可靠性解决方案，主要就是实现数据的同步，一般来讲是2-3个实现数据同步（对于100%数据可靠性解决方案一般是3个节点来做数据的备份存储），并且它的底层性能很高，使用erlang有媲美原生socket一样低的延迟，所以做数据同步的时候性能是特别好的。
其集群架构如下：
这种模式虽然能保证数据的高可用，但是缺点还是很明显的：不支持横向扩展，横向再增加一份是增加了rabbitmq集群的负担，因为4个节点4份数据要同步，那肯定吞吐量上一定是有所降低的。所以官方建议3个节点就行了。
如果要扩容，应该怎么办呢？也就是下面的多活模式解决的。
多活模式
这种模式也是实现异地数据复制的主流模式，因为Shovel模式配置比较复杂，所以一般来说实现异地集群都是使用双活或者多活模式来实现的。
这种模式需要依赖rabbitmq的federation插件，可以实现继续的可靠AMQP数据通信，多活模式在实际配置与应用非常的简单。可以简单的将federation插件的作用理解为上下游的消息的转发。
Federation插件是一个不需要构建Cluster，而在Brokers之间传输消息的高性能插件，Federation插件可以在Brokers或者Cluster之间传输消息，连接双方可以使用不同的users和vistual hosts，双方也可以使用版本不同的RabbitMQ和Erlang。Federation插件使用AMQP协议通信，可以接收不连续的传输。
Federation Exchanges,可以看成Downstream从Upstream主动拉取消息，但并不是拉取所有消息，必须是在Downstream上已经明确定义Bindings关系的Exchange，也就是有实际的物理Queue来接收消息，才会从Upstream拉取消息到Downstream。使用AMQP协议实施代理间通信，Downstream会将绑定关系组合在一起，绑定/解绑命令将会发送到Upstream交换机。因此，FederationExchange只接收具有订阅的消息。
RabbitMQ部署架构采用双中心模式（多中心），那么在两套（或多套）数据中心中各部署一套RabbitMQ集群，各中心之间还需要实现部分队列消息共享。多活集群架构如下：
