从 MQTT 代理消耗的消息数量似乎受到限制

积累知识，胜过积蓄金银！毕竟在Golang开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《从 MQTT 代理消耗的消息数量似乎受到限制》，就带大家讲解一下知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

我正在运行一个 Go 服务，该服务使用 Paho Go MQTT 客户端来订阅主题。生成 MQTT 消息的客户端（也是 Paho，但在 Android 设备上）在生成时进行记录，而我的服务在接收时进行记录。从该图中可以看出，接收端每天的消息数低于 36.000 条，似乎有一个相当一致的“上限”。这些图表几乎完美地相互遵循直到上限，但似乎 go 服务的上限略低于每分钟 600 条消息，这意味着每秒大约 10 条消息。

我应该在哪里寻找解决方案？我找不到任何可以解释此上限的设置（选项）。

正确答案

根据评论 paho.mqtt.golang 默认按顺序传递消息（MQTT spec 提供了一些消息排序的保证，并且在 go 例程中调用处理程序可能会破坏这一点）。这样做的结果是消息将被逐一传递，如果您的处理程序没有跟上，可能会形成一个队列（在 QOS1+ 时，代理需要保留消息，因为可能需要重新发送它们）。 p>

某些代理会限制为客户端排队的消息数量；例如，Mosquitto 中的 max_queued_messages 选项默认为 1000（此默认值在 Mosquitto 1.X 中较低），如果队列超过限制，“消息将被静默丢弃”。

这就是这里发生的事情；应用程序无法跟上传入消息，因此当队列超出限制时，代理开始丢弃消息。

在许多情况下，使用 paho.mqtt.golangoption ClientOptions.SetOrderMatters(false) 会有所帮助；设置此选项后，消息处理程序将在 separate go routine 中调用（因此处理程序必须是线程安全的）。或者在处理程序中启动 go 例程，但请注意，此方法会导致 ACK 在处理程序完成之前发送（如果您的应用程序意外终止，可能会导致消息丢失）。

今天关于《从 MQTT 代理消耗的消息数量似乎受到限制》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！