rabbitmq 队列堵塞

RabbitMQ使用不当导致的队列堵塞问题及解决之道

 本接盘侠接手的一个服务使用RabbitMQ和其他服务进行消息传输。我们发现，有时候 RabbitMQ中明明有元素，但是不会回调DefaultConsumer接口的handleDelivery函数，于是队列无法消化，队列越堵越长。通过jstack查看，发现rabbitmq消费者线程堵塞在socketinputstream的socketRead0函数。通过搜索，发现这个文章： 《Queue consumers are blocked onSocketInputStream.socketRead0》。

     我们的现象跟文章是一样的。那是否是因为没有正确地ACK/NACK导致的队列堵塞问题呢？我们进一步通过 rabbitmqctl 命令进行查看，注意name  messages_unacknowledged可以 查看被取走但还没有ACK的消息数：

rabbitmqctl  list_queues -p xxx.host namemessages_ready messages_unacknowledged 

unacknowledgedListing queues ...

xxx.queue 0 500 （我们的Qos设置为500，这时候没有ACK的消息数量已经达到上限，队列）

...done.

     通过以上排查基本可以确定队列堵塞是由于消费者线程取走了消息，但是既没有ACK，也没有NACK，这样的消息个数到达Qos设置的值后，队列就会堵塞，不再回调 handleDelivery函数。我查看原来的代码，发现逻辑十分混乱，在各种分支和异常处理中进行basicAck和basicNack操作，经过仔细分析发现存在分支遗漏这两个操作，这样就可能在长时间运行后，最终导致队列的堵塞。

    解决办法应该是在finally语句中来执行这些操作，我分析从队列中取出消息后，会有三种处理结果：1、处理成功，这种时候应该用basicAck确认消息；2、可重试的处理失败，这时候应该用basicNack将消息重新入列；3、不可重试的处理失败，这时候应该使用basicNack将消息丢弃。

状态定义：

enum Action {

  ACCEPT,  // 处理成功

  RETRY,   // 可以重试的错误

  REJECT,  // 无需重试的错误

}

代码框架如下：

Action action = Action.RETRY; 

try {

    //如果成功完成则action= Action. ACCEPT

}

catch (Exception e) {

   // 根据异常种类决定是 ACCEPT、 RETRY还是  REJECT

}

finally {

  // 通过finally块来保证Ack/Nack会且只会执行一次

  if (action == Action. ACCEPT) {

   channel.basicAck(tag);

  } else if (action == Action.RETRY) {

    channel.basicNack(tag, false, true);

  } else {

    channel.basicNack(tag, false, false);

  }  

}