不订阅＃-那么如何使用Mosquitto将所有消息转储到数据库？

当尝试将所有消息转储到数据库时，HiveMQ的博客在“最佳实践”下列出了不订阅多级通配符的内容。他们声称，订阅客户端可能无法跟上大量消息的需求，并建议使用代理插件直接代替消息流。

有时有必要订阅所有消息，这些消息是通过代理传输的，例如，将所有消息持久保存到数据库中时。不应通过使用MQTT客户端并订阅多级通配符来完成此操作。原因是，订阅客户端通常无法处理即将发送的消息负载。尤其是如果您的吞吐量很高。我们推荐的解决方案是在MQTT代理中实现扩展，例如，HiveMQ的插件系统允许您了解HiveMQ的行为，并添加异步例程来处理每条传入的消息并将其持久化到数据库中。

有没有

• 蚊子经纪人的类似系统（扩展程序/插件），
• 推荐的另一种与蚊子一起工作的方法，或者
• 有合理的证据证明这种方法根本没有必要，也就是说，订阅的客户#可以做得很好吗？

^{/programming//q/31584613/3984613并未详尽解决此问题。}

mosquitto经纪人的类似系统（扩展/插件）

据我所知，没有针对mosquitto broker的插件/扩展（至少没有开源的）。

另一种推荐的与mosquitto一起使用的方法

好吧，我可以说根据我在Mosquitto经纪人和AWS IoT方面的经验，您可以直接订阅“＃”

合理的证据

在看了这个问题之后，我有点好奇地了解吞吐量限制并找出是否需要扩展系统。因此，我设置了以下内容：

• 100个充当虚拟终端设备的AWS Lambda函数将一些随机数据发送到网关（EC2实例t2.nano500MB RAM）
• 每60秒触发一次函数，以将数据发布到不同主题的网关（lambdatoec2 / {VariableTopicNumberFrom1-100}
• EC2实例正在运行Mosquitto 1.4.10

到目前为止，我看到没有任何扩展系统的情况下，订购＃毫无问题。但是同样，我仍然必须测试一些极端情况（一旦测试它们，我将更新答案）。

关于openHAB邮件列表的讨论似乎表明，将其#用作订阅来接收所有消息没有问题：

在对MQTT设备进行故障排除时，我想到有时候我希望我可以看到Mosquitto代理看到的所有MQTT消息，而不是某个特定主题的消息。有没有办法做到这一点？

有人在蚊子名单上为您回答了这个问题；使用通配符。（＃）

此堆栈溢出问题也建议使用相同的方法：

订阅＃即可订阅除以$开头的主题（无论如何，这些主题通常都是控制主题）之外的所有内容。

当然，最好先了解要订阅的内容，并注意某些代理配置可能不允许显式订阅＃。

正如Bence Kaulics所指出的，该规范确实指出了#有效：

非规范性评论

• “＃”有效，并且将收到每个申请消息

老实说，我对最初的主张是否真的有道理感到怀疑：

原因是，订阅客户端通常无法处理即将发送的消息负载。

如果是这样，那么经纪人首先如何处理消息？只要您的客户端具有与代理类似的性能特征，我就强烈怀疑是否有可能使客户端不堪重负，因为这种流量也将使代理不堪重负，并首先导致崩溃。

总而言之，HiveMQ的主张似乎并没有得到其他来源的大量证据的支持，而且当您考虑其实际含义时，似乎并不合乎逻辑。

我认为重要的是要考虑到MQTT代理有许多不同的用例，就像任何软件一样。

处理十亿用户的聊天消息（许多用户，每个用户的消息率相对较低）不同于客户端少但消息率高的系统，它们都与家庭自动化系统不同（客户端少，消息率低） 。

HiveMQ正在考虑很高的客户端/消息率应用程序-在这种情况下，代理的功能几乎可以肯定远远超过了客户端。

如果您想#在家庭自动化系统中进行订阅，那么确实不太可能引起问题。您可以检查代理在任何情况下是否都使用过多的CPU。

与其他答案一样，订阅#将给您所有“正常”的主题，即不以开头的任何主题$。我解释规范的话说，每一个话题开始$，本身就是一个完整而独立的树，所以你必须订阅$SYS/#，$whatever/#得到一切。对于正常的应用程序，您极有可能不想这样做。