这是我的情景： 在我的应用程序中，我有几个使用内部使用tcp套接字的Quickfix相互通信的进程。流程如下：
Process1发送quickfix messaage-＆gt;进程2在处理完消息后发送quickfix消息 过程1 - ＆gt; .....-＆gt;过程n
类似地，确认消息像
一样流动过程n-＆gt; ....-＆gt;过程1
现在，除最后一个进程（进程n）之外的所有这些进程都在同一台机器上。 我用Google搜索并发现tcp套接字是ipc机制中最慢的。
那么，有没有办法传输和接收快速修复消息（显然使用他们的api） 通过其他ipc机制。如果是，我可以通过在同一台机器上的所有进程之间使用该ipc机制来减少延迟。
但是，如果我这样做，这些机制是否保证像tcp套接字一样传输完整的消息呢？
答案 0 :(得分：0)
我认为您正在进行过早优化，我认为TCP不会成为您的性能瓶颈。您的本地LAN延迟将比外部FIX连接更快。根据经验，我认为性能问题源于您的应用程序的消息处理（可能是由于OnMessage()回调中的意外阻塞）而不是之后发生的IPC内容。
建议：使用抽象层接口编写您的通信组件，以便以后可以将TCP替换为其他内容（例如ActiveMQ，ZeroMQ，无论您考虑其他什么），如果您决定你可能需要它。
除此之外，只需专注于让您的系统正常工作。一旦你确定行为是正确的（希望通过测试来确认它们），那么你就可以开展工作了。 在进行任何优化之前衡量您的表现，然后在进行“改进”后再次进行衡量。不要相信你的直觉;得到数字。
答案 1 :(得分：0)
虽然听到有关此问题相关要求的更多详细信息会很好，但我建议您查看共享内存解决方案。我假设您正在使用交易匹配引擎在共置设施中运行服务器，并使用高速内核旁路通信进行外部通信。 TCP的一个问题是用户/内核空间转换。我建议考虑IPC的用户空间共享内存，并使用繁忙的轮询技术进行同步，而不是使用可能还涉及内核转换的同步机制。