Table of Contents

  1. 概述
  2. AMQP事务(transaction)
  3. 发送方确认模式

概述

重启RabbitMQ后,队列和交换器都会消失(随同里面的消息),原因在于每个队列和交换器的durable属性,该属性默认为false

durable属性,它决定了RabbitMQ是否需要在崩溃或者重启之后重新创建队列(或者交换器)
将他设置为true,这样就不需要在服务器断电后重新创建队列和交换器了

把这个属性设置为true不足以让消息幸免于重启,光这样还不够

如果想要从Rabbit崩溃中恢复,那么消息必须做到这三点:

  • 把它的投递模式选项设置为2(持久)
  • 发送到持久化的交换器
  • 到达持久化队列

RabbitMQ确保持久性消息能从服务器重启中恢复的方式是,将他们写入磁盘上的一个持久化日志文件。当发布一条持久化消息到持久交换器上时,Rabbit会在消息提交到日志文件后才发送响应

如果RabbitMQ重启,服务器会自动重建交换器和队列,重播持久性日志文件中的消息到合适的队列或者交换器上

你可以为所有消息都启动持久化,但是你也要为此付出代价:性能,写入磁盘要比写入内存慢了不止一点点,而且会极大的减少RabbitMQ服务器每秒可处理的消息总数,导致消息吞度量降低至少10倍的情况并不少见

持久化消息在RabbitMQ内建集群环境中工作的并不好,实际上集群上的队列均匀分布在各个节点上而且没有冗余,如果运行a队列的节点崩溃了,那么直到节点恢复前,这个队列就从整个集群消失了,而且这个节点上的所有队列不可用,而且持久化队列也无法重建

什么情况下应该使用持久化消息通信呢?
首先你需要分析性能需求,如果持久化通信可以满足性能需求,那么用这种机制是极佳的方式

AMQP事务(transaction)

发布操作不返回任何信息给生产者,那你怎么知道服务器是否已经持久化消息到硬盘?可能写入硬盘之前服务器就宕机了,消息丢失,你却不知道

所以你需要把这些行为包装在一个事务中

不要把AMQP事务与大多数数据库事务搞混了,在AMQP中,在把信道设置为事务模式后,你通过信道发送那些想要确认的消息,之后还有多个其他AMQP命令,这些命令时执行还是忽略,取决于第一条消息发送是否成功,一旦你发送完所有命令,就可以提交事务了

虽然事务是正式的AMQP 0-9-1规范的一部分,但是它也有致命弱点:几乎吸干了Rabbit的性能,使用事务不但会降低大约2-10倍的消息吞度量,而且会使生产者应用程序之间产生同步,而你使用消息通信就是想避免同步

发送方确认模式

RabbitMQ团队决定拿出更好的方案来保证消息投递:发送方确认模式

和事务相仿,你需要告诉Rabbit将信道设置成confirm模式

  • 一旦信道进入confirm模式,所有在信道上发布的消息都会被指派一个唯一的id号(从1开始)
  • 一旦消息被投递给所有匹配的队列后,信道会发送一个发送方确认模式给生产者应用程序(包含唯一的id),这使得生产者知晓消息已经安全到达目的队列了(如果消息和队列是可持久化的,那么确认消息只会在队列将消息写入磁盘后才会发生)
  • 发送方确认模式最大的好处是他们是异步
  • 如果Rabbit发生了内部错误从而导致了消息的丢失,Rabbit会发送一条nack消息,就像发送方确认消息那样,只不过这次说明的是消息已经丢失了
  • 由于没有消息回滚的概念,因此发送方确认模式更加轻量级,同时对Rabbit代理服务器的性能几乎没有影响

(注:内容整理自《RabbitMQ实战》)