RabbitMQ 学习(五) —— RabbitMQ集群

镜像模式

镜像模式：集群模式非常经典的就是Mirror镜像模式，保证100%数据不丢失，在实际工作中也是用的最多的。

Mirror镜像队列，目的是为了保证rabbitmq数据的高可靠性解决方案，主要是为了实现数据的同步。一般来讲是2-3个节点实现数据同步。（对于100%数据可靠性解决方案一般是3节点）

如上图，三个服务器中的mirror queue数据通过数据同步来保证rabbitmq的高可靠性方案。前端做一个HA-proxyy KeepAlived负载均衡设置。rabbitmq发送过来一条消息，刚开始肯定是落在主服务器上，主服务器将数据进行一个copy，将数据同步到两个两个节点上。镜像队列之所以能保证数据100%不丢失，因为主节点挂了，还有两个从节点可以提供高可靠服务。

多活模式

多活模式，也是实现异地数据复制的主流模式，因为Shovel模式配置比较复杂，比如可能由于版本的原因出现各种问题，所以一般来说实现异地集群都是使用这种双活或者多活模型来实现的。这种模型需要依赖rabbitmq的federation插件，可以实现持续的可靠的AMQP的数据通信。多活模式在实际配置与应用非常简单。

RabbitMQ部署架构采用双中心模式（多中心），那么在两套（或多套）数据中心中各部署一套RabbitMQ集群，各中心的RabbitMQ服务除了需要为业务提供正常的消息服务外，中心之间还需要实现部分队列消息共享。

上图黄色和绿色表示这里有两套集群。两套集群之间有一个Federaion插件，通过此插件让节点之间的数据互相复制流转。如黄色的rabbitnode3可以和绿色的rabbitnode1或者rabbitnode3等任意节点的数据复制。

Federation插件：是一个不需要构建Cluster，而在Brokers之间传输消息的高性能插件，Federation插件可以在Brokers或者Cluster之间传输消息，连接的双方可以使用不同的users和virtual hosts，双方也可以使用版本不同的RabbitMQ和Erlang。Federation插件使用AMQP协议通讯，可以接受不连续的传输。

Federation Exchange，可以看成Downstream从Upstream主动拉取消息，但并不是拉取所有消息，必须是在Downstream上已经明确定义Bindings关系的Exchange，也就是有实际的物理Queue来接收消息，才会从Upstream拉取消息到Downstream。使用AMQP协议实施代理间通信，Downstream会将绑定关系组合在一起，绑定/解除绑定命令将发送到Upstream交换机。因此，Federation Exchange只接收具有订阅的消息。

upstream和downstream之间通过link建立的连接，可以将link视为Federation。上游过来的数据会到upstream exchange中，upstream exchange会将消息数据直接通过federation转到downsteam。下游也有一个exchange，会将消息转到queue，然后进行数据的消费。

注意：并不是上游所有的消息都会被拉取到下游，而是下游和上游之间定义了一个连接关系，并且下游要指定一个队列来实际存储消息。此时上游才会把消息路由到下游中。

多活模式，实现异地数据复制的主流模式，同一份数据，可以发送到两个集群中（通过Federation数据同步，当然前提满足Federation拉取条件）。两者都可以用队列对数据进行接收存储，都可以对消息进行消费。