from http://fengchj.com/?p=2367
某分布式消息推送系统，用RabbitMQ做消息分发。RabbitM采用镜像队列模式、双机HA部署，前端使用负载均衡，因此RabbitMQ主从节点上都会有生产者和消费者连接。此为应用背景。
版本：
OS: Debian 7, 3.2.39-2 x86_64 GNU/Linux
Erlang: R15B01 (erts-5.9.1)
RabbitMQ: 3.0.2 (ha policy, ha-mode:all)
故障现象还原：
1. 节点A的数据盘故障（磁盘控制器故障、无法读写），所有原本A上的生产者消费者failover到B节点。
2. 从节点B的WebUI上看，所有队列信息(包括队列元信息和数据)丢失，但是exchange、binding、vhost等依旧存在。
3. 节点B的日志中出现大量关于消费请求的错误日志：
=ERROR REPORT==== 23-Apr-2015::19:31:26 ===
connection <0.1060.0>, channel 1 - soft error:
{amqp_error,not_found,
"home node '[email protected]' of durable queue 'test' in vhost
'2891f31d' is down or inaccessible", 'basic.consume'}
4. 从生产者端看来一切正常，依旧会收到来自节点B的confirm消息(basic.ack amqp方法)。
经过一番排查定位，上述现象实际上有两个坑在里面：
一、 在数据可靠性方面，镜像队列也不完全可靠。
二、 要保证消息可靠性，生产者端仅仅采用confirm机制还不够。
对于第一个坑：
第一感觉应该是bug，其他人也出现过。在云环境下要重现这个Bug很简单，申请两台云主机做RabbitMQ HA，部署镜像队列。另外申请两块云硬盘，分别挂载到两台云主机，作为数据盘为RabbitMQ提供元信息和队列数据提供存储(${RABBITMQ_HOME}/var/lib)，模拟生产者和消费者对主节点(假设为节点A)进行生产消费，此时可以从云平台管理界面上卸载节点A上的云硬盘，观察节点B RabbitMQ WebUI，可以发现队列不见了。:)
换上最新版的3.5.1就没这个问题，但是要确认是哪个版本对它进行修复的却耗费了很久。初步翻阅了3.0.3 ~ 3.5.1之间大概20多个版本的Changelog，没有看到哪个bugfix的描述符合。只好用最笨的办法，对所有版本号采用二分法，挨个版本测试，最终将修复版本确定为3.4.0 (Changelog)。但是即便如此，也还是没有看到具体是哪个bugfix修复了此问题。
对于第二个坑：
对于队列不存在了，RabbitMQ依然向生产者返回confirm消息的情况，实际上通过生产者端的正确编程姿势可以避免。RabbitMQ官方有过说明:
For unroutable messages, the broker will issue a confirm once the exchange verifies a message won't route to any queue (returns an empty list of queues). If the message is also published as mandatory, the basic.return is sent to the client before basic.ack.
也就是说，对于那些路由不可达的消息(根据routerkey，找不到相应队列)，如果basic.publish方法没有设置mandatory参数(关于mandatory参数，可以参考『AMQP协议mandatory和immediate标志位区别』)，那么RabbitMQ会直接丢弃消息，并且向客户端返回basic.ack消息；如果basic.publish方法设置了mandatory参数，那么RabbitMQ会通过basic.return消息返回消息内容，然后再发送basic.ack消息进行确认。
因为节点上的队列元信息在第一个踩的坑里已经丢失了，所以所有发送到此节点上的消息必然是不可到达的，加上未在basic.publish方法上加mandatory参数，因此消息直接被RabbitMQ丢弃，并被正常confirm掉。
要避免踩这个坑，Java SDK的Channel对象提供了addReturnListener()回调方法，当收到服务器端的basic.return消息时，ReturnListener方法被调用，生产者端可以进行消息重传。当然，前提是basicPublish()方法的mandatory参数已经设置为true。