大声喊出我们是否应该考虑更好的事情：
我正在寻找一种非常快速且简单的方法来获取多个程序（例如 5 个） - 每个程序都在私有 OpenStack 云上的单独节点上运行以相互通信。
- 数据包将是短 C++ 结构（小于 100 字节）
- 交通流量将会较少（可能低于 100 辆/秒）
- 延迟确实不是问题。 （朋友之间的几毫秒是多少？） - 我们有很多周期和内存
- 消息应该以发布/订阅客户端/服务器范例的方式完成
- 库应该是 C++ 友好的。但可以在 Windows 和 Linux 上工作
- 稍后我们可能需要额外的语言绑定
- 我们不希望丢失消息
这是我的第一个想法。但如果你还有其他东西可以提供。喊出来。
UDP 套接字层的友好包装器：
- NanoMSG（NNG，因为它是 nanoMsg 的活跃项目）https://github.com/nanomsg/nng
C++ 结构数据的编码器/解码器：
- 平面缓冲区https://google.github.io/flatbuffers/
对于序列化，几乎任何具有正确语言绑定的东西都可以。 Google Protocol Buffers 与语言无关，有很多可用的绑定。唯一要避免的是内置于源代码中的序列化（如 Boost 的序列化 is / was），因为那样你就无法轻松地将其移植到另一种语言。
对于消息传输，ZeroMQ、NanoMsg 是不错的选择。然而，我认为这实际上可以归结为
- 你多么不想丢失消息，
- 正是您所说的“丢失消息”的意思。
关于 ZeroMQ（和 NanoMsg）的问题是（据我所知）当发生故障时，没有真正的方法可以知道消息的命运。例如，在 ZeroMQ 中，如果您发送一条消息，而接收者恰好正在工作并已连接，则该消息将通过该连接传输。发送端现在认为工作已经完成，消息已经传递。然而，除非且直到接收端实际调用zmq_recv()并完全处理所给的内容，如果接收端进程崩溃、断电等，消息仍然可能丢失。这是因为在消息被消耗之前，消息存储在 ZeroMQ 运行线程内的 RAM 中（各自的Context()-实例的控制域）。
您可以通过某种形式的 ack 消息以其他方式返回、超时等来解决这个问题。但这开始变得很麻烦，您最好使用 RabbitMQ 之类的东西。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
