RabbitMQ集群架构模式
主备模式
主备与主从
- 主备和主从的概念是有区别的，主备是主节点可以提供读写的，从节点是不提供任何读写的，只是一个备用的服务。
- 主要的目的就是在主节点产生故障或者宕机的时候它能够实现一个自动切换，由原来的主节点切换到我们的备用节点，由备用节点继续提供读写服务，这时候备用节点就是充当主节点的角色了。而原来的节点恢复后又会加入到集群中，变成了备用节点。
- 主从是主服节点可以提供读写，但从节点是只读的。主从更多的是实现读写分离和数据备份的效果。
主备模式
- 主备模式，也称之为Warren模式，即主节点如果挂了，切换到从节点继续提供服务，和activemq利用zookeeper做主/备是一样的效果。
- 主备未必是两个节点，可以一主多备。
- 主备模式：实现RabbitMQ的高可用集群，一般在并发和数据量不高的情况下，这种模型非常的好用且简单。
主备集群架构
如图为主备模式的简单架构模型，主要是利用HaProxy去做的主备切换，当主节点挂掉时，HaProxy会自动进行切换，把备份节点升级为主节点
HaProxy配置
HAProxy 是一款提供高可用性、负载均衡以及基于TCP(第四层)和HTTP(第七层)应用的代理软件， 简单了解一下它的相关配置
#监听集群
listen rabbitmq_cluster
bind 0.0.0.0:5672
#配置TCP模式
mode tcp
#简单的轮询
balance roundrobin
#主节点
server rxy76 192.168.143.76:5672 check inter 5000 rise 2 fall 3
#备用节点，rxy77代表主机名，backup代表备份节点
server rxy77 192.168.143.77:5672 backup check inter 5000 rise 2 fall 3
备注: rabbitmq集群节点配置
# inter每隔五秒对mq集群做健康检查，2次正确证明服务器可用，3次失败证明服务器不可用，并且配置主备机制
远程模式(Shovel)
- 远程模式：远距离通信和复制，可以实现双活的一种模式，简称Shovel模式。
- 所谓Shovel就是我们可以把消息进行不同数据中心的复制工作，我们可以跨地域的让俩个mq集群互联。
架构模型
Shovel架构模型：绿色部分就代表了两个不同地域的MQ节点，假设用户在A地方下一个订单，然后订单投递到了MQ，第一个地方的MQ节点为了避免压力过大、负载过高可以设置一个阈值，如果负载过高将订单信息转到另一个地方的MQ，分摊服务压力。同时也可以进行两个或多个中心的数据同步。
好处：在使用了shovel插件后，模型变成了近端同步确认，远端异步确认的方式，大大提高了订单确认速度，并且还能保证可靠性
怎么去做的？
Shovel集群的拓扑图如下所示 ，一个订单进来之后，里面有两个队列，如果正常队列压力过大，会将订单路由到backup队列，这个队列和另一个地域的MQ(某个交换机)产生了Shovel联系，就会把数据复制到远端MQ中心，在远端会有相应的队列进行消费
远程模式的使用
- Shovel集群的配置，首先启动rabbitmq插件，命令如下：
rabbitmq-plugins enable amqp_client
rabbitmq-plugins enable rabbitmq_shovel - 创建rabbitmq.config文件：
touch /etc/rabbitmq/rabbitmq.config - 在config文件中添加相关的配置
- 最后我们需要源服务器和目的地服务器都使用相同的配置文件(rabbitmq.config)
事实上这个配置会相对复杂一些，实现双活已经有更好的方式，所以远程模式了解即可。
镜像模式
- 镜像模式：集群模式非常经典的就是Mirror镜像模式，保证100%数据不丢失，在实际工作中也是用的最多的。
- 并且实现集群非常的简单，一般互联网大厂都会构建这种镜像集群模式。
- Mirror镜像队列，目的是为了保证rabbitmq数据的高可靠性解决方案，主要就是实现数据的同步，一般来讲是2-3个节点实现数据同步(对于100%数据可靠性解决方案一般是3节点)
集群架构
黄色的就是应用服务器，里面包含了RabbitMQ节点，节点里面有个Mirror queue，这三个镜像队列数据是要同步的。
外部发送一条消息，落到一台服务器上，这台服务器将数据进行同步，同步到另外两个节点上。
利用HA-proxy做负载均衡，然后KeepAlived做多个HA-proxy的高可用切换
多活模式(Federation)
- 多活模式：这种模式也是实现异地数据复制的主流模式，因为Shovel模式配置比较复杂，所以一般来说实现异地集群都是使用这种双活或者多活模型来实现的。
- 这种模型需要依赖rabbitmq的
federation插件，可以实现持续的可靠的AMQP数据通信，多活模式在实际配置与应用上非常的简单。 - 提供了更可靠的完备的数据保障，即使一个集群挂掉，也还有另外一个集群。
- RabbitMQ部署架构采用双中心模式(多中心) , 那么在两套(或多套)数据中心中各部署一套RabbitMQ集群，各中心的RabbitMQ服务除了需要为业务提供正常的消息服务外，中心之间还需要实现部分队列消息共享。
多活集群架构
上层就是应用层，然后经过LBS负载均衡，两套RabbitMQ集群，可能是两套镜像队列，两套集群通过federation插件进行数据的复制和流转。
当然federation插件不是建立在集群上的，而是建立到单个节点上，比如左边node3可以和右边任意一台建立这种多活机制，然后，自己这边的集群如果是采用镜像队列那么也会去进行同步，所以这种性能也是非常好的。
Federation插件说明
- Federation插件是一个不需要构建Cluster，而在Brokers之间传输消息的高性能插件，Federation 插件可以在Brokers或者Cluster之间传输消息，连接的双方可以使用不同的users和virtual hosts，双方也可以使用版本不同的RabbitMQ和Erlang
- Federation 插件使用AMQP协议通讯，可以接受不连续的传输
- Federation Exchanges，可以看成Downstream从Upstream主动拉取消息，但并不是拉取所有消息，必须是在Downstream上已经明确定义Bindings关系的Exchange，也就是有实际的物理Queue来接收消息，才会从Upstream拉取消息到Downstream。使用AMQP协议实施代理间通信，Downstream会将绑定关系组合在一起，绑定/解除绑定命令将发送到Upstream交换机。因此，FederationExchange只接收具有订阅的消息。
流转过程
- 如图所示上游服务和下游服务，建立一个Link连接，可以认为就是federation，X代表Exchange
- 上游过来的数据，可以通过Exchange，直接转到下游，下游Exchange去接收数据，然后路由到具体的队列进行消费。
- 上游过来的数据不是说所有的数据都会流转到下游的，而是说建立连接关系，下游需要有具体的队列进行存储。
- 上游也可以自己去监听，同一个数据可以发到两个集群中，都可以用队列去接收存储然后消费。
