使用管道、共享内存、消息队列等的QuickFix

Question

这是我的场景:在我的应用程序中，我有几个进程使用Quickfix相互通信，在内部使用tcp sockets.the流是这样的：

Process1发送quickfix消息->进程2在处理来自进程1->的消息后发送quickfix消息.....->进程n

类似地，确认消息流如下，

进程n->...->进程1

现在，除了最后一个进程(进程n)之外，所有这些进程都在同一台计算机上。我用谷歌搜索了一下，发现tcp套接字是最慢的ipc机制。

那么，有没有办法通过其他ipc机制发送和接收快速修复消息(显然是使用它们的apis)。如果是，那么我可以通过在同一台机器上的所有进程之间使用该ipc机制来减少延迟。

然而，如果我这样做了，这些机制是否像tcp套接字那样保证了完整消息的传输？

Answer 1

我认为您过早地进行了优化，并且我认为TCP不会成为您的性能瓶颈。您的本地LAN延迟将比外部修复连接的延迟更快。根据经验，我认为性能问题应该源于应用程序的消息处理(可能是由于OnMessage()回调中的意外阻塞)，而不是之后的进程间通信问题。

TCP建议：编写带有抽象层接口的通信组件，这样以后如果您决定可能需要的话，就可以用其他东西(例如ActiveMQ、ZeroMQ，或者其他您可能考虑的东西)来替换它。

除此之外，只要专注于让你的系统正常工作即可。一旦您确定行为是正确的(希望通过测试来确认它们)，那么您就可以对性能进行改进。在进行任何优化之前测量您的性能，然后在您进行“改进”之后再次测量。不要相信你的直觉；要有数字。

Answer 2

虽然听到与这个问题相关的需求的更多细节将是一件好事，但我建议您考虑共享内存解决方案。我假设您正在使用交易匹配引擎的托管设施中运行服务器，并使用高速内核旁路通信进行外部通信。TCP的问题之一是用户/内核空间的转换。我建议考虑将用户空间共享内存用于IPC，并使用繁忙的轮询技术进行同步，而不是使用可能涉及内核转换的同步机制。