我们需要一个基于客户端的轻量级消息传递解决方案。我们以前使用过AMQP，RabbitMQ，但是在C ++中我们遇到了问题。
我们想使用malamuteserver或MQTT选择ZeroMQ？我们的物联网几乎每5分钟就会发布数据（45 kb）。
我们需要100％发送此邮件，并且不想丢失任何邮件。
我们尝试了MQTT QoS级别2，但是当服务器断开连接或主服务器客户端出现问题时，我们将丢失已发布的消息。
我们需要确切的RabbitMQ任务/工作者模型。消息应在服务器中排队，直到发生任何情况都与使用者连接为止。
欢迎任何建议，方向和例子。
P.S .：这将是生产方式，因此我们想选择问题较少的方式:)
我认为MQTT被过度炒作了，请确保我认为结果是由于可用的开源服务器所致。 Zeromq确实提供了许多功能来构建满足要求的内容。我越看待可用的选项，就越倾向于zeromq。在我们的情况下，我们将以随机间隔从大量设备（网状网络中的网关或它们的终端节点）接收数据。我们的最终消息大小非常简单，一个定界字符串，二进制编码，压缩（<100字节）并通过网络发送。我决定在服务器上的zeromq上接收消息。原因不仅是基于zeromq作为代理，还包括我们如何利用其curveZmq功能来简化设备的配置，并实现简单的ZTP（零触摸配置系统）和密钥可管理性。我在预设时间讨论使用pub / sub与push / pull模式，其中在每个终端设备中都是在云服务器上具有代理订户的发布者或推送者。虽然通常在pub / sub中的pub，在典型的大规模IOT部署中，发布者较少，订阅者更多，但是，pubs / sub的订阅者却更多，所以这让我想知道我是否应该使用pub / sub，并且存在松动的问题。由于订阅者加入速度慢而产生的邮件-如果我们关闭服务器进行维护，该设备将一直发布邮件，直到达到HWM。猜猜总是存在丢失消息的风险，而不管发生什么事-回传网络已关闭且设备命中HWM-这已无法控制。
Malamute并没有太多的文档，否则我会做更多的探索。
所以，您决定使用什么吗？如果您要保留消息直到消息被消耗，我强烈建议将Zeromq作为代理，将工作人员将消息推入持久性存储中..您还可以在其中添加创意，包括添加序列号等，并允许客户端请求给定的消息序列范围等如果它们丢失了。
A:我们需要100％发送此邮件，并且不想丢失任何邮件。[B:消息应该在服务器中排队，直到发生任何事件，直到使用者连接为止。C:这将是生产环境，因此我们想选择一种问题较少的方法：）
A:是可行的A: + B:可行，困难但仍可行A: + B: + C:不是，这种要求的组合确实需要付出代价
[
D:欢迎任何建议，指导和例子。
ZeroMQ作为轻量级来了，毫无疑问，可调/可调整方式超越引用的[[~ 45 [kb / 5 min]吞吐量，但是魔鬼正确理解了这些优势Zen-of-Zero的包装，按原样打包，[[通过设计努力提供零保修]，并允许所有类型的用户设计自己的用例特定的（简称为“ -足够的“保修”需求，因此在其他情况下也不会损失一点效率）。因此，D:
C:]”中的“ 成本”，并且您已达到设计目标。 很容易，这是所有CTO面对并决定下一步的共同任务。奖励部分
如果需要最小化IoT设备的需求，可以将这些[[costs-of- C:与用于可扩展形式通信模式的更轻量级框架的类似自定义适应进行比较由Martin Sustrik et al设计的原型，作为ZeroMQ的妹妹-[[nanomsg
，通常可以节省一些低功耗/稀缺资源在大量的物联网设备中。