集群方案
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/