Наилучшая практика для реализации потока финансовых данных с низкой задержкой с использованием WCF? - PullRequest
36 голосов
/ 22 апреля 2011

У меня есть служба .NET, которая должна предоставлять финансовые данные в реальном времени своим клиентам.Скорость вывода для этого канала может быть интенсивной, и я ищу лучшую архитектуру для реализации этого типа сервиса с низкой задержкой и высокой производительностью.

Я думал об использовании какого-либо поставщика потоковых данных, одинкоторый используется для аудио или видео, но вместо этого отправляет обновления фида.

Буду признателен за любые мысли на эту тему или примеры из реальной жизни

Обновление:

Мне не нужно использовать WCF, это был только мой первый подход, так как это текущая технология.Любая другая реализация в C # приветствуется.

Ответы [ 7 ]

38 голосов
/ 03 мая 2011

Полное раскрытие информации: я работаю в Informatica (ранее 29West) и являюсь членом инженерной группы, ответственной за их продукты для обмена сообщениями .Я предвзятый.Я, однако, довольно хорошо разбираюсь в сообщениях с малой задержкой на финансовом рынке.

Если скорость передачи сообщений составляет около 60 сообщений в секунду.(как указано в комментарии к ответу Уилла Дина), и когда они доставляются в графический интерфейс с человеком, сидящим перед ним и реагирующим на рынок с человеческой скоростью, честно говоря, не имеет большого значения, какое программное обеспечениевы используете с точки зрения латентности.Возможно, вам даже удастся обойтись без использования WCF (хотя я все же рекомендовал бы против него; мы рассмотрели возможность его поддержки один раз и создали для него прототип адаптера, и это увеличило задержки на порядок - мы решили не беспокоиться об этомв то время).

Теперь программное обеспечение Informatica для обмена сообщениями может передавать сообщения между процессами на одном компьютере за микросекунду, и если вы хотите купить несколько замечательных сетевых адаптеров на 10 гигабит Eс помощью обхода ядра или механизма InfiniBand вы можете передавать миллионов сообщений в секунду между машинами с задержкой в ​​одну цифру микросекунды.Мы также скоро выпустим новую библиотеку сериализации данных, которая поддерживается в C / C ++, Java и .NET, как часть продукта обмена сообщениями, которая в некоторых случаях на самом деле быстрее, чем буферы протокола (хотя буферы протокола широко используются, а такжеочень хороший выбор).Наши API .NET и Java имеют функцию «ZOD» для «Zero Object Delivery», что является довольно забавным способом сказать, что они не генерируют новые объекты во время доставки сообщений, что означает отсутствие пауз сборки мусора и связанных всплесков / выбросов задержек.У нас есть еще один продукт под названием UMDS, который специально предназначен для разветвления высокоскоростного магистрального трафика для замедления настольных приложений без замедления магистрали или других клиентов.

Я мог бы продолжить и рассказать о том, насколько великолепно программное обеспечение Informatica для обмена сообщениями.и я думаю, что стоит проверить, но это уже выглядит как обычная реклама, и я инженер, а не продавец.Итак, вот несколько общих советов:

  • Если у вас много клиентов, получающих одни и те же данные, вам понадобится несколько вариантов многоадресной рассылки UDP.Вам часто понадобится надежный многоадресный транспорт какого-либо типа - известный (и бесплатный) надежный протокол многоадресной передачи - PGM.Windows включает реализацию PGM, которую можно использовать в C #;Я отсылаю вас к отличному сообщению Майка Реттига в блоге о том, как его использовать, если вы хотите попробовать его.(Я знаю, Майк - он умный парень.) Выбор протокола - это область, в которой вы получаете то, за что платите;Обмен сообщениями в Informatica включает в себя надежный многоадресный протокол, слабо основанный на PGM (наш архитектор разработал его совместно с RFM PGM уже давно), но с большим количеством значительных улучшений.Обычный PGM может подойти для того, что вам нужно.

  • Вы хотите использовать архитектуру без посредников / без серверов.Сделайте так, чтобы приложения общались однорангово, ни с чем в середине.Избегайте лишних прыжков в пути сообщения (что обычно означает, что нужно избегать большинства реализаций JMS, избегать чего-либо с «очередью» в имени где-либо и т. Д.).

  • Помните о том, как работает ваша системаведет себя, когда один отдельный клиент ведет себя плохо.Может ли один медленный потребитель замедлить всех остальных?

  • Существует множество параметров настройки ОС и параметров BIOS, которые могут быть полезны для любого типа сообщений с низкой задержкой, отечественных или купленных - например, объединение прерываний , привязка прерываний NIC к конкретному ядру ЦП, масштабирование на стороне приема (что исторически было ужасно при использовании с UDP в Windows, но должно стать намного лучше в будущем), отключение определенных состояний питания ЦПи т. д.

  • Не поддавайтесь искушению использовать встроенную сериализацию объектов в .NET для отправки целых объектов по проводам - ​​это на несколько порядков медленнее, чем при использовании простого двоичного формата (например, буферов протокола, библиотеки сериализации Informatica или ваш собственный двоичный формат и т. д.).

