问“保证传递”消息--我应该使用MQTT还是ZeroMQ？

EN

我认为MQTT被夸大了，我认为其结果应该归功于可用的开源服务器。Zeromq确实提供了很多特性来构建一些能够满足需求的功能。我越多地查看可用的选项，我就越倾向于零。在我们的示例中，我们将从大量设备(网格网络中的网关或终端节点)随机接收数据。我们最终确定的消息大小非常简单，一个分隔字符串、二进制编码、压缩( <100 Bytes)并通过导线发送。我决定在服务器上选择零来接收消息。其原因不仅是基于作为代理的zeromq，而且还包括如何利用它的curveZmq特性来简化设备的配置，并允许简单的ZTP (Zero Touch provisioning )和密钥管理。我在预置时间辩论如何使用pub/sub /pull模式，在每个终端设备中都是在云服务器上使用代理订阅服务器的发布者或推动者。通常，pub/sub中的pub较少，而在典型的大规模IOT部署中，订阅者更多，发行者更多，订阅者更少，这让我怀疑是否应该使用pub/sub，而且由于加入订阅服务器的速度慢，导致消息丢失的问题--如果我们关闭服务器以进行维护，该领域的设备会一直发布消息，直到HWM到达为止。我想，不管任何回传网络被关闭，设备击中了HWM，总是有丢失消息的风险--这是失控的。

马拉默特没有太多的文档，否则我会更多地研究它。

那么，你决定用什么了吗？如果您想要持久化消息直到它们被消耗，我强烈建议使用zeromq作为代理，让工作人员将消息推送到持久存储中。在这里，您也可以通过包含一个序列# etc..and来获得创造性，允许客户机在消息丢失时请求给定的序列范围等消息。

A:我们需要100%地传递这条消息，并且不想丢失任何消息。 如果发生任何事情，B:消息应该在服务器中排队，直到连接到消费者为止。 C: --这将是生产--所以我们希望选择一种问题较少的方式:)

A:是可行的

A: + B:是可行的，更难，但仍然可行

A: + B: + C:不是，这种需求的组合是需要付出代价的。

D:欢迎您的任何建议、方向和例子。

随着lightweight，的到来，“超越~ 45 [kb / 5 min]，的可调/可调整的方式”( ZeroMQ beyond )即将到来，然而，“魔鬼”是在正确理解Zen-of-Zero，软件包的优势的情况下出现的，因为--通过设计力求提供零保修，并允许所有类型的用户设计自己的、特定于用例的(理解为“足够”的-warranty one需求，这样就不会对世界其他用户的使用失去一点效率)。

因此，D:投入了适当的设计--为覆盖"costs"-of-C:而付出的努力--您已经达到了设计目标。

如此简单，这是一个共同的任务，任何和所有的首席技术官面对这一问题，并决定下一步。

奖金部分

如果需要将物联网设备的需求降到最低，可以将这些costs-of-C:与一个类似的定制框架进行比较--即使是一个更轻量级的可伸缩正式通信模式原型框架，这个框架是由Martin等人设计的，作为ZeroMQ one的妹妹-- 奈米 --可能会节省一些低功耗/更稀缺的资源，就像大量物联网设备中普遍存在的那样。

在现实世界中，没有所谓的“保证交付”，因为在许多方面都可能出错:硬件、网络、网络接口、路由、内存限制等等。(例如，RabbitMQ将数据存储在内存中，但在突然重新启动或内存耗尽时会发生什么情况？)当人们说“保证交付”时，通常的意思是有一些检测和重试机制。这通常是设计应用程序的问题，而不是使用的产品。在分布式网络中，不可能100%地了解整个状态。

首先，ZeroMQ是一个库，而不是一个产品。这意味着(使用几行代码)您可以使用任何类型的冗余创建任何类型的体系结构。ZeroMQ是无券商的，这意味着没有单一的故障点--但是如果您真的想要的话，可以使用ZMQ编写一个经纪系统。

MQTT是一个PUB/子系统，它使用代理来检查消息的传递。这就引入了一个单一的故障点。

ZeroMQ有更多的套接字类型，而不是PUB/SUB，对于不同的应用程序，MQTT只知道PUB/SUB。

Zyre是一个为不稳定网络构建的消息系统，它保证传递(在限制范围内)。它是使用ZeroMQ构建块构建的，并且可能对IoT最好。