环境
- EMQX 版本：5.0.19
- 操作系统版本：centos7
重现此问题的步骤
-
1k主题，每个每秒消息1条，消费被踢掉节点，只有一个消费节点，前几天消息每秒流入1500，流出1500是正常的，突然今天出现了问题，不能消费了，消费节点被踢，不断的重连又被踢
-
xxx
-
xxx
预期行为
日志追踪和emqx日志
mqtt-IQDvqVatwO.zip (930.1 KB)
emqx.log.10.zip (1.7 MB)
golang消费服务端的错误信息
首先看了下，日志里都是这样的告警。一秒大概 1183 条的消息丢弃
2023-04-24T14:22:16.461948+08:00 [warning] msg: dropped_msg_due_to_mqueue_is_full, mfa: emqx_session:handle_dropped/3, line: 643, peername: 123.168.101.215:1982, clientid: mqtt-h6LuqEhBUs, topic: data/SJ20130406/JX350/1383340119, payload: #{extra => [],flags => #{dup => false,retain => false},from => <<"MzEwMzMyNzUwODI0MTM5NTI2MTQ1OTcwMzE3ODgwODUyNDI">>,headers => #{peerhost => {123,168,101,215},properties => #{},proto_ver => 4,protocol => mqtt,username => <<"admin">>},id => <<0,5,250,15,6,163,190,67,244,64,88,0,45,189,44,129>>,qos => 0,timestamp => 1682317326401,topic => <<"data/SJ20130406/JX350/1383340119">>}, queue: #{dropped => 78579,len => 1000,max_len => 1000,store_qos0 => true}
但是并没有找到客户端有上报心跳报文 （PINGREQ) 整个日志文件持续 1 分钟。设备测的心跳是多少时间发一次呢？
另外，方便的话再测试的时候看下进程消息堆积情况如何：
-
bin/emqx eval 'observer_cli:start()'启动监控 - 输入
mq按 MsgQueue 阻塞消息数量排序 - 开始测试，并观察刚刚的监控页面，是否有 MsgQueue 过大的情况
我设置的队列长度1万，但是前段时间每秒消息1k没什么问题，设备心跳我试过0s，20s和30s都不行
日志追踪要抓下全流程的，即设备登录到断开重连，这个过程。这样方便分析 “为什么 golang 客户端报告 pingreps not recevied”的问题。
初步排查：
场景
- 1 台 EMQX，部署在服务器
- 1000 个发布客户端（MacOS本机） 1秒1条，约 1000条每秒的 TPS
- Go 的 MQTT 客户端订阅 （MacOS 本机）
data/#主题接收这 1000 条消息，2-3秒后通过 observer_cli 看到 MsgQueue 增长到 ~10000，Go 客户端报告pingreps not received, disconnting导致连接断开
初步结论
- Go 回调中执行了
Redis.Set(..)和Redis.Publish(..)操作，导致消费跟不上而导致堆积；注释掉这些操作后，暂未看见堆积问题
建议：
- 通常不使用一个客户端订阅接收大量消息（超过 1000 tps ），一旦消费跟不上、或者波动 EMQX 很容易会由于队列满而丢弃这些消息，甚至直接关闭客户端。可以考虑
- 消息接收回调中尽量少依赖外部 I.O, ；或使用异步处理提高吞吐能力
- 共享订阅、提高消费能力。
- 企业版的桥接到 Kafka 等功能，去耦合。
- 压力过大时，建议通过多台 Linux 服务器测试，不推荐 MacOS 和 Windows 个人主机（容易遇到各种干涉）