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

Question

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

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

对此主题或任何现实世界的例子表示赞赏

更新：

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

Answer 1

完全披露：我在Informatica（前29West）工作，并且是负责their messaging products的工程团队。我有偏见。但是，我对金融市场中的低延迟消息传递有很好的把握。

如果您的邮件速率约为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的excellent blog post如何使用它。 （我碰巧认识迈克 - 他是一个聪明的人。）协议选择是一个你得到你所付出的领域; Informatica的消息包括松散地基于PGM的可靠多播协议（我们的架构师设计它很久以来共同编写了PGM RFC），但有很多重大改进。然而，普通的PGM可能适合你的需要。

• 您希望使用无代理/无服务器架构。让应用程序与中间没有任何东西进行点对点通信。避免在消息路径中添加额外的跃点（这通常意味着避免大多数JMS实现，避免在名称中使用“queue”等几乎所有内容，等等。）

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

• 有很多操作系统调整和BIOS调整选项可以使任何类型的低延迟消息传递，自行开发或购买 - 例如interrupt coalescing，将NIC中断绑定到特定CPU核心，接收-side scaling（在Windows上与UDP一起使用时一直很糟糕，但将来会变得更好），禁用某些CPU电源状态等。

• 抵制在.NET中使用内置对象序列化通过网络发送整个对象的诱惑 - 它比使用简单的二进制格式（如Protocol Buffers或Informatica的序列化库，或者你自己的二进制格式等。）。

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

Answer 2

'低延迟'有多低，“忙”有多忙？你需要知道你的目标是选择正确的方法。

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

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

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

Answer 3

实时财务数据？永远不要依赖WCF。相反，与其他行业一起使用。即纳斯达克使用Real-Time Innovations - Data Distribution Service向用户提供实时股票报价。它们为通信库提供了C / C ++ / C＃api，它非常易于设置和使用（与WCF相比）。

通常，这种实时数据馈送使用publish/subscribe paradigm，这有助于确保以最小的开销进行通信。这种方法是面向消息的中间件的主要思想，它正是金融服务用于实时的东西。

在侧节点上，您可以使用RTI-DDS库提供实时音频 - 视频数据包，据我所知，像MQ-9这样的无人驾驶飞行器再次使用此库来提供实时视频和视频。地面控制站的地理位置信息。

还有免费的数据发布服务库，但我没有经验。你只需要谷歌吧。

编辑：我目前正在制作一些HMI（人机界面）软件原型，该软件使用上述RTI-DDS库以及另外两个具有此类面向消息的体系结构的库，这些库确实可以运行到现在为我所有的实时通讯需求。这是一个演示：http://epics.codeplex.com/（它将用于远程控制我们全新的核研究设施中的设备）

Answer 4

您制作的假设和功能越多，制作系统的速度就越快。您尝试制作的东西越强大，越灵活，您的表现就会越多。我会建议一些必备的基本要点：

1. 二进制数据序列化格式。 不要使用XML或任何其他人 传递你的可读方法 数据。
2. 足够强大的数据 它可以的序列化格式 支持跨架构， 跨语言端点。 BER来了 记住 - C# seems to have support
3. 具有的传输协议     保证交付和数据     完整性。如果有任何类型的     财务算法将使用     这个数据，甚至缺少一个滴答     可能意味着之间的差异     并触发或丢失订单     出价格。即使你是     要汇总你的汇率     服务器你仍然想要控制     如何呈现信息     你的客户。 TCP适用于分布式系统。但是，如果您的客户端与服务器位于同一台计算机上，则可以有更快的替代方案。 UDP甚至不会收到订单，这可能会有问题（尽管不是不可克服的）。

关于内部处理：

1. 避免使用字符串和其他类 增加显着的开销 任务。使用基本字符数组 代替。我不确定有什么选择 你有C＃或者你有 轻量级替代品如果是这样，请使用 他们。这也适用于数据结构。
2. 注意双重/浮动比较错误。使用仅检查必要精度级别的比较。如果可能的话，在内部将所有内容转换为整数，并提供足够的元数据以在另一端转换回来。
3. 在C ++中使用与池化分配器类似的东西。我缺乏对C＃的了解使我无法更具体。 C＃可能不是你最好的选择。最重要的是，你将要创建并销毁大量的tick对象，并且没有理由每次都要求操作系统获取内存。
4. 只发送增量，不发送客户已有的信息。这假设您正在使用保证交付的运输。如果不是，你可能会长时间显示陈旧数据。

Answer 5

这可能是有趣的，虽然它特定于游戏... Lowest Latency small size data Internet transfer protocol? c#

以下是UDP连接http://www.winsocketdotnetworkprogramming.com/clientserversocketnetworkcommunication8r.html

的教程

关于UDP的另一篇文章 http://msdn.microsoft.com/en-us/magazine/cc163648.aspx

Answer 6

您具体询问“低延迟用户Feed”。对于“仅限馈送”（特别是如果它不产生收入），您真正想要的是低延迟，用户可以等待一秒;这不是低延迟。

如果您想要快速交易，那么您需要从交易所（或附近的光纤链路）物理移动到街道。接下来你需要'换卡';以太网卡是“智能”的，并提供“交易公式”，对网卡进行编程，根据收到的数据进行预编程交易（不会破坏您的计算机）。

请参阅：http://intelligenttradingtechnology.com/article/groundbreaking-results-high-performance-trading-fpga-and-x86-technologies

学会操纵环境会比重新发明轮子更能吸引你。

超低延迟是昂贵的，但数十亿人受到威胁;你的赌注（并追求更低的延迟）受到$。

的限制

Answer 7

过去我曾使用过Tibco rv或原始套接字来预测流量价格/费率。在这种情况下，通常是客户端（或实际上是用户）是限制因素（因为用户只能处理很多更新），因此这是一个“丢失”数据的示例。在这种情况下，客户端服务代理可用于限制更新。

如果系统用于自动交易或HFT，那么29West LatencyBuster等产品已被证明效果良好，并提供有保证的信息。