我有一个 .NET 服务，需要向其客户提供实时财务数据。此提要的输出速率可能会变得很高，我正在寻找最佳架构来实现此类低延迟和高性能的服务。
我正在考虑使用某种流数据提供程序，用于音频或视频，但发送提要更新。
将不胜感激关于这个主题的任何想法，或任何现实世界的例子
Update:
我不必使用 WCF，这只是我的第一种方法，因为它是当前的技术。欢迎任何其他 C# 实现。
全面披露：我在 Informatica（前身为 29West）工作，是负责的工程团队成员他们的消息传递产品 http://www.informatica.com/products_services/ultra_messaging/Pages/index.aspx。我有偏见。不过，我确实非常了解金融市场中的低延迟消息传递。
如果您的消息速率约为 60 条消息/秒。 （正如对威尔·迪恩的回答的评论中所述），并且它们被传递到一个图形用户界面，一个人坐在它前面并以人类的速度对市场做出反应，老实说，什么软件并不重要您从延迟的角度使用。您甚至可以不用使用 WCF（尽管我仍然建议不要使用它；我们曾经考虑过支持它并为其设计了一个适配器原型，但它使延迟增加了一个数量级 - 我们决定不再理会它）当时）。
现在，Informatica 的消息传递软件can在同一台机器上的进程之间在一微秒内传递消息，如果您想购买一些带有内核旁路或 InfiniBand 设备的漂亮 10 gig-E NIC，您可以通过millions具有个位数微秒延迟的机器之间每秒的消息数。我们还将很快发布一个新的数据序列化库，它支持 C/C++、Java 和 .NET，作为消息传递产品的一部分，在某些情况下实际上比 Protocol Buffers 更快（尽管 Protocol Buffers 被广泛使用，并且也是一种非常好的选择）。我们的 .NET 和 Java API 都有一个名为“ZOD”的功能，即“零对象传递”，这是一种有趣的方式，表示它们在消息传递期间不会生成新对象，这意味着不会出现垃圾收集暂停和相关的延迟峰值/异常值。我们还有另一种名为 UMDS 的产品，专门设计用于将高速骨干流量分散到速度较慢的桌面应用程序，而不会减慢骨干或其他客户端的速度。
我可以继续谈论 Informatica 的消息传递软件有多棒，我确实认为它值得一试，但这看起来已经像是一个直截了当的广告，而且我是一名工程师，而不是销售人员。所以这里有一些更一般的建议：
如果您有很多客户端接收相同的数据，您将需要某种 UDP 多播。您经常需要某种可靠的多播传输 - 众所周知的（且免费的）可靠多播协议是 PGM。 Windows 包含可在 C# 中使用的 PGM 实现；我会向您推荐 Mike Rettig 的优秀的博客文章 http://jroller.com/mrettig/entry/pgm_subscriber_in_c如果您想尝试一下如何使用它。 （我碰巧认识迈克——他是个聪明人。）协议选择是一个你付出什么就能得到什么的领域； Informatica 的消息传递包括松散地基于 PGM 的可靠多播协议（设计该协议的架构师很久以前与他人共同编写了 PGM RFC），但进行了许多重大改进。不过，普通 PGM 可能就可以满足您的需求。
您想要采用无代理/无服务器架构。让应用程序进行点对点通信，中间没有任何中间环节。避免消息路径中的额外跃点（这通常意味着避免大多数 JMS 实现，避免几乎任何名称中带有“队列”的内容，等等）。
当某个客户端行为不当时，请注意您的系统的行为方式。一个缓慢的消费者会拖慢其他所有人的速度吗？
有很多操作系统调整和 BIOS 调整选项可以使任何类型的低延迟消息传递（无论是自制的还是购买的）受益 - 例如中断合并 http://29west.wordpress.com/2009/06/10/how-does-interrupt-coalescing-affect-low-latency-high-performance-messaging/、将 NIC 中断绑定到特定的 CPU 核心、接收端扩展（过去在 Windows 上与 UDP 一起使用时非常糟糕，但将来应该会变得更好）、禁用某些 CPU 电源状态等。
抵制使用 .NET 中内置对象序列化通过网络发送整个对象的诱惑 - 它比使用简单的二进制格式（如 Protocol Buffers、Informatica 的序列化库或您自己的二进制格式等）慢几个数量级.)。
如果您有更具体的问题或需要有关我的建议的更多详细信息，请告诉我！
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
