今天主要分享RabbitMQ常见的4种集群架构，有待改进，大家一起看看吧！
01主备模式也称为Warren(兔子窝)模式。实现rabbitMQ的高可用集群，一般在并发和数据量不高的情况下，这种模式非常的好用且简单。
也就是一个主/备方案，主节点提供读写，备用节点不提供读写。如果主节点挂了，就切换到备用节点，原来的备用节点升级为主节点提供读写服务，当原来的主节点恢复运行后，原来的主节点就变成备用节点，和activeMQ利用zookeeper做主/备一样，也可以一主多备。
HaProxy配置:
listenrabbitmq_clusterbind0.0.0.0:567#配置tcp模式modetcp#简单的轮询balanceroundrobin#主节点roundrobin随机server你的76机器hostname192.168.11.76:5672checkinter5000rise2fall2server你的77机器hostname192.168.11.77:5672backupcheckinter5000rise2fall2#备用节点注意了，上面的rabbitMQ集群节点配置#inter每隔5秒对mq集群做健康检查，2次正确证明服务可用，2次失败证明服务器不可用，并且配置主备机制
02***模式***模式可以实现双活的一种模式，简称shovel模式，所谓的shovel就是把消息进行不同数据中心的复制工作，可以跨地域的让两个MQ集群互联，远距离通信和复制。
Shovel就是我们可以把消息进行数据中心的复制工作，可以跨地域的让两个MQ集群互联。
***模式
如图所示，有两个异地的MQ集群（可以是更多的集群），当用户在地区1这里下单了，系统发消息到1区的MQ服务器，发现MQ服务已超过设定的阈值，负载过高，这条消息就会被转到地区2的MQ服务器上，由2区的去执行后面的业务逻辑，相当于分摊我们的服务压力。
在使用了shovel插件后，模型变成了近端同步确认，远端异步确认的方式，大大提高了订单确认速度，并且还能保证可靠性。
shovel模式拓扑图
如上图所示，当我们的消息到达exchange，它会判断当前的负载情况以及设定的阈值，如果负载不高就把消息放到我们正常的warehouse_goleta队列中，如果负载过高了，就会放到backup_orders队列中。backup_orders队列通过shovel插件与另外的MQ集群进行同步数据，把消息发到第二个MQ集群上。
不过这是rabbitMQ比较早期的架构模型了，现在很少使用了。
03镜像模式非常经典的mirror镜像模式，保证100%数据不丢失。在实际工作中也是用得最多的，并且实现非常的简单，一般互联网大厂都会构建这种镜像集群模式。
mirror镜像队列，目的是为了保证rabbitMQ数据的高可靠性解决方案，主要就是实现数据的同步，一般来讲是2-3个节点实现数据同步。对于100%数据可靠性解决方案，一般是采用3个节点。
集群架构如下
mirror镜像队列
如上图所示，用KeepAlived做了HA-Proxy的高可用，然后有3个节点的MQ服务，消息发送到主节点上，主节点通过mirror队列把数据同步到其他的MQ节点，这样来实现其高可靠。
04多活模式这个也是实现异地数据复制的主流模式，因为shovel模式配置比较复杂，所以一般来说，实现异地集群的都是采用这种双活或者多活模型来实现的。这种模式需要依赖rabbitMQ的federation插件，可以实现持续的，可靠的AMQP数据通信，多活模式在实际配置与应用非常的简单。
rabbitMQ部署架构采用双中心模式(多中心)，那么在两套(或多套)数据中心各部署一套rabbitMQ集群，各中心的rabbitMQ服务除了需要为业务提供正常的消息服务外，中心之间还需要实现部分队列消息共享。
多活集群架构如下:
federation插件是一个不需要构建cluster，而在brokers之间传输消息的高性能插件，federation插件可以在brokers或者cluster之间传输消息，连接的双方可以使用不同的users和virtualhosts，双方也可以使用不同版本的rabbitMQ和erlang。federation插件使用AMQP协议通信，可以接受不连续的传输。federation不是建立在集群上的，而是建立在单个节点上的，如图上黄色的rabbitnode3可以与绿色的node1、node2、node3中的任意一个利用federation插件进行数据同步。
如上图所示，federationexchanges可以看成downstream从upstream主动拉取消息，但是并不是拉取所有消息，必须是在downstream上已经明确定义Bingdings关系的exchange，也就是有实际的物理queue来接收消息，才会从upstream拉取消息到downstream。
它使用AMQP协议实现代理间通信，downstream会将绑定关系组合在一起，绑定/解绑命令将发送到upstream交换机。因此，federationexchange只接收具有订阅的消息。
其实四种模式建议大家重点掌握第三种，镜像模式属于标准的集群镜像模式。其他几种模式都存在出现脏数据问题的可能，后面会分享更多devops和DBA方面内容，感兴趣的朋友可以关注下！
