← Zurück

Дублирование ордеров в ядре S#

Добрый день.

Обращаюсь прежде всего к разработчикам, ну и к опытным специалистам по части алго. Есть такая проблема сейчас: когда пришел ордер событие вызывает обработчики, ну и все что на них висит поочереди отрабатывает. Если где происходит затык, мы получаем висяк всей системы. Михаил уже было обмолвился что в стратегию будет заходить очередь всех событий в один поток. Это хорошее решение. Но там мне никто не ответил, поэтому задаю более развернутый вопрос здесь. Как будет это реализовано? Сделать очередь я и щас могу без проблем, но известно что между событием по ордеру и началом обработки может произойти изменение статуса ордера. Отсюда когда мы начнем ордер обрабатывать, получим уже другой статус и обработаем его. Но в очереди событий будет лежать еще одно событие с таким же статусом ордера. Это как-то плохо и нехорошо. Как планируется решить вопрос? Нет ли смысла начать дублировать объекты которые могут меняться при передаче в стратегии итд?? Если делать очереди то как-то тут надо обходить эту проблему. Дублировать ордера (и другие объекты которые могут меняться) я могу и сам, но тогда скорее всего придется доработать Clone методы.

В общем как видится решение текущей проблемы с локами через очереди? Какую архитектуру нужно сделать? Как избежать подвешивания всего и вся если один из потребителей загнется?

War dieses Thema hilfreich?

Thema teilen

Kommentare (6)

Anmelden oder Konto erstellen, Melden Sie sich an oder registrieren Sie sich, um einen Kommentar zu hinterlassen

VassilSanych
VassilSanych

Идеального решения нет. Очередь событий в одном потоке позволяет быть уверенным, что обработка не будет лочиться по пути к стратегии, и что при тестировании всё будет происходить в правильной последовательности и с хорошей производительностью. Многопоточность в этом случае (как сейчас) даёт излишний оверхед на контроль потоков и дополнительные проблемы синхронизации. Асинхронность реальных событий никто не отменяет: как было запаздывание реагирования, так и будет. Затыки с производительностью и проблемы распараллеливания собственной стратегии предлагаю решать разработчику стратегии.

ra81
ra81 Autor

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

Сделки например дублировать нет смысла они неизменны. Ну и так далее.

VassilSanych
VassilSanych

ra81: и в событии посылать дубль а не оригинал, и дубль будет неизменен на всем протяжении. Зачем работать с устаревшей заявкой? Может лучше предусмотреть её изменчивость?

ra81
ra81 Autor

VassilSanych:

ra81: и в событии посылать дубль а не оригинал, и дубль будет неизменен на всем протяжении. Зачем работать с устаревшей заявкой? Может лучше предусмотреть её изменчивость? Тут есть два варианта развития событий. Либо мы вводим кучу неопределенностей типо: ордер может измениться пока мы его обрабатываем, котировка может измениться между двумя нашими действиями, да еще дофига чего. Либо мы работаем с неким снимком на конкретный момент времени. Тогда наши действия вполне линейны и определенны. А уж чтобы не работать с устаревшими данными просто наращиваем мощность железа и все. Что выгоднее? Думаю вариант два выгоднее. Он линеен, легко прослеживается, легко масштабируется.

В общем жду таки разработчиков.

VassilSanych
VassilSanych

ra81: Тогда наши действия вполне линейны и определенны. Ага. Только бессмысленны. Потому что заявки с таким статусом уже нет. Информация снэпшота имеет смысл только для логирования. Для торговли важно нынешнее состояние, а не то, как замечательно и логично мы обрабатываем состояние заявки, которое было пару секунд назад.

gramp
gramp

VassilSanych:

ra81: Тогда наши действия вполне линейны и определенны. Ага. Только бессмысленны. Потому что заявки с таким статусом уже нет. Информация снэпшота имеет смысл только для логирования. Для торговли важно нынешнее состояние, а не то, как замечательно и логично мы обрабатываем состояние заявки, которое было пару секунд назад.

в любом случае мы работаем со снэпшотом, вопрос лишь в частоте его получения - кому-то важны микросекунды, кому-то минуты )