Разработка T&S ленты для криптобирж под ключ

Time & Sales лента: где она ломается под нагрузкой

Лента Time & Sales — это поток всех исполненных сделок: цена, объём, сторона инициатора. На спокойном рынке она выглядит безобидно, но именно она первой упирается в пределы инфраструктуры на пиковом потоке заявок, когда модуль исполнения выдаёт события быстрее, чем их успевают доставить и отрисовать.

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

Рассинхрон потока возникает на стыке восстановления после обрыва связи. Клиент берёт снимок состояния и догоняет его порциями изменений, но пока снимок применяется, часть изменений уже устарела или пришла с другим порядковым номером. Без строгого контроля непрерывности последовательности лента тихо разъезжается с реальным состоянием книги — внешне живая, но с неверными объёмами и ценой последней сделки.

Задержка отклика и зависание интерфейса — третья точка отказа, и живёт она на стороне клиента. Отрисовка каждой сделки отдельным обновлением при пике держит главный поток вычислений занятым, накопившиеся обновления сливаются в очередь, и лента перестаёт реагировать на действия трейдера — до перезагрузки вкладки.

Разбираем, как это закрывается: подтверждение обработки на каждом участке пути, контроль непрерывности последовательности, ограничение очереди с явным сигналом о перегрузке и пакетная отрисовка кадрами вместо обновления на каждое событие.

Эффект внедрения: отклик, полнота, устойчивость к пикам

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

Метрики снимаются непрерывно с двух сторон — на сервисе раздачи и на клиенте: панели мониторинга в Grafana, алерты на расхождение счётчиков и на рост времени восстановления. Расхождение хотя бы в одну сделку становится поводом для разбора, потому что лента участвует в сверке и аудите истории торгов.

Устойчивость к пикам проверяется не на глаз, а прогоном записанного потока: сервис обязан пережить всплеск без потери строк и без роста задержки отрисовки. После обрыва лента догоняет поток сама, без действий дежурного, — это и есть та разница, которую заказчик видит в эксплуатации.

Форматы ленты: поток сделок, агрегация, снапшоты

Формат ленты определяет, что именно получает клиент: каждую сделку отдельно, агрегированные интервалы или срез истории на момент подключения. На бирже эти режимы сосуществуют, и выбор между ними — компромисс между полнотой данных, нагрузкой на канал и задержкой доставки.

Поток сделок идёт по постоянному соединению: цена, объём, сторона инициатора и идентификатор последовательности в каждом сообщении. Агрегация сделок собирает их в интервалы — окно агрегации настраивается от долей секунды до минуты: шире окно, меньше сообщений и выше задержка реакции. Снапшоты истории закрывают подключение и разрыв канала: клиент забирает срез за нужный диапазон и продолжает с того места, где остановился, без пропусков и дублей.

В рабочем контуре режимы комбинируются: снапшот при подключении, затем догон потоком по идентификатору последовательности. Поэтому формат ленты мы согласуем с заказчиком до начала работы — от него зависит и схема хранения, и то, как клиент переживает разрыв соединения без потери сделок.

Порядок работ: аудит потока, схема, сборка, проверка

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

1. Аудит источников. Инвентаризируем площадки: способ доставки сделок, частота обновлений, глубина потока, поведение в часы пик. Отмечаем, где данные расходятся с биржевым агрегатором, и заранее решаем, чем закрывать эти расхождения.

2. Схема данных. Описываем единую модель сделки: цена, объём, сторона агрессора, метка времени, идентификатор площадки, признак отмены. Правила нормализации сводят разные форматы к одному контракту — лента перестаёт зависеть от конкретного источника.

3. Сборка сервиса. Реализуем подписку, буферизацию, дедупликацию и переподключение с догоном пропущенного окна: обрыв связи не оставляет дыру в ленте. Публикацию настраиваем так, чтобы задержка от сделки до записи оставалась предсказуемой.

4. Проверка на истории. Прогоняем сервис на архивных данных и сверяем с эталонной лентой площадки: ищем пропуски, дубли, нарушения порядка, расхождения меток времени. Каждое расхождение разбираем до причины — в коде или в самом источнике.

5. Испытания на сбоях. Эмулируем всплески активности, разрыв соединения, рестарт узла и смотрим, восстанавливается ли лента без потерь. По итогам настраиваем сигналы, по которым дежурный видит деградацию раньше пользователя.

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

Комплект передачи: сервисы, схемы, регламенты, доступы

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

