MQTT与MQ设计考虑因素

Question

我这里没有具体的问题; 只需要一些设计指南.

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

本文有一些见解,似乎我应该同时使用MQ和MQTT,因为如果我将来获得轻量级客户端,MQTT可能会有所帮助.

谢谢 !

Answer 1

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

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

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

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

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