使用WCF实施低延迟实时财务数据馈送的最佳做法?

Sol*_*Sol 36 .net c# wcf

我有一个.NET服务需要向其客户提供实时财务数据.此Feed的输出速率可能会变得很快,我正在寻找最佳架构来实现这种低延迟和高性能的服务.

我正在考虑使用某种流数据提供程序,一种用于音频或视频,但发送Feed更新.

会对这个主题或任何现实世界的例子表示感谢

更新:

我不必使用WCF,这只是我的第一种方法,因为它是当前的技术.欢迎使用C#中的任何其他实现.

str*_*dim 38

完全披露:我在Informatica(原29West)工作,并且是负责其消息产品的工程团队.我有偏见.但是,我确实很好地掌握了金融市场中的低延迟消息传递.

如果您的消息速率约为60消息/秒.(正如Will Dean的回答评论中所说的那样),他们被送到了一个人类坐在它前面的图形用户界面,并以人性化的速度对市场做出反应,老实说这对软件来说无关紧要您从延迟角度使用.你甚至可以放弃使用WCF(虽然我仍然建议不要使用它;我们考虑过支持它一次并为它构建一个适配器原型并且延迟了一个数量级的延迟 - 我们决定不打扰它当时).

现在,Informatica的消息传递软件可以在一微秒内在同一台机器上的进程之间传递消息,如果你想购买一些带有内核旁路或InfiniBand设备的10 gig-E网卡,你可以在机器之间每秒传递数百万条消息具有一位数微秒的延迟.我们还将很快发布一个支持C/C++,Java和.NET的新数据序列化库,作为消息产品的一部分,在某些情况下实际上比协议缓冲区更快(虽然协议缓冲区被广泛使用,也是一个非常好的选择).我们的.NET和Java API都有一个名为"ZOD"的功能,用于"零对象传递",这是一种有趣的方式,说它们在消息传递期间不生成新对象,这意味着没有垃圾收集暂停和相关的延迟峰值/异常值.我们已经找到专门设计用于扇出高速骨干网流量慢的桌面应用程序,而不会减慢骨干或其他客户端其他产品称为UMDS.

我可以继续谈谈Informatica的消息软件有多么出色,我觉得值得一试,但这看起来像是一个直接的广告,而且我是工程师,而不是销售人员.所以这里有一些更一般的建议:

  • 如果你有很多客户端收到相同的数据,你会想要一些UDP多播的风格.您经常需要某种可靠的多播传输 - 众所周知(且免费)的可靠多播协议是PGM.Windows包含可在C#中使用的PGM实现; 如果您想尝试一下,我会向您推荐Mike Rettig 关于如何使用它的优秀博客文章.(我碰巧认识迈克 - 他是一个聪明的人.)协议选择是一个你得到你所支付的领域; Informatica的消息包括松散地基于PGM的可靠多播协议(我们的架构师设计了它很久以来共同编写了PGM RFC),但有很多重大改进.不过,普通的PGM可能适合您的需求.

  • 您希望使用无代理/无服务器架构.让应用程序与中间没有任何东西进行点对点通信.避免在消息路径(这通常意味着避免大多数JMS实现,避免几乎与名称为"排队"的地方,任何东西等)多余的啤酒花.

  • 请注意当一个客户端行为不当时系统的行为方式.一个人可以放慢消费者的速度吗?

  • 有许多操作系统调整和BIOS调整选项可以使任何类型的低延迟消息传递,自行开发或购买 - 例如中断合并,将NIC中断绑定到特定CPU核心,接收端扩展(这在历史上一直很糟糕)当在Windows上与UDP一起使用时,但将来会变得更好),禁用某些CPU电源状态等.

  • 抵制在.NET中使用内置对象序列化通过线路发送整个对象的诱惑 - 它比使用简单的二进制格式(如Protocol Buffers,或Informatica的序列化库,或您自己的二进制格式等)慢几个数量级. ).

如果您有任何更具体的问题或需要更多关于我的建议的详细信息,请告诉我们!


Wil*_*ean 6

"低延迟"有多低,"忙"有多忙?您需要了解您的目标是选择正确的方法.

我可以为您提供一些硬件,这些硬件可以响应100%的所有请求,例如20us,直到网络硬件的全部容量,但它根本不会使用WCF.

对于一个非常广泛的近似,我会说像WCF这样的东西是非常高级和权衡的易用性和抽象的程序员对性能(延迟/吞吐量)的好处.他们是否为您的应用程序交换太多需要实数.

广泛使用的最低延迟,最低开销的基于IP的协议是UDP - 这就是它用于DNS和NTP之类的原因.它在服务器上具有很高的可扩展性,因为服务器不需要保持任何状态,并且几乎可以在任何平台上实现它.但你确实需要考虑网络数据包而不是.NET对象.您是否也提供客户端软件?

  • 完全同意你的"宽泛近似".但UDP不适用于财务数据,因为松散数据是不可接受的.TCP应该没问题. (2认同)
  • 我认为很多这种超低延迟的财务数据只是最新的价格,所以它几乎是*可以丢失数据的典型例子,因为新的最新价格很快就会出现.但是,如果TCP连接保持打开状态,那么它的延迟时间不会超过UDP连接,尽管它对服务器而言更加昂贵. (2认同)
  • 我会从他对你的问题的评论中得到安德烈的第一个建议 - 假设"原始套接字"他的意思是"一个简单的TCP套接字",而不是一个真正的"原始套接字",这对我来说是裸IP.像协议缓冲器实现之一的快速序列化方案似乎是过度抽象和繁琐的字节翻转之间的一个很大的折衷.如果您打开TCP连接,则不应该对所需的性能有太大的麻烦.查看使用.NET套接字的各种异步选项,以避免每个客户端使用一个线程,这很少是一个很好的解决方案. (2认同)