• Комплект документации: описание топологии сервисов, форматов сообщений и гарантий доставки — включая поведение при обрыве соединения и переподключении с догрузкой пропущенных сделок.
• Схемы интеграции: диаграммы потока от торгового ядра до клиентских подписчиков, точки подключения, порядок маршрутизации и правила нормализации данных по инструментам.
• Регламент эксплуатации: порядок плановых работ и окна обслуживания, процедура выката новой версии и отката на предыдущую, критерии обязательной эскалации инцидента.
• Политики доступа: роли и права на промышленный и тестовый контуры, выдача и отзыв ключей, разделение доступа к торговому ядру и к витрине исторических данных.
• Инструкции для дежурной смены: пошаговые сценарии на типовые отказы — рост задержки публикации, лавина переподключений, расхождение ленты с ядром, деградация канала.
• Мониторинг и оповещения: набор метрик (полнота потока, задержка, доля отброшенных сообщений), пороги срабатывания и адресаты уведомлений.
• Протоколы приёмки: результаты нагрузочных и отказоустойчивых прогонов плюс контрольный список проверки после каждого релиза.

Объём документации не «на всякий случай»: каждый артефакт закрывает конкретный класс отказов, который иначе стоит часов простоя биржи. Комплект передаём на встрече с разбором, а не архивом — чтобы дежурная смена и ваш инженер задали вопросы по живому.

Кейс: пиковый поток сделок и время восстановления

Биржа с резкими всплесками активности: листинги, каскадные ликвидации, новостные импульсы. Средний поток сделок в ленте Time & Sales идёт ровно, но на пике кратность к нему вырастала в десятки раз — и именно в эти минуты лента отставала сильнее всего, когда данные нужны посекундно.

До нас переподключение клиента шло через полный снапшот и без дедупликации по идентификатору сделки. Итог — либо пропуск сделок в истории, либо дубли, а восстановление подписки занимало минуты.

Что изменили

Поток сделок отдаём через Kafka: снапшот плюс инкремент, дедупликация по идентификатору сделки, серверный буфер на время переподключения — подписка не рвётся, клиент догоняет пропущенное сам.

Результат

Устранён целый класс отказов — расхождение ленты у клиента с фактическими сделками на бирже. На пиковых интервалах задержка доставки осталась в пределах секунды и перестала расти вместе с нагрузкой, а отставание ленты больше не требует ручного вмешательства дежурной смены.

Чем отличается поток сделок от агрегированного стакана?

Поток сделок, или Time & Sales лента, — это журнал исполнений: цена, объём, время и сторона инициатора в каждой строке. По метке агрессора видно, снимал ли покупатель лимитную заявку на продажу или продавец бил в бид, — снимок книги заявок такого не показывает.

Агрегированный стакан — про намерения, а не про факты: лимитные заявки сгруппированы по уровням цены с суммарным объёмом на каждом. Заявку можно снять до исполнения, поэтому стакан — состояние, которое пересобирается из инкрементальных изменений, а поток сделок — последовательность событий, из снимка не восстановимая.

Отличие подходов проявляется на одной и той же сделке. Стакан отвечает, где стоит плотность и на каком уровне цена встретит сопротивление; лента — как объём был набран: одной крупной заявкой или серией мелких исполнений по разным ценам.

Выбор режима диктует задача. Алгоритмам, которые считают дельту и дисбаланс агрессора, нужна лента с флагом стороны; оценка ликвидности и проскальзывания строится по глубине стакана. Для арбитража и контроля качества исполнения подают оба потока одновременно.

В интерфейсе их ведут по разным каналам: лента обновляется на каждое исполнение, стакан — реже, по накопленным изменениям. При плотном потоке записи сворачивают по цене за короткий интервал — отрисовка перестаёт захлёбываться, но разбивка на отдельные сделки теряется.

Технические вопросы, которые задают до старта работ

До старта проекта заказчики проверяют примерно одно и то же: переживёт ли лента обрыв связи, чем подтверждается порядок сделок и не придётся ли трогать ядро торговой платформы ради нового потока. Ниже — короткие ответы по каждому пункту, детали разбираем на архитектурной сессии вместе с вашей командой.

Как вы гарантируете правильный порядок сделок?

Последовательность задаёт единый источник времени на стороне адаптера к бирже, а не часы браузера. Пакет, пришедший не по порядку, попадает в буфер переупорядочивания и публикуется только после пропущенного, поэтому строки не переставляются и не «дёргаются» при отрисовке.

Насколько сложно встроить это в нашу платформу?

Подключаемся отдельным сервисом к вашему каналу рыночных данных и отдаём нормализованный поток по контракту, согласованному с вашей командой; совместимость с FIX и внутренним форматом брокера проверяем на стенде до релиза. Матчинг и балансовые модули не меняем.