MQTT与MQ设计考虑因素

Question

我这里没有具体的查询;只需要一些设计指南。

我在Node.js , MQTT and Websockets上看到了这篇文章。 我想我们可以使用Node / Java + ActiveMQ + Websockets实现类似的目的。我的查询是如何在MQ和MQTT之间进行选择的？与ActiveMQ相比，我可以安全地在大中型项目中使用mosquitto这样的“开放”服务器吗？

This article已经有了一些见解，似乎我应该同时使用MQ和MQTT，因为如果我将来获得轻量级客户端，MQTT可能会有所帮助。

谢谢！

Answer 1

除了Shashi所说的，它们具有不同的功能和用例。

MQTT为pub / sub定义了标准的线路协议，正如Shashi所说，它是为非常轻量级的环境而设计的。因此，它具有非常小的线格式，一些基本服务质量和基本功能集。

另一方面，传统的消息排队系统通常是专有的（虽然AMQP的目的是改变它），涵盖点对点和发布/订阅，提供许多服务质量，并倾向于拥有更重量级的线路格式，虽然这样做是为了支持增强的功能集，例如回复寻址，协议转换等等。

MQTT的一个很好的例子就是手机，平板电脑和机顶盒中的端点。它们具有最小的马力，内存和系统资源。通常，来自这些的连接要么保持MQTT，要么在它们之间进行通信，要么它们桥接到企业级MQ，在那里它们可以与后端应用程序进行相互通信。例如，基于MQTT的聊天客户端可能通过MQTT代理直接与另一个聊天客户端进行通信。或者，基于MQTT的内容传送系统将桥接到企业消息传送网络，该网络托管要传送到在电话和平板电脑上运行的应用的广告和其他内容。企业后端将管理广告投放的所有统计数据和基于账单的视图，而MQTT支持允许在最终用户设备上以最小的电池或马力消耗推送内容。

因此，MQTT用于存在功率，带宽和网络稳定性问题的嵌入式系统和终端用户设备。这通常与传统的MQ消息传递相结合，尽管我从未见过MQTT被用作传统消息传递应用程序的独占传输。据推测，这是因为MQTT缺乏一些更强大的功能，如消息关联，回复寻址和点对点寻址，这些已成为20年来消息传递的核心。

Answer 2

MQTT协议适用于内存占用较少的传感器，移动电话等小型设备。这些设备通常位于脆弱的网络中，通常具有较低的计算能力。

这些设备通过MQTT协议连接到组织后端网络，以发送和接收消息。例如，输油管道中的温度传感器将收集流过管道的油的温度并将其发送到控制中心。作为响应，可以通过MQTT将命令消息发送到另一个设备，以减少/停止通过该管道的油流。

WebSphere MQ具有向/从MQTT设备发送/接收消息的能力。因此，如果您计划实施基于消息传递的解决方案，该解决方案涉及设备和传感器，您可以考虑MQ和MQTT。

HTH

Answer 3

如前所述，MQTT定义了一个应用程序有线协议（即在传输之前如何组织和序列化信息）。 Mosquitto或其他任何MQTT代理只是Hub and Spoke Integration Pattern的实现，就像基于JMS和AMQP的代理一样，区别在于传输级别的有线协议：{{3}定义了标准化的传输线协议，而ActiveMQ等JMS代理定义了自己的专有格式，即AMQP。当然，不像Mosquitto这样的标准实现实现专有的线传输协议（这会影响互操作性，但在性能方面可能是更好的选择）。

回到问题。根据您在可扩展性和可靠性方面的需求，像Mosquitto这样的经纪人可以在真实场景中使用：通常，需要聚类来确保我。可用性，ii。可靠性和iii。可扩展性。经纪人认为PAN（Private Area Netorks），通常不提供OTB（Out of The Box）这样的功能--ActiveMQ提供了这一功能。

总结，它可以满足您的要求，为您挑选最佳解决方案。