“保证交付”消息——我应该使用 MQTT 还是 ZeroMQ？ [关闭]

Question

我们需要一个基于轻量级客户端的消息传递解决方案。我们之前用过AMQP、RabbitMQ，但是在C++中就出现了问题。

我们想选择带有 malamuteserver 或 MQTT 的 ZeroMQ 吗？我们的物联网几乎每 5 分钟发布一次数据 (45 kb)。

我们需要 100% 传递此消息，并且不想丢失任何消息。

我们尝试了 MQTT QoS 级别 2，但是当服务器断开连接或主服务器客户端出现问题时，我们会丢失已发布的消息。

我们需要的正是 RabbitMQ 任务/工作者模型。如果发生任何事情，消息应该在服务器中排队，直到消费者连接。

欢迎任何建议、方向和示例。

P.S.：这将是生产，所以我们想选择问题较少的方式:)

Answer 1

我认为 MQTT 被夸大了，当然我认为结果是由于可用的开源服务器。 Zeromq 确实提供了许多功能来构建满足要求的东西。我对可用选项的了解越多，我就越倾向于 zeromq。在我们的例子中，我们将以随机间隔从大量设备（网状网络中的网关或终端节点它们）接收数据。我们最终确定的消息大小非常简单，是一个分隔字符串、二进制编码、压缩（

Malamute 没有太多文档，否则我会进一步探索它。

那么，您决定使用什么了吗？如果您想保留消息直到它们被消费，我强烈建议 zeromq 作为代理，工作人员将消息推送到持久存储中..您也可以在这里发挥创意，包括序列#等..并允许客户端请求给定的消息序列范围等，如果它们丢失了。

Answer 2

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

A: 可行
A: + B: 可行，更难，但仍然可行
A: + B: + C: 不可行，这种需求组合确实需要付出代价

D: 欢迎提出任何建议、指导和示例。

ZeroMQ 即将到来，它是轻量级，毫无疑问，可调/可调整远远超出 ~ 45 [kb / 5 min] 的引用吞吐量，然而，魔鬼对 Zen-of-Zero 的优势有正确的理解，包装原样，按设计努力提供零保修，并让所有种类用户设计他们自己的、特定于用例的（读作“刚好够用”的保证，因此不会对世界其他地方的用例失去一点效率）。

因此，D: 投入了适当的设计工作以弥补“成本”-of-C: strong> 并且您已经达到了设计目标。

如此简单，这是所有 CTO 面临的共同任务并决定下一步。

奖金部分

如果需要最小化 IoT 设备的要求，可以将这些 costs-of-C: 与类似的自定义适配甚至更轻量级的框架进行比较Scalable Formal Communication Pattern Archetypes，由 Martin Sustrik 等 设计，作为 ZeroMQ 的妹妹 - nanomsg，可能会节省一些低功耗/稀缺资源，通常存在于大量物联网设备中。

Answer 3

在现实世界中，不存在“保证交付”之类的东西，因为在许多层面上都可能出现问题：硬件、网络、网络接口、路由、内存限制等等。 （例如，RabbitMQ 将数据存储在内存中，但突然重启或内存不足时会发生什么？） 当人们说“保证交付”时，人们通常的意思是有一些检测和重试机制。这通常是设计应用程序的问题，而不是使用过的产品。在分布式网络中，不可能 100% 了解整个状态。

首先，ZeroMQ 是一个库，而不是一个产品。这意味着（只需几行代码）您可以创建具有任何类型冗余的任何类型的架构。 ZeroMQ 是无代理的，这意味着没有单点故障 - 但如果您真的需要，您可以使用 ZMQ 编写代理系统。

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

ZeroMQ 有更多的套接字类型，而不仅仅是 PUB/SUB，用于不同的用例，其中 MQTT 只知道 PUB/SUB。

Zyre 是为不稳定的网络构建的消息传递系统，可保证交付（在限制范围内）。它是使用 ZeroMQ 构建块构建的，可能最适合物联网