如果我们应该考虑更好的事情,请大声喊出:
我正在寻找一种非常快速和简单的方法来获得几个程序(例如5个) - 每个程序都运行在私有OpenStack云上的不同节点上……
对于序列化,几乎任何具有正确语言绑定的东西都可以。 Google Protocol Buffers与语言无关,可以使用大量绑定。唯一要避免的是源代码中内置的序列化(比如Boost的序列化是/是),因为那样你就不能轻易地将它移植到另一种语言中。
对于消息传输,ZeroMQ,NanoMsg是不错的选择。但是,我认为这真的归结为
关于ZeroMQ(和NanoMsg)的事情是(AFAIK),当发生故障时,没有真正知道消息命运的方法。例如,在ZeroMQ中,如果您发送消息并且收件人恰好正在工作并连接,则消息将通过连接传输。发送端现在认为作业已完成,消息已经发送。但是,除非并且直到接收端实际呼叫 zmq_recv() 如果接收端进程崩溃,电源故障等,消息仍然可以完全处理,消息仍然会丢失。这是因为在消耗之前消息存储在ZeroMQ运行线程内的RAM中(内部)各自的 Context() -instance的控制域)。
zmq_recv()
Context()
你可以通过让某种ack消息向前反转,超时等来解释这个问题。但是这开始变得越来越繁琐,你最好用RabbitMQ之类的东西。
非常尊重玛格丽特·哈米尔顿为阿波罗计划所做的工作。
喊出来。
亲爱的博士, 有很多功能,对于专业决策来说很重要,这些功能在上面的购物清单中没有提到。
如果Apollo AGC示例在这里有所帮助,那就更好了。
寻求的包裹:
如果所有这些对于您在Draper实验室的进一步努力而言非常重要,ZeroMQ将顺利适应(如果某些延迟/性能数据可能需要增强类固醇,因为它比上述成熟混合物更重要,也可能喜欢回顾Martin Sustrik的另一个孩子,比他的ZeroMQ更年轻 - nanomsg 工具)。
无论如何,如果你确实有 (CIT)。 “ 的 ......很多周期和记忆...... 强> “,让我参与进来,如果你允许,我会在业余时间处理很多TFLOP :o)
:o)
鉴于最近的评论,让我补充说明使用海军研究实验室发布的NACK-Oriented Reliable Multicast(NORM) 的 norm:// 强> 运输级,这可能会帮助你纯洁 PUB/SUB - 设计意图,它似乎可以修复 的 渴望“ 不想丢失信息 强> 根据Zen-of-Zero的说法,“否则不会小心”,这会将所有此类操作留在用户端应用程序代码中 的 分布式系统 强> 行为。
norm://
PUB/SUB