单机磁盘故障引发RabbitMQ镜像队列数据丢失

from http://fengchj.com/?p=2367
昨天mq不能正常连接了，错误代码如下，后来跟运维部门的同事确认才发现是mq当机了，由于mq不是我们来维护的，也不知道为什么当机了，就搜索了这篇文章，不知道是否和我们的真实情况一样

Mar 29, 2016 11:39:30 AM org.springframework.amqp.rabbit.listener.BlockingQueueConsumer start
WARNING: Reconnect failed; retries left=2
java.io.IOException
    at com.rabbitmq.client.impl.AMQChannel.wrap(AMQChannel.java:106)
    at com.rabbitmq.client.impl.AMQChannel.wrap(AMQChannel.java:102)
    at com.rabbitmq.client.impl.AMQChannel.exnWrappingRpc(AMQChannel.java:124)
    at com.rabbitmq.client.impl.ChannelN.queueDeclarePassive(ChannelN.java:790)
    at com.rabbitmq.client.impl.ChannelN.queueDeclarePassive(ChannelN.java:61)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.springframework.amqp.rabbit.connection.CachingConnectionFactory$CachedChannelInvocationHandler.invoke(CachingConnectionFactory.java:348)
    at com.sun.proxy.$Proxy25.queueDeclarePassive(Unknown Source)
    at org.springframework.amqp.rabbit.listener.BlockingQueueConsumer.start(BlockingQueueConsumer.java:213)
    at org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer$AsyncMessageProcessingConsumer.run(SimpleMessageListenerContainer.java:524)
    at java.lang.Thread.run(Thread.java:745)
Caused by: com.rabbitmq.client.ShutdownSignalException: channel error; reason: {#method(reply-code=404, reply-text=NOT_FOUND - home node 'rabbit@rabbitmq176124' of durable queue 'cadtongji.glodon.com_tongji.func.que' in vhost '/cadtongji' is down or inaccessible, class-id=50, method-id=10), null, ""}
    at com.rabbitmq.utility.ValueOrException.getValue(ValueOrException.java:67)
    at com.rabbitmq.utility.BlockingValueOrException.uninterruptibleGetValue(BlockingValueOrException.java:33)
    at com.rabbitmq.client.impl.AMQChannel$BlockingRpcContinuation.getReply(AMQChannel.java:343)
    at com.rabbitmq.client.impl.AMQChannel.privateRpc(AMQChannel.java:216)
    at com.rabbitmq.client.impl.AMQChannel.exnWrappingRpc(AMQChannel.java:118)
    ... 11 more
Caused by: com.rabbitmq.client.ShutdownSignalException: channel error; reason: {#method(reply-code=404, reply-text=NOT_FOUND - home node 'rabbit@rabbitmq176124' of durable queue 'cadtongji.glodon.com_tongji.func.que' in vhost '/cadtongji' is down or inaccessible, class-id=50, method-id=10), null, ""}
    at com.rabbitmq.client.impl.ChannelN.asyncShutdown(ChannelN.java:474)
    at com.rabbitmq.client.impl.ChannelN.processAsync(ChannelN.java:315)
    at com.rabbitmq.client.impl.AMQChannel.handleCompleteInboundCommand(AMQChannel.java:144)
    at com.rabbitmq.client.impl.AMQChannel.handleFrame(AMQChannel.java:91)
    at com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.java:533)

某分布式消息推送系统，用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。