it-swarm.com.ru

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

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

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

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

Обновление:  

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

34
Sol

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

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

Теперь программное обеспечение Informatica для обмена сообщениями может передавать сообщения между процессами на одной машине за микросекунду, и если вы хотите купить несколько сетевых адаптеров Nice 10 GIG-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 в Windows, но в будущем должно стать намного лучше), отключение определенных состояний питания процессора и т. д.

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

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

37
strangelydim

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

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

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

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

6
Will Dean

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

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

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

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

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

3
Teoman Soygul

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

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

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

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

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

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

Смотрите: http://intelligenttradingtechnology.com/article/groundbreaking-results-high-performance-trading-fpga-and-x86-technologies

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

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

1
Rob

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

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

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

1
Jonathan

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

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

0
dashton