RabbitMQ使用不当导致的队列堵塞问题及解决办法
2015-10-14 21:03
489 查看
本接盘侠接手的一个服务使用RabbitMQ和其他服务进行消息传输。接手后发现:有时候RabbitMQ中明明有元素,但是不会回调DefaultConsumer的handleDelivery函数,于是队列无法消化,越堵越长。通过jstack查看,发现rabbitmq消费者线程堵塞在socketinputstream的socketRead0函数。通过搜索,发现这篇文章:《Queue
consumers are blocked on SocketInputStream.socketRead0》。
我们的现象跟文章中描述的挺像的。那是否是因为没有正确地ACK/NACK导致的队列堵塞问题呢?可以进一步通过rabbitmqctl 命令进行查看,参数"name messages_unacknowledged"可以查看被取走但还没有ACK的消息数:
rabbitmqctl list_queues -p xxx.host name messages_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将消息丢弃。
状态定义:
处理代码:
类似这种必须执行的代码,一定要放在finally块中。如果在各种 if else exception 里面鸡零狗碎地ack、nack,是容易出很篓子的。即使一开始开发人员能够考虑周全,在后续的开发和维护中也可能百密一疏。所以一开始就要保证逻辑的严密性。
consumers are blocked on SocketInputStream.socketRead0》。
我们的现象跟文章中描述的挺像的。那是否是因为没有正确地ACK/NACK导致的队列堵塞问题呢?可以进一步通过rabbitmqctl 命令进行查看,参数"name messages_unacknowledged"可以查看被取走但还没有ACK的消息数:
rabbitmqctl list_queues -p xxx.host name messages_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) { // 根据异常种类决定<span style="font-family: 'Microsoft YaHei', SimSun, Verdana, Arial, Helvetica, sans-serif;">action</span>是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); } }
类似这种必须执行的代码,一定要放在finally块中。如果在各种 if else exception 里面鸡零狗碎地ack、nack,是容易出很篓子的。即使一开始开发人员能够考虑周全,在后续的开发和维护中也可能百密一疏。所以一开始就要保证逻辑的严密性。
相关文章推荐
- Rabbitmq集群搭建笔记
- python使用rabbitmq实现网络爬虫示例
- Linux下PHP扩展amqp安装
- rabbitmq学习
- CentOS6.5 安装rabbitmq
- 非常不错的rabbitmq集群高可用部署
- Rabbitmq 安装与配置
- rabbitmq可靠性保证(原文加上部分标记)
- rabbitmq流控制(原文标记)
- AMQP协议
- RabbitMQ 系列——1.初始
- rabbitMQ安装
- rabbitmq——用户管理
- rabbitmq 消息传送与监听
- rabbitmq 消息传送与监听
- [翻译] [RabbitMQ+Python入门经典] 兔子和兔子窝
- RabbitMQ的WEB管理器rabbitmq_management
- RabbitMQ修改端口号和心跳时间
- Rabbitmq的网络层浅析
- 使用RabbitMQ实现带权限的Routing