rabbitmq在高可用HA方面的方案总结

为了提升消息传递交付的可用性，rabbitMQ有几种集群的方案，不一样的方案有不一样的优缺点
一、普通的集群
rabbitMQ中的exchange和queue都包含meta、contents、state等信息,exchange在集群中的每一个节点都保存一份数据，
可是queue不同，queue在集群中对于contents只存储一份，其余节点只存储meta信息
为何只在一个节点存储queue的contents，官方是这么说的：
a、 Storage space—If every cluster node had a full copy of every queue, adding nodes
wouldn’t give you more storage capacity. For example, if one node could store
1 GB of messages, adding two more nodes would just give you two more copies
of the same 1 GB of messages.
b、 Performance—Publishing messages would require replicating those messages to
every cluster node. For durable messages, that would require triggering disk
activity on all nodes for every message. Your network and disk load would
increase every time you added a node, keeping the performance of the cluster
the same (or possibly worse).

对于publish，客户端任意链接集群的一个节点，转发给建立queue的节点存储消息的全部信息；

对于consumer，客户端任意链接集群中的一个节点，若是数据不在该节点中，则从存储该消息data的节点拉取。

可见当存储有queue内容的节点失效后，只要等待该节点恢复后，queue中存在的消息才能够获取消费的到。

显然增长集群的节点，能够提升整个集群的吞吐量，可是在高可用方面要稍微差一些

 

二、mirror queue

mirror queue是为rabbitMQ高可用的一种方案，相对于普通的集群方案来说，queue中的消息每一个节点都会存在一份copy,

这个在单个节点失效的状况下，整个集群仍旧能够提供服务。可是因为数据须要在多个节点复制，在增长可用性的同时，系统的吞吐量会有所降低。

在实现机制上，mirror queue内部实现了一套选举算法，有一个master和多个slave,queue中的消息以master为主，

对于publish，能够选择任意一个节点进行链接，rabbitmq内部若该节点不是master，则转发给master，master向其余slave节点发送该消息，

后进行消息本地化处理，并组播复制消息到其余节点存储，

对于consumer，能够选择任意一个节点进行链接，消费的请求会转发给master,为保证消息的可靠性，consumer须要进行ack确认，

master收到ack后，才会删除消息，ack消息会同步(默认异步)到其余各个节点，进行slave节点删除消息。

若master节点失效，则mirror queue会自动选举出一个节点（slave中消息队列最长者）做为master，做为消息消费的基准参考;

在这种状况下可能存在ack消息未同步到全部节点的状况(默认异步)，

若slave节点失效，mirror queue集群中其余节点的状态无需改变。

 

 

以上两种集群的方案对于客户端来说，都须要考虑节点的失效。

客户端能够容错性的方式链接rabbitMQ集群，好比失效重连下一个节点等。

也能够在客户端和mq之间加一个LoadBalancer,如HAProxy,作负载均衡，失效转发用。

 

三、固然还有其余的方式，好比active/passive和shovel,  主备方式(active,passive)只有一个节点处于服务状态，能够结合pacemaker和ARBD，  shovel简单从一个broker的一个队列中消费消息，且转发该消息到另外一个broker的交换机。  这两种方式用的比较少，这里就不作介绍了。