c++ - NanoMsg (NNG) 和 FlatBuffers 是否适合这个项目？

Question

如果有更好的东西我们应该考虑，请大声说出来:

我正在寻找一种非常快速和简单的方法来获取多个程序(例如 5 个)- 每个程序都在私有(private) OpenStack 云上的不同节点上运行以相互通信。

• 数据包将是短的 C++ 结构(小于 100 字节)
• 流量会很低(可能低于 100/秒)
• 延迟确实不是问题。 ( friend 之间的几毫秒是多少？)-我们有很多周期和内存
• 消息应该作为发布/订阅客户端/服务器范例完成
• 库应该是 C++ 友好的。但同时适用于 Windows 和 Linux
• 稍后我们可能需要额外的语言绑定(bind)
• 我们不希望丢失消息

这是我的第一个想法。但是如果你有别的东西可以提供。大声喊出来。

UDP 套接字层的友好包装器:

• NanoMSG(NNG，因为它是 nanoMsg 的活跃项目)https://github.com/nanomsg/nng

C++ 结构数据的编码器/解码器:

• FlatBuffers https://google.github.io/flatbuffers/

Answer 1

对于序列化，几乎任何具有正确语言绑定(bind)的东西都可以。 Google Protocol Buffers 与语言无关，有很多可用的绑定(bind)。唯一要避免的是内置在您的源代码中的序列化(就像 Boost 的序列化是/曾经是)，因为那样您就不能轻易地将它移植到另一种语言。

对于消息传输，ZeroMQ、NanoMsg 都是不错的选择。但是，我认为这真的归结为

1. 您非常不想丢失消息，
2. 首先，正是您所说的“丢失消息”的意思。

关于 ZeroMQ(和 NanoMsg)的事情是(AFAIK)在发生故障时没有真正的方法知道消息的命运。例如，在 ZeroMQ 中，如果您发送一条消息，而接收方恰好正在工作并处于连接状态，则该消息将通过连接进行传输。发送端现在认为工作已经完成，消息已经传递。然而，除非并且直到接收端实际调用 zmq_recv() 并完全处理它收到的内容，否则如果接收端进程崩溃、电源故障等，消息仍然可能丢失。这是因为在使用之前，消息存储在 ZeroMQ 运行线程内的 RAM 中(在相应的 Context()-instance 的控制域内)。

您可以通过让某种 ack 消息以另一种方式返回、超时等来解决这个问题。但这开始变得繁琐，您最好使用 RabbitMQ 之类的东西。