Комментарии 17
Вместо тарантула я бы предложил рассмотреть Mnesia (или ETS для начала), которые являются частью (платформы) Erlang. Так вы получите прозрачное взаимодействие с возможностью хранения термов эрланга без дополнительных затрат на сериализацию/десериализацию.
Если каждое приложение может быть запущено во множественном числе, будет ли применение оркестратора сервисов типа k8s? Каким образом планируется service discovery, балансировка сервисов, и т.д.? Где api gateway для публичных api, что планируется использовать в качестве system bus? Смотря на картинку архитектуры возникает много вопросов.
Спасибо за комментарий. Организация кластера действительно важный вопрос.
Контейнеризация активно используется на этапе разработки для создания виртуальных сред приближенных к боевым. В продакшене ее использование не планирую. Штатных средств Erlang/OTP хватает для построения отказоустойчивого и масштабируемого кластера. Ответы на вопросы связанные с SD, балансировкой, системной шиной и другими важными моментами при проектировании распределенных систем освещены в моих прошлых публикациях: habr.com/ru/post/446028, habr.com/ru/post/446108, habr.com/ru/post/446344.
В последующих статьях архитектура Vtrade будет рассмотрена более детально.
Контейнеризация активно используется на этапе разработки для создания виртуальных сред приближенных к боевым. В продакшене ее использование не планирую. Штатных средств Erlang/OTP хватает для построения отказоустойчивого и масштабируемого кластера. Ответы на вопросы связанные с SD, балансировкой, системной шиной и другими важными моментами при проектировании распределенных систем освещены в моих прошлых публикациях: habr.com/ru/post/446028, habr.com/ru/post/446108, habr.com/ru/post/446344.
В последующих статьях архитектура Vtrade будет рассмотрена более детально.
Тема интересная. Но на реальной бирже количество операций (квотс) в тысячу раз больше сматченных ордеров. Так что нагрузка для 5-7 тысяч матчей в секунду не определяет выбор технологий и дизайна.
Эксперимент, как раз и задуман, чтобы понять какие технологии и дизайн применять в реальных проектах. Очень интересна конструктивная критика и реальный опыт разработки.
Поделитесь пожалуйста примерным набором технологий и дизайном, которые обеспечивают поток 5-7к закрытых сделок или частичных закрытий в секунду на рынок (с полной фиксацией данных и уведомлением участников), и потенциально позволяющие обслуживать сотни и тысячи рынков.
Поделитесь пожалуйста примерным набором технологий и дизайном, которые обеспечивают поток 5-7к закрытых сделок или частичных закрытий в секунду на рынок (с полной фиксацией данных и уведомлением участников), и потенциально позволяющие обслуживать сотни и тысячи рынков.
+100500 — я бы и сам хотел послушать на эту тему :)) — жутко интересно, что другие выбирают. Обосновать какой-то выбор работа неблагодарная, но есть два принципиальных момента — скорость доставки квоты или ордера (MQ и TCP для этого уже не годятся) и распределенность компонент — она выйдет боком если нараспределять квотбуки (пардон, я не знаю задумывали ли вы квотбуки). По скорости доставки ордер/квота от входа в систему до бука (включая парсинг). Должна долетать за 30-40 микросекунд или быстрей, это типа уже у всех. Потому как квотов/ордеров на бирже может входить до миллиона в секунду на пиках. А по распределенности — все что нараспределялось (по рынкам), придется потом собирать для доставки одному клиенту. Ну вот как то так, с самого начала. А, да, Тарантул кстати гуд, Усманычу респект, реально развивает :))).
вот да… информации мало)
Насчет скорости. Раунд трип, от момента приземления ордера на платформе до момента, когда ордер попадает к обработчику рынка (order matching engine) и тот выдает сигнал, составляет около 30-35 мкс. В основном, это время тратится в mq построенном поверх erlang distributed, который в свою очередь бегает поверх tcp. Хотя бы с этой метрикой определились, что она примерно, как у всех)
Tarantool чаще радует. Огорчает, что пока не завезли синхронную репликацию. Ну и к явному управлению транзакциями есть вопросы.
Насчет скорости. Раунд трип, от момента приземления ордера на платформе до момента, когда ордер попадает к обработчику рынка (order matching engine) и тот выдает сигнал, составляет около 30-35 мкс. В основном, это время тратится в mq построенном поверх erlang distributed, который в свою очередь бегает поверх tcp. Хотя бы с этой метрикой определились, что она примерно, как у всех)
Tarantool чаще радует. Огорчает, что пока не завезли синхронную репликацию. Ну и к явному управлению транзакциями есть вопросы.
Вот тут про 35мкс через mq поподробнее, плиз — правильно ли я понял что между ордер ресивером ужи матчинг энджин mq через tcp/ip stack? Меня терзают смутные сомнения...
Внутри платформы все по tcp. Erlang дает full mesh. Тоже стало любопытно про задержки. У меня отложилась в памяти цифра end-to-end до 30 мкс.
Сейчас измерил req-resp на локали внутри докера. Sequential 20933 cycles/s, что эквивалентно round trip latency = 47,7мкс. Плюс будет tcp stack latency. На моем ядре и машине он равен ~28 мкс. Плюс будет сетевая end-to-end latency 7 мкс в случае 10 GigE и меньше 1,5 мкс для InfiniBand. Итого в конкретном случае round tip latency будет 89,7 мкс и 78,7мкс соответственно.
Если говорить про задержку доставки ордера от входа в систему до обработчика книги, то это end-to-end latency и в конкретном случае она будет от 44 мкс до 39 мкс соответственно.
Да, не 35 мкс. Похоже, чтобы добиться 30 мкс нужно сидеть в ядре, а не user space.
Сейчас измерил req-resp на локали внутри докера. Sequential 20933 cycles/s, что эквивалентно round trip latency = 47,7мкс. Плюс будет tcp stack latency. На моем ядре и машине он равен ~28 мкс. Плюс будет сетевая end-to-end latency 7 мкс в случае 10 GigE и меньше 1,5 мкс для InfiniBand. Итого в конкретном случае round tip latency будет 89,7 мкс и 78,7мкс соответственно.
Если говорить про задержку доставки ордера от входа в систему до обработчика книги, то это end-to-end latency и в конкретном случае она будет от 44 мкс до 39 мкс соответственно.
Да, не 35 мкс. Похоже, чтобы добиться 30 мкс нужно сидеть в ядре, а не user space.
>Похоже, чтобы добиться 30 мкс нужно сидеть в ядре, а не user space.
Kernel bypass на входе и kernel bypass между компонентами (если мы все еще говорим про распределенную систему, а не однопоточный процесс :) — бывает и такое). Иначе кроме latency у вас еще и CPU будет загружен толканием квотов через tcp/ip стек, да так, что на матч ресурсов не останется. Т.е. это все к вопросу об MQ для ордеров/квот.
А что у вас за Infiniband? Свой или с азура? Мне интересно где в наши дни берут Infiniband кластера :)
Kernel bypass на входе и kernel bypass между компонентами (если мы все еще говорим про распределенную систему, а не однопоточный процесс :) — бывает и такое). Иначе кроме latency у вас еще и CPU будет загружен толканием квотов через tcp/ip стек, да так, что на матч ресурсов не останется. Т.е. это все к вопросу об MQ для ордеров/квот.
А что у вас за Infiniband? Свой или с азура? Мне интересно где в наши дни берут Infiniband кластера :)
InfiniBand я привел для оценки интервала
ок. Кроме коммуникаций надо определиться с read/write contention на приемке квотов/ордеров, в идеале бы с минимум блокировок и контекст свитч. Тут простор для творчества и креатива, одним выбором фреймворка не отделаешься :). Ну а дальше — smart quotes throttling и оптимизация буфферов.
Жаль только что все ноу хау, из реального мира, являются trade secrets. Так что здесь никто особенно откровенничать не станет :( Но вот я бы с удовольствием почитал.
Жаль только что все ноу хау, из реального мира, являются trade secrets. Так что здесь никто особенно откровенничать не станет :( Но вот я бы с удовольствием почитал.
Я думаю ваш эксперимент вполне можно провести на не очень хорошей сетевой инфраструктуре. Задержки на сеть и сетевой стек — примерно константа. Если их померить отдельно и вычесть из итоговой цифры, а потом добавить 10 мкс на каждый хост между входом и выходом (столько вам добавит хорошая сеть и карточка с kernel-bypass), то получится убедительная цифра.
Если эта цифра в районе 50 мкс — нормально. Если вы померите ещё 99%-й персентиль и он в пределах 100 мкс — совсем хорошо. Это примерно то что достигается на commodity hardware (без FPGA итп) для функциональности matching engine. Мерить нужно «честно», switch-to-switch. То есть от «пакет с ордером на вашем первом свиче» до «ответ (какой-нибудь) на вашем последнем свиче».
Ничего космического в технологиях нет — in-memory хранилище с синхронной репликацией и минимумом гарантий на консистентность, поменьше хостов на «главном» пути пакета (желательно минимум, то есть 2), поменьше походов в ядро, оптимизированные структуры данных и алгоритмы. Но общедоступные бесплатные библиотеки которые это все обеспечивают мне неизвестны. Поэтому буду с интересом следить за развитием событий :)
Если эта цифра в районе 50 мкс — нормально. Если вы померите ещё 99%-й персентиль и он в пределах 100 мкс — совсем хорошо. Это примерно то что достигается на commodity hardware (без FPGA итп) для функциональности matching engine. Мерить нужно «честно», switch-to-switch. То есть от «пакет с ордером на вашем первом свиче» до «ответ (какой-нибудь) на вашем последнем свиче».
Ничего космического в технологиях нет — in-memory хранилище с синхронной репликацией и минимумом гарантий на консистентность, поменьше хостов на «главном» пути пакета (желательно минимум, то есть 2), поменьше походов в ядро, оптимизированные структуры данных и алгоритмы. Но общедоступные бесплатные библиотеки которые это все обеспечивают мне неизвестны. Поэтому буду с интересом следить за развитием событий :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эксперимент VonmoTrade. Часть 1: Биржи и современные технологии