进程间通信是否可以与进程内事件一样快(使用 wcf 和 c#)
本文关键字：一样 是否 使用 wcf 进程 进程间通信 事件 | 更新日期: 2023-09-27 17:55:33
我有一个对传入事件流（CEP 引擎）执行分析的应用程序。此流可以来自不同的来源（数据库、网络等）。
为了高效解耦，我希望此服务使用 wcf 公开命名管道，并允许其他应用程序从源读取数据并将其馈送到服务中。
因此，一个进程负责获取和处理传入的数据，而另一个进程负责分析数据，使用带有命名管道绑定的 wcf 连接两者。它们都将部署在同一台计算机上。
问题是，如果我只是将两个服务耦合到一个进程中并使用常规事件，我会注意到中间使用 wcf 的吞吐量较低吗？
不，在现代主流操作系统中，IPC 永远不会，也永远不会像进程内事件一样快。原因是与激活不同进程相关的上下文切换开销。即使对于多核系统，其中不同的进程在不同的内核上运行，尽管它们各自独立运行（因此激活一个进程与另一个进程没有相关的成本 - 它们始终处于活动状态），跨进程的通信仍然需要跨越安全边界，命中网络堆栈（即使使用管道）等等。 如果本地函数调用大约需要 1000 个 CPU 周期来调用，则 IPC 将是数百万个。
因此，IPC 将比进程内通信慢。 这在你的情况下是否真的重要，是一个不同的问题。例如，假设您有一个需要运行 2 小时的蒙特卡罗模拟的操作。在这种情况下，调用操作需要 1 毫秒还是 1000 毫秒真的无关紧要。
通常，通信性能不是您想要优化的。即使性能很重要，关注性能的一个小方面 - 比方说，是使用 IPC 还是本地函数调用 - 可能是错误的处理方式。
我假设"CEP"指的是"复杂事件处理"，这意味着高吞吐量、高容量的处理。所以我明白性能对你很重要。
但是，要实现真正的可扩展性和可靠性，您不能简单地优化进程内事件;你将需要依赖多台计算机并横向扩展。这将意味着某种程度的IPC，不管怎样。在较小的规模（事件）中提高效率显然很重要，但整体高端性能将在很大程度上受到你选择横向扩展的体系结构的限制。
WCF 之所以不错，是因为它允许将构建基块从本地计算机移动到远程计算机，并且由于通道堆栈，您可以以模块化方式添加通信服务。
这对你是否重要，由你决定。