Linux C/C++ 远程消息队列的建议
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10440323/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Recommendations for C/C++ remote message queues
提问by Randall Cook
I am working on a project which involves several C++ programs that each take input and generate output. The data (tens to hundreds of bytes, probably JSON) essentially flows (asynchronously) in one direction, and the programs will need to be located on different Linux computers around the LAN.
我正在做一个项目，该项目涉及多个 C++ 程序，每个程序都接受输入并生成输出。数据（数十到数百字节，可能是 JSON）本质上（异步）在一个方向上流动，并且程序需要位于 LAN 周围的不同 Linux 计算机上。
Since the data flows in only one direction, I don't believe I need a transactional model like HTTP. I think a message queue model (fire and forget) makes the most sense and should simplify the logic of each program. It is probably sufficient to merely note that the message was added to the remote queue successfully.
由于数据只向一个方向流动，我认为我不需要像 HTTP 这样的事务模型。我认为消息队列模型（即发即弃）最有意义，应该简化每个程序的逻辑。仅注意消息已成功添加到远程队列可能就足够了。
What I am looking for are recommendations for how to implement this message queue in C or C++. It seems like POSIXand Boostmessage queues are limited to a single host, and RabbitMQseems to have weak C/C++ support, and MQ4CPPseems inadequately supported for a business-critical role. Am I wrong about this? What about Boost ASIOor ACEor writing socket code myself? I look forward to your suggestions.
我正在寻找的是有关如何在 C 或 C++ 中实现此消息队列的建议。它看起来像POSIX和升压消息队列仅限于一台主机，并RabbitMQ的似乎有微弱的C / C ++的支持，并MQ4CPP似乎充分支持业务关键作用。我错了吗？Boost ASIO或ACE或自己编写套接字代码怎么样？我期待着您的建议。
采纳答案by user7116
In terms of simple messaging support, ZeroMQ is hard to beat. It's available in many language bindings and supports everything from simple send and receive to pub/sub, fanout, or even a messaging pipeline. The code is also easy to digest and makes it pretty easy to switch between patterns.
在简单的消息支持方面，ZeroMQ 很难被击败。它在许多语言绑定中可用，并支持从简单的发送和接收到发布/订阅、扇出甚至消息传递管道的所有内容。代码也很容易消化，并且可以很容易地在模式之间切换。
Looking at their Weather Update Server sample(in 20 some odd languages) shows how easy it can be to create publish/subscribe setups:
查看他们的天气更新服务器示例（以 20 种奇怪的语言显示）显示了创建发布/订阅设置是多么容易：
zmq::context_t context (1);
zmq::socket_t publisher (context, ZMQ_PUB);
publisher.bind("tcp://*:5556");
publisher.bind("ipc://weather.ipc");
while(1) {
// Send message to all subscribers
zmq::message_t message(20);
snprintf ((char *) message.data(), 20 ,
"%05d %d %d", zipcode, temperature, relhumidity);
publisher.send(message);
}
I've used it on some mixed C# and Python processes without much hassle.
我已经在一些混合的 C# 和 Python 进程中使用了它，没有太多麻烦。
回答by Fantastic Mr Fox
I am using Boost Serialization and socket sending for a similar application. You can find an example of serialization here :
我正在为类似的应用程序使用 Boost Serialization 和套接字发送。您可以在此处找到序列化示例：
http://code.google.com/p/cloudobserver/wiki/TutoriaslBoostSerialization
http://code.google.com/p/cloudobserver/wiki/TutoriaslBoostSerialization
And on this page:
在此页面上：
http://www.boost.org/doc/libs/1_38_0/doc/html/boost_asio/examples.html
http://www.boost.org/doc/libs/1_38_0/doc/html/boost_asio/examples.html
under serialization you will find examples on how to make servers and clients. Make one server on a particular port and you can generate multiple clients on multiple computers which can communicate with that port.
在序列化下，您将找到有关如何制作服务器和客户端的示例。在特定端口上创建一台服务器，您可以在可以与该端口通信的多台计算机上生成多个客户端。
The downside to using boost serialization is that it has a large overhead if you have a simple data structure to be serialized but it does make it easy.
使用 boost 序列化的缺点是，如果你有一个简单的数据结构要序列化，它会有很大的开销，但它确实很容易。
回答by Linuxios
Personally, if I understand the question, I think that you should use a lower-level TCP connection. It has all of the guarantied delivery that you want, and has a rather good Berkley Sockets API. I've found that if your willing to implement a very simple protocol (eg. four-byte NBO message length, nbytes of data), you can get very simple, very customizable, and very simple. If you go with this, you also (as mentioned) get great C support (which means C++ support, although things aren't in classes and methods). The socket code is also very easy, and they have asynchronous IO with the standard async flags for the Linux/UNIX/POSIX IO functions (thats one of the other benefits, if you know anything about POSIX programing, you basically know the socket API).
就我个人而言，如果我理解这个问题，我认为您应该使用较低级别的 TCP 连接。它具有您想要的所有保证交付，并且具有相当好的 Berkley Sockets API。我发现如果您愿意实现一个非常简单的协议（例如，四字节 NBO 消息长度，n字节数据），您可以获得非常简单、非常可定制且非常简单的结果。如果你这样做，你也（如上所述）获得了很好的 C 支持（这意味着 C++ 支持，虽然东西不在类和方法中）。套接字代码也很简单，它们具有用于 Linux/UNIX/POSIX IO 函数的带有标准异步标志的异步 IO（这是其他好处之一，如果您对 POSIX 编程有所了解，您就基本了解了套接字 API） .
One of the best resources for learning the socket API are:
学习套接字 API 的最佳资源之一是：
- Beej's Guide to Network Programing: http://beej.us/guide/bgnet/, this is very good if you need the overall programming model in addition to specifics
- Man Pages: If you just need function signatures, return values, and arguments, these are all you need. I find the Linux ones to be very well written and useful (Proof: Look at my console:
man,man,man,man,man,make,man, ...)
- Beej 的网络编程指南：http: //beej.us/guide/bgnet/，如果除了细节之外还需要整体编程模型，这是非常好的
- 手册页：如果您只需要函数签名、返回值和参数，这些就是您所需要的。我发现 Linux 的写得很好而且很有用（证明：看看我的控制台：
man,man,man,man,man,make,man, ...）
Also, for making data network-sendable, if your data is JSON, you have no worries. Because JSON is just ASCII (or UTF-8), it can be sent raw over the network with only a length header. Unless your trying to send something complicated in binary, this should be perfect (if you need complicated in binary, either look at serialization or prepare for a lot of Segmentation Fault).
此外，为了使数据可通过网络发送，如果您的数据是 JSON，则无需担心。因为 JSON 只是 ASCII（或 UTF-8），所以它可以通过网络原始发送，只有一个长度标头。除非您尝试以二进制形式发送复杂的内容，否则这应该是完美的（如果您需要以二进制形式发送复杂内容，请查看序列化或准备大量Segmentation Fault）。
Also, you probably, if you go the socket path, want to use TCP. Although UDP will give you the one-way aspect, the fact that making it reliable is pitting your home-baked solution against the top-of-the-line TCP given by the Linux kernel, TCP is an obvious option.
此外，如果您使用套接字路径，您可能想要使用 TCP。尽管 UDP 会给您提供单向方面，但使其可靠的事实是将您自制的解决方案与 Linux 内核提供的顶级 TCP 进行较量，TCP 是一个明显的选择。
回答by damienh
Another recommendation is the distributed framework OpenCL. The document The OpenCL C++ Wrapper for APIprovides further information on the library. In particular, the API function cl::CommandQueuecould be of interest for creating queues on devices within a network setup.
另一个建议是分布式框架OpenCL。文档The OpenCL C++ Wrapper for API提供了有关该库的更多信息。特别是，API 函数cl::CommandQueue可能对在网络设置中的设备上创建队列感兴趣。
回答by Duck
RabbitMQ is just one implementation of AMQP. You might want to investigate Apache Qpidor other variants that might be more C/C++ friendly. There is a libamqpfor C though I have no first hand experience with it. I don't know exactly what your requirements are but AMQP, properly implemented, is industrial strength and should be orders of magnitude faster and more stable than anything you are going to build by hand in a short amount of time.
RabbitMQ 只是AMQP 的一种实现。您可能想研究Apache Qpid或其他可能对 C/C++ 更友好的变体。尽管我没有第一手经验，但有一个用于 C的libamqp。我不确切知道您的要求是什么，但是正确实施的 AMQP 具有工业实力，并且应该比您在短时间内手动构建的任何东西都快和稳定几个数量级。
回答by jbruni
Another messaging solution is ICE (http://www.zeroc.com/). It is multi-platform, multi-language. It uses more of an RPC approach.
另一个消息传递解决方案是 ICE ( http://www.zeroc.com/)。它是多平台、多语言的。它更多地使用了 RPC 方法。
