非集群下，简单的说：
- 如果是excl，则设置durability没有意义，因为不管服务器挂了还是客户端主动/被动断开了，队列都会自动删除。
- auto-delete，其实可简单的认为是同理，即使非excl，则无论是服务器挂了还是全部消费者断开了，队列都会删除。
集群下：
这还真得测试如下：
1、A服务器挂了，客户端连接从A自动切换到B之后（即使配置了多个，任何时候MQ仍然只是连接到一个），MQ服务器是否认为仍然是原来的消费者？从理论上来说，应该是要认为相同的，不然就失去了集群的意义。
2、服务不是在客户端设置多个地址，而是通过haproxy进来的（不过一般大规模来说，应该使用TCP负载均衡器，小规模可能运维考虑不用），此时又是什么样的含义。
关于可靠传输，发布、订阅端发送后没有收到ack/confirm时的业务状态一致性判断问题，通常来说靠协议自身去实现100%可靠性是很难的（总要有补偿机制兜底），主要要应用层去如何设计以最小化开发/维护/运行时成本的处理。
ACK：消费者->RabbitMQ的消息处理确认
confirm：RabbitMQ->发布者的消息收到确认(AMQP标准里面用事务，太重量级)
ACK+confirm+persistent是确保消息可信到达唯一条件，即使如此，仍然有可能存在链路上的问题。如下：
publish,未收到confirm客户端挂了,服务器已成 业务可重复执行（尤其是如果生产者是整个链路的中间环节）
publish,未收到confirm服务器挂了,服务器已成 业务可重复执行（尤其是如果生产者是整个链路的中间环节）
publish,未收到confirm客户端挂了,服务器未成 无需处理，理论上不可能发生
publish,未收到confirm服务器挂了,服务器未成 客户端处理异常
consume,未收到ack客户端挂了,客户端已成 业务可重复执行（尤其是如果消费者是整个链路的中间环节）
consume,未收到ack服务器挂了,客户端已成 业务可重复执行（尤其是如果消费者是整个链路的中间环节）
consume,未收到ack客户端挂了,客户端未成 无需处理，服务端自动重发
consume,未收到ack服务器挂了,客户端未成 无需处理，理论上不可能发生
同时要考虑集群下是否完全一致。