В HFT имеет ли смысл пытаться параллельно обрабатывать заказы?
Ну, я предполагаю, что это более теоретический вопрос для тех, кто знаком с HFT. Я получаю заказы от FAST и обрабатываю их. Я получаю около 2-3 тысяч заказов в секунду. Вопрос в том, стоит ли мне пытаться обрабатывать их синхронно или асинхронно.
Каждый раз, когда я получаю следующий заказ, мне нужно сделать следующее:
- обновить книгу заказов соответствующего инструмента
- обновить индексы и индикаторы, которые зависят от этого порядка
- обновить стратегии и запланировать некоторые действия, если это необходимо (купить / продать что-то и т. д.)
Чтобы сделать это синхронно, у меня есть около 200-300 мкс (чтобы иметь возможность обрабатывать 3000 заказов в секунду). Этого должно быть достаточно, я думаю.
Я думаю, что на планирование асинхронной задачи я потратил ~30 мкс
Плюсы и минусы:
Синхронный:
- ++ не нужно синхронизировать вещи!
- ++ задержка между "заказ получен" и "действия предприняты" меньше, потому что не нужно планировать задачи или передавать данные / работу другому процессу (очень важно для hft!).
- - однако действие "заказ получен" может быть отложено, потому что мы можем ждать в буфере сокета, ожидая обработки предыдущего заказа
Асинхронный:
- ++ способность использовать возможности современных серверов (мой сервер имеет 24 ядра, например)
- ++ в некоторых сценариях быстрее, потому что не ждите пока обрабатывается предыдущее сообщение.
- ++ может обрабатывать больше сообщений или делать более "сложные" вещи за сообщение
- - нужно синхронизировать много чего может замедлить работу программы
Пример синхронизации: мы получаем обновленный заказ MSFT, затем обновляем заказ INTC и обрабатываем их в разных потоках. В обоих случаях мы запускаем пересчет индекса NASDAQ. Поэтому расчет индекса NASDAQ должен быть синхронизирован. Однако эту конкретную проблему можно обойти, чтобы избежать синхронизации... Это всего лишь пример возможной синхронизации.
Поэтому вопрос заключается в том, должен ли я обрабатывать обновления заказов синхронно или асинхронно. Пока что я обрабатываю их асинхронно, и у меня есть отдельный поток для каждого инструмента. Потому что я могу обрабатывать два обновления для разных приборов (MSFT и INTC), но два обновления для одного прибора (MSFT) должны обрабатываться синхронно.
1 ответ
Я получаю заказы от FAST и обрабатываю их. Я получаю около 2-3 тысяч заказов в секунду
В самом деле? Вы работаете на бирже? Если серьезно, я получаю данные с 5 бирж, но это не заказы;) Я предлагаю вам привести свой срок в соответствие - вы получите 2-3 тысячи СОБЫТИЙ, но я действительно сомневаюсь, что вы получаете ЗАКАЗЫ.
Вы когда-нибудь задумывались о выполнении многоступенчатой настройки обработки? Т.е. вы получаете данные в 2-х потоках, передаете их в другой поток, чтобы найти инструмент (идентификатор вместо строк), передаете их в другой поток, чтобы обновить книгу заказов, передаете их в другой поток, чтобы сделать индикаторы, передайте X в X темы делать стратегии?
Нет необходимости планировать задачи все время, просто синхронизируйте очереди с одним сообщением обработки задач на каждом из них. Может быть супер эффективным с подходом без блокировки.
Жестоко говоря: я за многопоточность, но все при обработке ядра должны поддерживать мощность, поэтому классическая многопоточность отсутствует. Зачем? Мне нужна полностью повторяемая обработка, чтобы модульные тесты получали определенный результат.
Пока что я обрабатываю их асинхронно, и у меня есть отдельный поток для каждого инструмента
Вы не торгуете много, верно? Я имею в виду, я отслеживаю около 200 000 инструментов (5 полных обменов). Выделение 200.000 потоков было бы - ах - непомерно;)
GO поэтапный конвейер - это означает, что циклы ядра могут быть небольшими, и вы можете распределить их по достаточному количеству ядер, чтобы вы были гораздо более масштабируемыми. THEN должным образом оптимизировать - например, довольно часто приходят обновления одного инструмента, за которым следует другое обновление для того же инструмента (например, многократное выполнение при выполнении большого заказа). Воспользуйтесь этим.