Если у вас есть более конкретные вопросы или вам нужна более подробная информация по любому из моих советов, просто дайте мне знать!

6 голосов
/ 22 апреля 2011

Насколько низка задержка и насколько интенсивна интенсивность? Вам нужно иметь представление о том, к чему вы стремитесь, чтобы выбрать правильный подход.

Я мог бы предоставить вам какое-то оборудование, которое отвечало бы на 100% всех запросов, скажем, за 20, вплоть до полной емкости вашего сетевого оборудования, но при этом совсем не использовало бы WCF.

В очень широком приближении я бы сказал, что такие вещи, как WCF, являются очень высокоуровневыми и компромиссными для простоты использования и абстракции для блага программиста с производительностью (задержка / пропускная способность) ). Если они торгуют слишком много для вашего приложения, нужны реальные цифры.

Широко распространенным протоколом на основе IP с минимальной задержкой и минимальными издержками является UDP, поэтому он используется для таких вещей, как DNS и NTP. Он очень масштабируем на сервере, потому что серверу не нужно сохранять какое-либо состояние, и его очень просто внедрить практически на любой платформе. Но вам нужно думать с точки зрения сетевых пакетов, а не объектов .NET. Вы тоже можете поставлять клиентское ПО?

3 голосов
/ 02 мая 2011

Чем больше допущений вы сделаете и какие функции вы выберете, тем быстрее вы сможете сделать свою систему.Чем надежнее и гибче вы пытаетесь делать вещи, тем больше страдает ваша производительность.Я бы предложил несколько основных обязательных элементов:

  1. Формат сериализации двоичных данных.Не используйте XML или любой другой читаемый человеком способ передачи ваших данных.
  2. Достаточно надежный формат сериализации данных, который может поддерживать кросс-архитектурные, мультиязычные конечные точки.На ум приходит BER - C #, похоже, поддерживает
  3. Транспортный протокол, который гарантирует доставку и целостность данных.Если какой-либо тип финансового алгоритма будет использовать эти данные, даже если пропустить один тик, это может означать разницу между ордером, который запускается или отсутствует в цене.Даже если вы собираетесь агрегировать тики на своем сервере, вы все равно хотите контролировать, как информация представляется вашим клиентам.TCP работает для распределенных систем.Однако есть гораздо более быстрые альтернативы, если ваши клиенты находятся на той же машине, что и ваш сервер.UDP даже не гарантирует порядок, который может быть проблематичным (хотя и не непреодолимым).

Что касается внутренней обработки:

  1. Избегайте строк и других классов, которые добавляют значительныенакладные расходы на простые задачи.Вместо этого используйте базовые массивы символов.Я не уверен, какие у вас есть варианты в C # или есть ли у вас даже легкие альтернативы.Если это так, используйте их.Это относится и к структурам данных.
  2. Имейте в виду ошибки сравнения двойных / плавающих чисел.Используйте сравнения, которые проверяют только необходимый уровень точности.Если возможно, внутренне преобразуйте все в целые числа и предоставьте достаточное количество метаданных для обратного преобразования на другом конце.
  3. Используйте нечто подобное распределенным распределителям в C ++.Недостаток знаний C # не позволяет мне быть более конкретным.Снова C #, вероятно, не ваш лучший выбор здесь.Суть в том, что вы собираетесь создавать и уничтожать множество тиковых объектов, и нет никакой причины каждый раз запрашивать у ОС память.
  4. Отправляйте только дельты, но не отправляйте информацию,клиенты уже есть.Это предполагает, что вы используете транспорт с гарантированной доставкой.Если нет, то вы могли бы в конечном итоге отображать устаревшие данные в течение длительного времени.
