RabbitMQ 匿名队列断开问题定位记录

RabbitMQ 匿名队列断开问题定位分析

 

1    问题现象

平台中，服务的信息交互通过RabbitMQ进行。在实际的使用中，发现系统启动后，就会出现status 监控的mq connection断开，服务实例无法接收web端的控制命令。

  

2    问题分析

经过查看日志信息，系统与mq断开时有如下异常日志打印：

 

2018-06-20 19:19:44,335 [Thread-140618412050176] connection.py[line:1952] INFO Disconnected from RabbitMQ at 10.25.73.2:5672 (505): UNEXPECTED_FRAME - expected content header for class 60, got non content header frame instead

2018-06-20 19:19:44,336 [Thread-140618412050176]blocking_connection.py[line:472] ERROR Connection close detected; result=BlockingConnection__OnClosedArgs(connection=>, reason_code=505, reason_text='UNEXPECTED_FRAME - expected content header for class 60, got non content header frame instead')

Unhandled exception in thread started by >>>>

Traceback (most recent call last):

  File "/root/.local/lib/python3.5/site-packages/pika/adapters/blocking_connection.py", line 1780, in start_consuming

    self.connection.process_data_events(time_limit=None)

  File "/root/.local/lib/python3.5/site-packages/pika/adapters/blocking_connection.py", line 707, in process_data_events

    self._flush_output(common_terminator)

  File "/root/.local/lib/python3.5/site-packages/pika/adapters/blocking_connection.py", line 474, in _flush_output

    result.reason_text)

pika.exceptions.ConnectionClosed: (505, 'UNEXPECTED_FRAME - expected content header for class 60, got non content header frame instead')

 

经过网上搜索，问题的原因为多线程向channel发送消息会导致此问题。

  

3    使用架构分析

系统架构如下：

 Status实例与MQ有两个channel：

• 服务控制：exchange的类型为fanout，用来接收web端的控制命令
• 状态上报：channel定期向另外一个exchange发送消息上报服务的状态

 

使用机制：

1. 服务控制 channel创建后，启动一个线程来消费channel的消息。
2. 状态上报 channel每隔15秒上报一次status信息
3. 心跳机制，每隔30秒心跳线程会使用控制和状态的channel发送心跳信息。

分析到这里，问题比较明了，服务控制channel存在多线程使用的情况。心跳线程和任务消费线程会同时使用同一个channel，导致出现UNEXPECTED_FRAME的错误，同时导致mq的connect断开。

4    解决方案

接收消息的channel属于长连接，不发送心跳也不会中断。把接收消息的channel从heartbeat中去除，只使用发送消息的channel发送心跳。

  

5    同connect多个channel收发问题

5.1   问题描述

同一个MQ connect创建多个channel，有接收消息的，有发送消息的，这样的使用场景，也会出现UNEXPECTED_FRAME错误，导致connection断开连接。

5.2   解决方案

收发消息的channel分别用两个connect创建，防止出现异常