可信送达，即确保消息总是送达，即使系统中的某部分挂掉（网络问题，防火墙，硬件问题，程序出错）。
连接失败
这种情况，客户端需要重新建立一个连接，之前建立的所有通道都会自动关闭并重新打开。一般来说，会抛出异常，可以建立失败回调处理。
ack
连接失败发生时，消息可能正在传输中（正在生成消息、在操作系统的缓存中、在网络上），那么消息就会丢失，收不到ack则会通知发送方进行重发。ack又可以分为两种情况：客户端通知服务器已经收到消息了，服务器通知客户端收到消息了（这种也叫做confirm，也就是消息中间人开始负责处理这些消息了）。
当然，TCP可以保证消息的送达，但是这是网络层面的，ack保证的是消息的接受和执行，它确认的是消息是否被接受同时转交所有权，接收者接下里负责处理它。所以，接受者不应该在工作未完成之前发送ack。
心跳
tcp连接的超时时间一般较长（例如linux默认为11分钟），所以amqp协议提供了心跳，使得可以在应用层发现连接错误。
作为中间人
中间件需要考虑的问题是服务器重启、硬件错误或者自身崩溃。为了确保消息在重启后还存在，则需要把消息存储在磁盘上。包含exchange、队列、消息的持久化，
集群和高可用性
如果想保证中间件在硬件错误时仍能工作，则需要使用rabbitmq集群。在集群中，所有的东西（exchange、bind、user等 除了队列需要额外的配置）都是在各个机器间共享的，所有结点都可以获得。因为这些内容在集群中的每个结点上都有，那么可以允许结点挂掉但是不会造成信息丢失。
作为发送者
如果使用了confirm，那么发送者会重发所有没有收到服务器ack的消息。可能会有消息重复的情况，即中间件已经发了ack但是发送者没有收到（网络问题），那么接收者需要处理这种重复的情况或者它本身是等幂的。
确保消息被传送
有一些情况需要确保消息被传送到了队列中，当然大多数情况发送者只是发送，如果没有接收者在等待消息可以被安全的丢弃。而为了确定消息可以被传送到队列里，发送者可以先声明该队列再发送。如果不能简单的声明队列，可以在发送时增加mandatory标记，确保在没有传送到队列时会得到通知。
作为接收者
接收者需要考虑的就是会收到重复消息（网络错误时），最好是接收者的操作是等幂的则不需要额外的操作。RabbitMQ在没有收到接收者的ack并进行重发时，会带上redelivered标记。（但是如果遇到了发送者发了重复消息的情况则不能处理）
另外如果接收者发现他不能处理该消息，可以发送reject。
分布式
联邦和shovel都是使用amqp的，所以他们也可以启用ack，在必要时可以重传消息。