3 голосов
/ 27 апреля 2011

Живые финансовые данные?Никогда не полагайтесь на WCF на это.Вместо этого следуйте тому, что используют другие отрасли.то есть NASDAQ использует Инновации в реальном времени - Служба распространения данных для доставки тиковых акций пользователям.Они предоставляют C / C ++ / C # api для своих коммуникационных библиотек, которые чрезвычайно просты в настройке и использовании (по сравнению с WCF).

В общем, этот вид потоков данных в реальном времени использует publish /подпишите парадигму , которая помогает убедиться, что общение происходит с минимальными издержками.Такой подход является основной идеей в промежуточном программном обеспечении, ориентированном на сообщения, и это именно то, что финансовые службы используют для работы в режиме реального времени.

На боковом узле вы можете доставлять аудио-видео пакеты в реальном времени.используя библиотеку RTI-DDS, насколько мне известно, беспилотные летательные аппараты, такие как MQ-9, снова используют эту библиотеку для доставки видеоизображения в реальном времени и информации о географическом местоположении на наземные станции управления.

Существует также бесплатное распространение данныхслужебные библиотеки, но у меня нет опыта в них.Вам просто нужно зайти в Google.

Редактировать : В настоящее время я создаю прототип некоторого программного обеспечения HMI (человеко-машинный интерфейс), в котором используются вышеупомянутые библиотеки RTI-DDS, а также две другие библиотеки, имеющие такиеориентированные на сообщения архитектуры, которые до сих пор работали без проблем для всех моих потребностей в коммуникации в реальном времени.Вот демонстрация: http://epics.codeplex.com/ (она будет использоваться для дистанционного управления оборудованием на нашем новом ядерном исследовательском центре)

1 голос
/ 01 июня 2015

Вы спрашиваете конкретно о «ленте пользователей с низкой задержкой».Что вы действительно хотите с низкой задержкой, для «Только канал» (и особенно, если это не приносит доход), пользователи могли бы подождать секунду;это не низкая задержка.

Если вы хотите торговать БЫСТРО, вам нужно физически переместиться через улицу от Биржи (или поблизости с оптической связью).Далее вам необходимо «Торговля на карте»;Карта Ethernet является «умной» и снабжается «Торговыми формулами», которые программируют сетевую карту для осуществления предварительно запрограммированной сделки на основе полученных данных (без приставания к компьютеру).

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

Умение манипулировать этой средой принесет вам больше, чем изобретать колесо.

Сверхнизкая задержка обходится дорого, но на карту поставлены миллиарды;Ваши ставки (и стремление к снижению латентности) будут уменьшены на $.

1 голос
/ 27 апреля 2011

Это может представлять интерес, хотя оно специфично для игр ... Протокол интернет-передачи данных малого размера с самой низкой задержкой? C #

Вот учебник по соединению UDP http://www.winsocketdotnetworkprogramming.com/clientserversocketnetworkcommunication8r.html

Еще одна статья по UDP http://msdn.microsoft.com/en-us/magazine/cc163648.aspx

0 голосов
/ 30 апреля 2011

В прошлом я использовал Tibco rv или raw-сокеты для потоковых цен / тарифов, где ожидаются обновления с высокой частотой.В этой ситуации ограничением часто является клиент (или фактически пользователь) (поскольку пользователь может обработать только очень много обновлений), и поэтому это пример того, где вы можете «потерять» данные.В этой ситуации клиентский сервисный брокер может использоваться для регулирования обновлений.

Если система используется для автоматической торговли или HFT, то такие продукты, как 29West LatencyBuster, доказали свою работоспособность и предлагают гарантированный обмен сообщениями.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...