有谁知道同一台计算机上的应用程序之间的本地消息传递的快速总线?
我正在寻找一种可由在同一台计算机(不同应用程序域和进程的混合)上运行的.NET 应用程序使用的发布/订阅机制。我真的宁愿避免运行单独的服务或任何需要太多配置的服务。显然我也想将内存和CPU负载保持在最低限度。
具体来说,我想向同一主机上的订阅者广播大量小消息。所以我想要一个总线(例如MSMQ或NServiceBus) - 但我不想要完整网络支持的开销(它只需要本地命名管道)或企业总线的成本和复杂性。
I'm looking for a pub/sub mechanism that can be used by .NET applications running on the same machine (a mixture of different app domains and processes). I'd really rather avoid having to run a separate service or anything that requires too much configuration. Obviously I'd like to keep the memory and cpu load to a minimum too.
Specifically I want to broadcast high volumes of small messages to subscribers on the same host. So I want a bus (e.g. MSMQ or NServiceBus) - but I don't want the overhead of full network support (it only needs local named pipes) or the cost and complexity of an enterprise bus.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
命名管道是进行本地进程交互的最快方式。
参考:
NamedPipeServerStream
< br>NamedPipeClientStream
< br>选择传输
重要阅读:
不要陷入僵局
Named pipes is the fastest way to do local process interaction.
Reference:
NamedPipeServerStream
NamedPipeClientStream
Choosing a transport
Important reading:
Don't get in a deadlock
如果您只想从一个进程向另一个进程发送信号以表明部分工作已完成,那么最轻量级的解决方案可能是 互斥体。
If you just want to send a signal from one process to other that some portion of work is done, the most lightweight solution could be a mutex.
我猜想,如果配置正确,MSMQ + NServiceBus 将能够在单台机器上实现您所需的吞吐量。有一个 [Express] 属性会导致您的消息不写入磁盘。如果性能足够,那么使用这样的高级框架比自行构建要好得多。
I would guess that configured properly, MSMQ + NServiceBus would be able to achieve your desired throughput on a single machine. There is an [Express] attribute that will cause your messages to not be written to disk. If performance is adequate, you are much better off using a high-level framework like this than rolling your own.
全部在 Windows 上
All on Windows
这不是我的最终解决方案,但提出的一个解决方案是 0MQ 它提供了可靠的 pub/sub 模式,对配置和基础设施的要求相对较低。缺点是它的级别相对较低(.NET API 是本机 C 代码的包装器)——因此我需要实现所有序列化等。
当我有时间进行实验并得出结论时,我会回复。
This isn't my definitive solution, but one solution that has come up is 0MQ which offers a reliable pub/sub mode and has relatively low requirements for configuration and infrastructure. The downside is that it is relatively low level (the .NET API is a wrapper around the native C code) - so I will need to implement all the serialisation and so on.
I'll post back when I've had time to experiment and come to a conclusion.