<分区>
我们需要一个基于客户端的轻量级消息传递解决方案。我们以前用过AMQP，RabbitMQ，但是在C++中我们遇到了问题。
我们想选择 ZeroMQ with malamuteserver 还是 MQTT？我们的物联网几乎每 5 分钟就会发布一次数据 (45 kb)。
我们需要 100% 传递此消息并且不想丢失任何消息。
我们尝试了 MQTT QoS 级别 2，但是当服务器断开连接或主服务器客户端出现问题时，我们将丢失已发布的消息。
我们恰好需要 RabbitMQ 任务/ worker 模型。如果发生任何事情，消息应该在服务器中排队直到消费者连接。
欢迎任何建议、方向和示例。
P.S.:这将是生产环境，所以我们希望选择问题较少的方式 :)
最佳答案
我认为 MQTT 被夸大了，当然我认为结果是由于可用的开源服务器。 Zeromq 确实提供了很多功能来构建满足要求的东西。我越看可用的选项，就越倾向于 zeromq。在我们的例子中，我们将以随机间隔从大量设备(网状网络中的网关或终端节点 themsevles)接收数据。我们最终确定的消息大小非常简单，一个分隔字符串，二进制编码，压缩(<100 字节)并通过网络发送。我决定在服务器上使用 zeromq 来接收消息。原因不仅基于 zeromq 作为代理，还在于我们如何利用其 curveZmq 功能来简化设备配置，并允许简单的 ZTP(零接触配置系统)和 key 可管理性。我在预设时间辩论使用发布/订阅与推/拉模式，其中每个终端设备都是发布者或推送者，在云服务器上有代理订阅者。虽然通常在 pub/sub 中发布，但在典型的大规模 IOT 部署中，发布者更少，订阅者更多，发布者更多，订阅者更少，所以我想知道我是否应该使用 pub/sub 并且存在丢失问题由于订阅者加入速度慢而导致的消息——如果我们关闭服务器进行维护怎么办，现场的设备将继续发布消息，直到达到 HWM。猜想总是存在丢失消息的风险，无论发生什么事——回程网络出现故障并且设备命中 HWM——这是无法控制的。
Malamute 没有太多文档，否则我会对其进行更多探索。
那么，您决定使用什么了吗？如果您想保留消息直到它们被使用，我强烈建议将 zeromq 作为代理，让工作人员将消息推送到持久存储中。您也可以在这里发挥创意，包括序列号等，并允许客户端请求给定的消息序列范围等，如果它们丢失了。
关于c++ - "Guaranteed Delivery"消息传递 - 我应该使用 MQTT 还是 ZeroMQ？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50656232/