RabbitMQ集群和消息传递确认机制

集群方案

1. 单一模式：

最简单的情况，非集群模式。

2. 默认的集群模式。

对于Queue来说，消息实体只存在于其中一个节点，A、B两个节点仅有相同的元数据即队列结构。

当消息进入A节点的Queue中后，consumer从B节点拉取时，RabbitMQ会临时在A、B间进行消息传输，把A中的消息实体取出并经过B发送给consumer。

该模式存在一个问题就是当A节点故障后，B节点无法取到A节点中还未消费的消息实体。

如果做了消息持久化，那么得等A节点恢复，然后才可被消费；如果没有持久化的话，然后就没有然后了……

3. 镜像模式：把需要的队列做成镜像队列，均在与多个节点，属于RabbitMQ的HA方案。

该模式解决了上述问题，其实质和普通模式不同之处在于，消息实体会主动在镜像节点间同步，而不是在consumer取数据时临时拉取。

该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉。

Confirm机制

文档和例子见：http://www.rabbitmq.com/blog/2011/02/10/introducing-publisher-confirms/

Transaction事务

参考文档：https://kishanthan.wordpress.com/2013/05/05/transaction-support-with-rabbitmq/

代码例子：https://gist.github.com/scvalex/613157

参考文档

AMQP v1.0.pdf

confirm过程讲的不错：

http://blog.csdn.net/anzhsoft/article/details/21603479?utm_source=tuicool&utm_medium=referral

官方文档： https://www.rabbitmq.com/confirms.html

mq协议讲解： https://www.rabbitmq.com/amqp-0-9-1-quickref.html

https://kishanthan.wordpress.com/2013/05/05/transaction-support-with-rabbitmq/