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

为了提高消息传递交付的可用性，rabbitMQ有几种集群的方案，不同的方案有不同的优缺点
1、普通的集群
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中存在的消息才可以获取消费的到。

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

 

2、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,做负载均衡，失效转发用。

 

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