使用WCF实现低延迟实时财务数据提要的最佳实践

全面披露:我在Informatica(前身为29West)工作，是负责他们的消息传递产品的工程团队的一员。我有偏见。然而，我确实对金融市场中的低延迟消息传递有很好的把握。

如果你的消息速率约为60条消息/秒。(就像Will Dean回答的评论中所说的那样)，并且它们被传送到GUI中，而一个人坐在它的前面，以人类的速度对市场做出反应，老实说，从延迟的角度来看，你使用什么软件并不重要。您甚至可以使用WCF(尽管我仍然不建议使用它;我们曾经考虑过支持它，并为它制作了一个适配器原型，但它使延迟增加了一个数量级——我们当时决定不为此烦恼)。

现在，Informatica的消息传递软件可以在同一台机器上的进程之间传递消息，时间远低于1微秒，如果您想购买一些带有内核旁路或InfiniBand设备的10 gb - e网卡，您可以在机器之间传递每秒数百万的消息，延迟时间为一位数微秒。我们还将很快发布一个新的数据序列化库，它支持C/c++、Java和。net，作为消息传递产品的一部分，在某些情况下，它实际上比协议缓冲区更快(尽管协议缓冲区被广泛使用，也是一个非常好的选择)。我们的。net和Java api都有一个名为"ZOD"的特性，即"零对象交付"，这是一种有趣的说法，它们在消息交付期间不生成新对象，这意味着没有垃圾收集暂停。相关的延迟峰值/异常值。我们还有另一款名为UMDS的产品，专门设计用于将高速骨干流量分散到较慢的桌面应用程序，而不会减慢骨干或其他客户端。

我可以不停地说Informatica的通讯软件有多棒，我确实认为它值得一试，但这已经看起来像一个直接的广告了，而且我是工程师，不是销售人员。所以这里有一些更一般的建议:

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

• 您想要使用无代理/无服务器架构。让应用程序进行点对点通信，中间没有任何东西。避免消息路径上的额外跳转(这通常意味着避免大多数JMS实现，避免几乎任何在名称中带有"queue"的东西，等等)。

• 注意当单个客户端行为不当时系统的行为。一个慢速的消费者能拖慢其他所有人吗?

• 有很多操作系统调优和BIOS调优选项可以使任何低延迟的消息传递受益，无论是本地的还是购买的——比如中断合并，将网卡中断绑定到特定的CPU核心，接收端扩展(在Windows上使用UDP时历史上很糟糕，但将来应该会变得更好)，禁用某些CPU电源状态，等等。

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

如果您有更具体的问题或需要更多关于我的建议的细节，请告诉我!

"低延迟"有多低，"高延迟"有多忙?你需要知道你的目标是什么，以选择正确的方法。

我可以为您提供一些硬件，这些硬件可以在20秒内响应所有请求，直到您的网络硬件的全部容量，但它根本不会使用太多WCF。

大致说来，我想说像WCF这样的东西是非常高级的，并且在性能(延迟/吞吐量)方面权衡了易用性和为程序员的利益而抽象。他们是否为您的应用程序付出了太多代价，需要实际的数字。

广泛使用的最低延迟，最低开销的基于ip的协议是UDP -这就是为什么它被用于像DNS和NTP这样的东西。它在服务器上具有很强的可扩展性，因为服务器不需要保留任何状态，而且在几乎任何平台上实现它都非常简单。但是您确实需要考虑网络数据包而不是。net对象。你们也提供客户端软件吗?

实时财务数据?永远不要依赖WCF。相反，借鉴其他行业的做法。例如，纳斯达克使用实时创新-数据分发服务向用户提供实时股票报价。他们为他们的通信库提供了C/c++/c# api，这非常容易设置和使用(与WCF相比)。

通常，这种类型的实时数据源使用发布/订阅范式，这有助于确保以最小的开销进行通信。这种方法是面向消息的中间件的主要思想，它正是金融服务用于实时内容的方法。

在侧节点上，您可以使用RTI-DDS库发送实时音视频数据包，据我所知，MQ-9等无人机也使用该库发送实时视频&;向地面控制站提供地理位置信息。

也有免费的数据分发服务库，但我没有经验。你只需要谷歌一下。

Edit:我目前正在制作一些HMI(人机界面)软件的原型，该软件使用前面提到的RTI-DDS库以及其他两个具有此类面向消息架构的库，这些库到目前为止确实可以满足我所有的实时通信需求。这里有一个演示:http://epics.codeplex.com/(它将用于远程控制我们全新的核研究设施的设备)

你做的假设和特征越多，你可以使你的系统越快。你想做的事情越健壮、越灵活，你的表现就越糟糕。我想建议一些基本的必备事项:

1. 二进制数据序列化格式。不要使用XML或任何其他人的可读方法数据。
2. 一个足够健壮的数据序列化格式支持cross-architecture,跨语言的端点。数量是c#似乎支持
3. 具有的传输协议保证交付和数据的完整性。如果有任何类型的金融算法将使用这个数据，甚至少了一个刻度可能意味着两者之间的区别命令被触发或丢失出了价。即使你是要在你的您仍想控制的服务器信息是如何呈现的你的客户。TCP适用于分布式系统。但是，如果您的客户端与服务器位于同一台机器上，则有更快的替代方案。UDP甚至不能保证订单，这可能会有问题(尽管不是不可克服)。

关于内部处理:

1. 避免字符串和其他类给simple增加大量开销任务。使用基本字符数组代替。我不知道有什么选择如果你有的话轻量级替代方案。如果是，使用他们。这也适用于数据结构。
2. 注意double/float比较错误。使用只检查必要精度级别的比较。如果可能的话，将所有内容在内部转换为整数，并提供足够的元数据以在另一端转换回来。
3. 在c++中使用类似于池分配器的东西。由于缺乏c#知识，我无法更具体地说明。同样，c#可能不是您的最佳选择。底线是，你将创建和销毁大量的tick对象，没有理由每次都向操作系统请求内存。
4. 只发送delta，不要发送客户已经拥有的信息。这假定您正在使用具有保证交付的传输。如果不这样做，你可能会在很长一段时间内显示过时的数据。

这可能是有趣的，尽管它是特定于游戏…最低延迟小尺寸数据互联网传输协议?c#

这是一个关于UDP连接的教程http://www.winsocketdotnetworkprogramming.com/clientserversocketnetworkcommunication8r.html

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

你特别问了关于"低延迟用户提要"的问题。你真正想要的低延迟是什么，对于"Feed Only"(特别是如果它不产生收入)，用户是否可以等待一秒钟;这不是低延迟。

如果您想快速交易，那么您需要从交易所穿过街道(或附近有光链路)。接下来你需要"交易卡";以太网卡是"智能的"，并被输入"交易公式"，该公式编程网卡根据收到的数据进行预先编程的交易(不打扰您的计算机)。

见:http://intelligenttradingtechnology.com/article/groundbreaking-results-high-performance-trading-fpga-and-x86-technologies

学会操纵环境会给你带来比重新发明轮子更多的东西。

超低延迟是昂贵的，但数十亿美元的风险;您的赌注(以及对更低延迟的追求)可能会受到$的限制。

在过去，我使用Tibco rv或原始套接字来进行流媒体价格/费率，这些地方需要高频更新。在这种情况下，通常是客户端(或者实际上是用户)受到限制(因为用户只能处理这么多更新)，因此这是一个可能"丢失"数据的例子。在这种情况下，可以使用客户端服务代理来限制更新。

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