概述

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

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

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

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

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实战》）