最佳实践实现使用WCF一个低延迟的实时财务数据源？ [英] Best practice to implement a low latency live financial data feed using WCF?

问题描述

我有需要实时的财务数据饲料给客户一个.NET服务。输出速率为这个饲料可能会紧张，我找最好的架构来实现这种类型的低延迟和高性能的服务。

I have a .NET service which need to feed live financial data to its clients. The output rate for this feed might get intense and I am looking for the best architecture to implement this type of service with low latency and high performance.

我想使用某种类型的流数据提供者，一个用于音频或视频的，但送料的更新替代。

I was thinking of using some kind of a stream data provider, one that is used for audio or video, but send feed updates instead.

请问AP preciate关于这个问题的任何想法，或任何真实世界的例子

Would appreciate any thought on this subject, or any real world examples

更新：

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

I don't have to use WCF, that was only my first approach since it is the current technology. Any other implementation in C# is welcome.

推荐答案

全面披露：我对Informatica的（以前29West公司）工作，我的工程队负责的their消息产品的。我有偏见。我这样做，不过，有一个pretty的把握好低延迟消息在金融市场。

Full Disclosure: I work for Informatica (formerly 29West) and am on the engineering team responsible for their messaging products. I am biased. I do, however, have a pretty good grasp of low-latency messaging in the financial market.

如果你的消息率约为60消息/秒。 （如在威尔院长的回答评论说），他们正在被传递到一个GUI与人坐在它前面，反应了市场在人类速度，诚实无所谓了一大堆什么软件您由于响应时间使用。你甚至可以得到与使用WCF（虽然我还是会建议反对，我们认为支持它曾经和原型的适配器，并将其臃肿的潜伏期由一个数量级 - 我们决定不打扰它在的时间）。

If you message rates are about 60 messages/sec. (as stated in a comment on Will Dean's answer), and they're being delivered to a GUI with a human sitting in front of it and reacting to the market at human-speed, it honestly doesn't matter a whole lot what software you use from a latency perspective. You might even be able to get away with using WCF (though I'd still recommend against it; we considered supporting it once and prototyped an adapter for it and it bloated latencies up by an order of magnitude - we decided not to bother with it at the time).

现在，Informatica的通讯软件的可以的进程间传递消息在同一台机器上远低于一微秒，如果你想购买一些不错的万兆-E网卡内核旁路或InfiniBand的齿轮，你可以通过的每秒百万次信息有延迟的个位数微秒机器之间的的。我们也将很快被释放了在C / C支持的新的数据序列化库++，Java和.NET的通讯产品，在某些情况下，实际上是快于Protocol Buffers的（虽然Protocol Buffers的广泛使用，也有一部分非常不错的选择）。我们的.NET和Java API都有一个名为ZOD的零对象交货，这是说，他们产生的信息传递过程中没有新的对象，这意味着没有垃圾回收还挺有趣的方式功能暂停＆放大器;相关的延迟高峰/异常值。我们已经得到了多数民众赞成专门用来扇出高速骨干网流量较慢的桌面应用程序，而不会减慢骨干或其他客户端其他产品称为UMDS。

Now, Informatica's messaging software can pass messages between processes on the same machine in well under a microsecond, and if you want to buy some nice 10 gig-E NICs with kernel bypass or InfiniBand gear, you can pass millions of messages per second between machines with single-digit microseconds of latency. We'll also soon be releasing a new data serialization library that's supported in C/C++, Java, and .NET as part of the messaging product that in some cases is actually faster than Protocol Buffers (although Protocol Buffers are widely used and also a very good choice). Our .NET and Java APIs both have a feature called "ZOD" for "Zero Object Delivery", which is a kinda funny way of saying they generate no new objects during message delivery, meaning no garbage collection pauses & associated latency spikes/outliers. We've got another product called UMDS that's specifically designed to fan out high-speed backbone traffic to slower desktop apps without slowing down the backbone or other clients.

