我正在运行使用PAHO GO MQTT客户端订阅主题的GO服务。生产MQTT消息的客户（也是PAHO，但在Android设备上）会在收到时日志时日志记录。从此图中可以看到，似乎每天在接收方下的36.000邮件都有一个非常一致的“上限”。这些图几乎互相关注到帽子，但随后，GO Service在每分钟略低于600条的消息上盖上帽子，这意味着每秒大约10毫秒。
我应该在哪里寻找解决方案？我找不到任何可以解释此上限的设置（选项）。
I'm running a Go service that uses the Paho Go MQTT client for subscribing to a topic. The clients that produce the MQTT messages (also Paho, but on Android devices) log when they produce and my service logs when it receives. As you can see from this graph, there seems to be a pretty consistent "cap" right below 36.000 messages per day on the receiving side. The graphs follow each other almost perfectly up to the cap, but then it seems that the go service caps out on slightly below 600 messages per minute, which means around 10 msgs per second.
Where should I look for the solution to this? I cannot find any setting (options) that could explain this cap.
发布评论
评论（1）
根据注释默认消息的默认消息（ MQTT规格提供了一些保证的消息订购，并在GO例程中调用处理程序可能会破坏此问题）。这样做的结果是，消息将逐一传递，如果您的处理程序不跟上，则可能会形成队列（在QoS1+上，经纪人需要保留消息，因为可能需要重新发送它们）。
一些经纪人限制了客户排队的消息数。例如
max_queued_messages在蚊子默认为1000中的选项（此默认值较低蚊子1.x ），如果队列超过限制，则“将默默删除消息”。这似乎在这里发生了。该应用程序没有跟上传入的消息，因此当队列超过限制时，经纪人开始删除消息。
在许多情况下，使用
paho.mqtt.golang选项client> clientoptions.setOrderMatters（false）将有所帮助；使用此选项设置，将在A （因此处理程序必须是螺纹安全）。或者，在处理程序中启动GO例程，但请注意，此方法会导致在处理程序完成之前发送ack（如果您的应用程序出乎意料地终止）。As per the comments
paho.mqtt.golangdefaults to ordered delivery of messages (the MQTT spec provides some guarantees re message ordering and and calling handlers in a go routine may break this). The upshot of this is that messages will be delivered one-by-one and, if your handler is not keeping up, a queue may form (at QOS1+ the broker needs to retain messages as it may be necessary to resend them).Some brokers limit the number of messages queued for a client; for example the
max_queued_messagesoption in Mosquitto defaults to 1000 (this default was lower in Mosquitto 1.X) and, if the queue exceeds the limit, "messages will be silently dropped".This is what appears to have been happening here; the application was not keeping up with incoming messages so the broker began dropping messages when the queue exceeded a limit.
In many cases using the
paho.mqtt.golangoptionClientOptions.SetOrderMatters(false)will help; with this option set the message handler will be called in a separate go routine (so the handler must be threadsafe). Alternatively start a go routine within the handler but note that this approach results in theACKbeing sent before the handler completes (which may result in message loss if your application terminates unexpectedly).