RabbitMQ之二----集群模式

1、默认普通模式

队列创建时，只会在宿主节点（队列所在的节点）创建队列的进程，宿主节点包含完整的队列信息，包括元数据、状态、内容等等。消息实体只存在宿主节点。群只会同步队列和交换器的元数据到集群中的其他节点，其它节点存储的是指向该队列的指针，并不同步队列本身

举个例子来说，
当消息进入A节点的Queue中后，consumer从B节点拉取时，RabbitMQ会临时在A、B间进行消息传输，把A中的消息实体取出并经过B发送给consumer。所以consumer应尽量平均连接每一个节点。否则consumer只连一方，出口也就在一方，会产生瓶颈。在负载均衡的条件下，可以增加broker可以线性提高服务的性能和吞吐量

缺点：不能保证消息不会丢失

当集群中某一节点崩溃时，崩溃节点所在的队列进程和关联的绑定都会消失，附加在那些队列上的消费者也会丢失其订阅信息，匹配该队列的新消息也会丢失。

比如A为宿主节点，当A节点故障后，B节点无法取到A节点中还未消费的消息实体。如果做了消息持久化，那么得等A节点恢复，然后才可被消费；如果没有持久化的话，然后就没有然后了

2、Warren集群模式

主备集群模式：一个主 RabbitMQ Server 节点，两个或两个以上的从 RabbitMQ Server 节点，主节点如果挂了，从节点提供服务，和activemq利用zookeeper做主/备一样

指定一个主 RabbitMQ Server 节点，然后指定两个或两个以上的从 RabbitMQ Server 节点，并且在主节点和从节点之间，通过一定的技术手段来实现主从节点间的通信

HAProxy是一个使用C语言编写的自由及开放源代码软件，其提供高可用性、负载均衡，以及基TCP和HTTP的应用程序代理

3、Shovel集群模式

远程模式：远距离通信和复制，我们可以把消息复制到不同数据中心，跨地域的让两个MQ集群互联。 分摊服务器压力，并且在使用了shovel插件后，模型变成了近端同步确认，远端异步确认方式，大大提高了消息确认速度，并且还能保证可靠性

如上图，假设位于北京节点的 RabbitMQ Server 服务器为远程主节点，如果压力正常，则消息会被推送到 RabbitMQ 北京节点；如果 RabbitMQ北京节点的服务器压力过大，或该节点中的 RabbitMQ 消息队列已满，则消息会被推送到与之相连的其他节点，以此类推。

缺点：

1. 远程模式虽然提供了对不同节点的 RabbitMQ Server 压力检测的功能，但是其配置起来过于繁琐，实际使用的也不多；
2. Shovel 模式如果节点之间的距离太远，则会造成节点间通信的延迟

4、Federation模式

多活模式：这种模式也是实现异地数据复制的主流模式，相对于Shovel模式配置比较复杂，所以一般来说实现异地集群都是使用这种双活或者多活模式来去实现的。这种模型需要依赖Rabbitmq的federation插件，实现不同地域节点间的通信，多活模式在实际配置与应用非常简单。

当我们的应用程序，或者生产者需要使用我们的 RabbitMQ Server 时，就会向我们的 RabbitMQ Server发送请求，由图可知，该请求会被我们所配置的负载均衡策略所截获，同时，负载均衡策略会根据请求的内容，来将请求分发到相应的地域节点中的RabbitMQ Server 中。

Federation 多活集群模式与 Shovel 远程调用集群模式最大的不同之处在于，Shovel 远程调用集群模式需要指定主区域，即可以理解为主节点，但是 Federation 多活集群模式不需要指定，它的每一个节点都相当于是主节点，每一个节点都是活跃的， 请求只会根据不同的负载均衡策略来分发到不同的地域节点上而已。
Federation 多活集群模式支持我们配置较远距离的 RabbitMQ Server 节点

5、Mirror模式

镜像集群模式：主要就是通过镜像的概念来实现集群的搭建，引入 Mirror 镜像队列机制，能使得在 RabbitMQ 集群环境下，数据可以达到 100% 的投递可靠性，是搭建 RabbitMQ 集群的首选方案

将队列镜像的复制到其它的broker上，当集群中一个节点失效后便会将队列切换到另一个节点上去，从而保障服务的可用性。

keepAlived 通过VRRP（Virtual Router RedundancyProtocol虚拟路由器冗余协议）协议实现高可用（主备切换）功能，目的是为了解决静态路由单点故障问题。
keepalived服务正常工作时，主master节点会向备节点发送（多播方式）心跳消息，当主master节点故障不再发送心跳时，备节点会调用自身的接管程序，接管主master节点的ip资源及服务，当主节点恢复时，备节点释放接管的资源与服务，恢复到备用角色

镜像队列

Mirror 镜像队列和其他普通的消息队列一样，镜像队列中存储消息的方式也和普通队列相同，都需要生产者将消息推送到队列中，供消费者获取并消费消息。在此基础上增加了将消息和ack复制到所有镜像的功能

一个镜像队列中包含有1个主节点master和若干个从节点slave。其主从节点包含如下几个特点：

• 消息的读写都是在master上进行，并不是读写分离

• master接收命令后会向salve进行组播，salve会命令执行顺序执行

• master失效，根据节点加入的时间，最老的slave会被提升为master

• 互为镜像的是队列，并非节点，集群中的不同节点可以互为镜像队列，也就是说队列的master可以分布在不同的节点上

消息的发布（除了Basic.Publish(共享队列)之外）、消费都是通过master节点完成，同时将消息的处理动作通过GM(Guarenteed Multicast)广播给所有的slave节点，slave节点的GM收到消息后，通过回调交由mirror_queue_slave进行消息的存储，而master上的回调处理是由coordinator负责完成

quorum queues

RabbitMQ 3.8.0中提出的一种新的队列，以raft分布式算法实现的FIFO的队列，是以数据安全为最高优先级的，是mirror queues的替代方案。

未完待续