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