对列软件 :rabbitmq, 协议 AMQP
现象:队列数据被消费,但是对应的数据没有在数据有展示导致前端显示错误。
第一次排查怀疑的几个方向1:代码出问题了没有写到数据库。2:队列消费失败导致没有写入数据库。打开消费端日志,发现日志没有报错,只是看到消息接收了两次,然后提示已被消费,可以排除数据库插入错误,可以排除消费端程序没有宕掉,没有消费失败。
第二次排查,先把redis 锁关闭,再把进程都关闭只留一个进程消费。发现是消息是不断地重复消费,重复5次之后suervisor 报了致命错误,从这里怀疑是消费端心跳超时导致的消息没有被消费,但是有个不符合的现象是没有记录消费错误的日志这个怀疑不太准确。
第三次排查 将supervisor中管理的消费进程关掉,在命令行直接使用PHP 执行该进程,发现消息是没有被消费只有接收到消息的日志,然后进程自动结束,但我这是守护进程啊,不该关闭的,很纠结,而且有个现象是数据量比较小的时候是可以正常消费的,但是如果数据量大的话会消费失败。加强了对消费超时心跳超时导致的链接断掉的怀疑。
第四次排查,心跳时间加长,tcpdump 吧,看看干了点什么,多次打包发现协商,没有问题但是消费端突然向服务端提出关闭连接的请求,reset 还发现在有不断地 请求连接不断地发送消息不断地发消息然后是不断的关闭channel,就开始怀疑是不是因为在这个进程里面还有连接其他队列的的程序导致的?因为我是用的一个共用的链接服务端,所以有这怀疑,
第五次
记一次排查队列消费失败
最新推荐文章于 2023-04-17 20:26:33 发布
对列软件 :rabbitmq, 协议 AMQP现象:队列数据被消费,但是对应的数据没有在数据有展示导致前端显示错误。第一次排查怀疑的几个方向1:代码出问题了没有写到数据库。2:队列消费失败导致没有写入数据库。打开消费端日志,发现日志没有报错,只是看到消息接收了两次,然后提示已被消费,可以排除数据库插入错误,可以排除消费端程序没有宕掉,没有消费失败。第二次排查,先把redis 锁关闭,再把进程...
摘要由CSDN通过智能技术生成