我可以继续下去了巨大Informatica的通讯软件是如何，我也认为这是值得一试，不过这已经看起来像一个直线式广告，而我是一个工程师，而不是销售人员。因此，这里的几件更普遍的建议是：

I could go on and on about how great Informatica's messaging software is and I do think it's worth checking out, but this already looks like a straight-up ad, and I'm an engineer, not a sales person. So here's a few pieces of more general advice:

• 如果你有大量接收相同数据的客户端，你会想UDP组播一番风味。你会经常需要某种形式的可靠的多播传输 - 著名的（和免费的）可靠组播协议PGM。 Windows包含PGM的实现，这是在C＃中使用的;我将把你迈克瑞特格的优秀的博客帖子如何使用它，如果你想尝试一下。 （我碰巧知道迈克 - 他是一个聪明的家伙。）协议的选择是在你得到你所支付的地区; Informatica的消息包括松散的基础关闭PGM（我们的设计师是谁设计它合写的PGM RFC半晌后）的可靠组播协议，但有很多重大的改进。普通PGM可能是罚款，你需要什么，但。

• If you have a lot of clients receiving the same data, you'll want some flavor of UDP multicast. You'll often want a reliable multicast transport of some kind - the well-known (and free) reliable multicast protocol is PGM. Windows includes an implementation of PGM that's usable in C#; I'll refer you to Mike Rettig's excellent blog post on how to use it if you want to try it out. (I happen to know Mike - he's a smart guy.) Protocol choice is an area in which you get what you pay for; Informatica's messaging includes a reliable multicast protocol loosely based off of PGM (our architect who designed it co-wrote the PGM RFC a long while back), but with a lot of major improvements. Plain PGM might be fine for what you need, though.

您想要去一个brokerless /无服务器架构。有应用程序进行通信的对等什么也没有在中间。避免在消息路​​径额外跳（这通常意味着避免大多数的JMS实现，切忌差不多名称中排队的地方，等等。任何东西）。

You want to go with a brokerless/serverless architecture. Have the apps communicate peer-to-peer with nothing in the middle. Avoid extra hops in the message path (which usually means avoid most JMS implementations, avoid almost anything with "queue" in the name somewhere, etc.).

要考虑到如何当一个单独的客户端行为不端系统的行为。一种缓消费者可以减缓其他人？

Be mindful of how your system behaves when one individual client misbehaves. Can one slow consumer slow down everyone else?

有很多操作系统优化和BIOS调节选项，可以造福任何购买形式的低延迟消息，自产自销或 - 比如<一href="http://29west.word$p$pss.com/2009/06/10/how-does-interrupt-coalescing-affect-low-latency-high-performance-messaging/">interrupt凝聚，搭售网卡中断到一个特定的CPU核心，接收端缩放（这在历史上一直是可怕的使用UDP在Windows上使用的时候，却应该得到在将来更好），禁用某些CPU电源状态等

There are a lot of OS tuning and BIOS tuning options that can benefit any sort of low-latency messaging, homegrown or bought - things like interrupt coalescing, tying NIC interrupts to a particular CPU core, receive-side scaling (which has historically been terrible when used with UDP on Windows, but should be getting much better in the future), disabling certain CPU power states, etc.

抵制诱惑，使用内置的对象序列化在.NET中发送过来的电线全对象 - 这是数量级比使用简单的二进制格式（如协议缓冲区，或Informatica的序列化库，或更慢的订单自己的二进制格式，等等）。

Resist the temptation to use built-in object serialization in .NET to send whole objects over the wire - it is orders of magnitude slower than using a simple binary format (like Protocol Buffers, or Informatica's serialization library, or your own binary format, etc.).

如果您有更具体的问题或者需要我的任何咨询更详细的，只是让我知道！

If you have more specific questions or need more detail on any of my advice, just let me know!

这篇关于最佳实践实现使用WCF一个低延迟的实时财务数据源？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！