通过 vhost 你保障了队列和交换器的安全。当 Rabbit 崩溃或者重启时，该如何确保关键交换器、队列不重建，消息不丢失呢？
队列与交换器的幸免
默认情况下在 Rabbit 里创建队列和交换器在服务器重启或崩溃时都会消失，原因在于每个队列和交换器的durable属性。该属性默认情况为false，它决定了 RabbitMQ 是否需要在崩溃或者重启之后重新创建队列（或者交换器）。将它设置为true，这样你就不需要在服务器断电后重新创建队列和交换器了。但仅仅这样并无法让消息幸免于重启。
持久化消息
能从 AMQP 服务器崩溃中恢复的消息，我们称之为持久化消息。在消息发布前，通过把它的“投递模式”（delivery mode）选项设置为2（AMQP 客户端可能会使用人性化的常量来代替数值）来把消息标记成持久化。到现在为止，消息还只是被表示为持久化的，但是它还必须被发布到持久化的交换器中并到达持久化的队列中才行。如果不是这样的话，则包含持久化消息的队列（或者交换器）会在 Rabbit 崩溃重启后不复存在，从而导致消息成为孤儿。因此，如果消息想要从 Rabbit 崩溃中恢复，那么消息必须：
- 把它的投递模式选项设置为
2（持久） - 发送到持久化的交换器
- 到达持久化的队列
消息持久化的过程
RabbitMQ 确保持久性消息能从服务器重启中恢复的方式是，将它们写入磁盘上的一个持久化日志文件。当发布一条持久性消息到持久交换器上时，Rabbit 会在消息提交到日志文件后才发送响应。记住，之后这条消息如果路由到了非持久队列的话，它会自动从持久性日志中移除，并且无法从服务器重启中恢复。一旦你从持久化队列中消费了一条持久性消息的话（并且确认了它）,RabbitMQ 会在持久化日志中把这条消息标记为等待垃圾收集。在你消费持久性消息前，如果 RabbitMQ 重启的话，服务器会自动重建交换器和队列（以及绑定），重播持久性日志文件中的消息到合适的队列或者交换器上（取决于Rabbit服务器宕机的时候，消息处在路由过程的哪个环节）。
消息持久化的缺点
使用持久化机制会导致消息吞吐量降低至少10倍
消息写入磁盘要比存入内存中慢不止一点点，而且会极大地减少 RabbitMQ 服务器每秒可处理的消息总数。持久性消息在 RabbitMQ 内建集群环境下工作得不好
虽然 RabbitMQ 集群允许你和集群中的任何节点的任一队列进行通信，但是事实上那些队列均匀地分布在各个节点而没有冗余（在集群中任何一个队列都没有备份的拷贝）。如果运行 seed_bin 队列的集群节点崩溃了，那么直到节点恢复前，这个队列也就从整个集群中消失了（如果队列是可持久化的）。更重要的是，当节点宕机时，其上的队列也都不可用了，而且持久化队列也无法重建。这就会导致消息丢失。后面更详细地讨论这一情况，并给出替代的集群方法来解决这个问题。
确保消息持久化
现在有一个问题就是：发布操作不返回任何信息给生产者，那你怎么知道服务器是否已经持久化了持久消息到硬盘呢？服务器可能会在把消息写入磁盘前就宕机了，消息因此而丢失，而你却不知道。
AMQP 事务
这就要提到一个和消息持久化相关的一个概念：AMQP 事务（transaction）。当继续处理其他任务前，你必须确保代理接收到了消息，并且已经将消息路由给所有匹配的订阅队列，你需要把这些行为包装到一个事务中。在 AMQP 中，在把信道设置成事务模式后，通过信道发送确认的消息，之后还有多个其他 AMQP 命令。这些命令是执行还是忽略，取决于第一条消息发送是否成功。一旦你发送完所有命令，就可以提交事务了。如果事务中的首次发布成功了，那么信道会在事务中完成其他 AMQP 命令。如果发送失败的话，其他 AMQP 命令将不会执行。事务填补了生产者发布消息以及 RabbitMQ 将它们提交到磁盘上这两者之间“最后1英里”的差距。
但是 AMQP 事务几乎吸干了 Rabbit 的性能：
- 会降低大约2～10倍的消息吞吐量
- 会使生产者应用程序产生同步
发送方确认模式
和事务相仿，你需要告诉 Rabbit 将信道设置成confirm模式，而且只能通过重新创建信道来关闭该设置。一旦信道进入confirm模式，所有在信道上发布的消息都会被指派一个唯一的 ID 号（从1开始）。一旦消息被投递给所有匹配的队列后，信道会发送一个发送方确认模式给生产者应用程序（包含消息的唯一 ID）。这使得生产者知晓消息已经安全到达目的队列了。如果消息和队列是可持久化的，那么确认消息只会在队列将消息写入磁盘后才会发出。
发送方确认模式的最大好处是它们是异步的。一旦发布了一条消息，生产者应用程序就可以在等待确认的同时继续发送下一条。当确认消息最终收到的时候，生产者应用的回调方法就会被触发来处理该确认消息。如果Rabbit发生了内部错误从而导致了消息的丢失，Rabbit 会发送一条 nack（not acknowledged，未确认）消息。就像发送方确认消息那样，只不过这次说明的是消息已经丢失了。同时，由于没有消息回滚的概念（同事务相比），因此发送方确认模式更加轻量级，同时对 Rabbit 代理服务器的性能影响几乎可以忽略不计。
