Реализация real-time WebSocket scraping для криптобирж и EVM-сетей

Почему WebSocket scraping ломается на пиковых нагрузках

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

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

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

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

Что даёт непрерывный поток данных с бирж и сетей

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

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

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

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

Сравнение режимов сбора рыночных данных

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

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

WebSocket scraping: этапы внедрения и передачи

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

1. Разбор источников. Фиксируем, какие каналы нужны: сделки, стакан, новые блоки, логи адресов. Для каждого уточняем лимиты на число одновременных подписок и глубину истории — где поток самодостаточен, а где нужен добор данных.
2. Схема потоков данных. Ведём путь сообщения: источник → подписка → нормализация → очередь → хранилище → потребитель. Помечаем точки буферизации, чтобы всплеск активности на рынке не превращался в потерю событий.
3. Настройка подписок. Задаём фильтры, частоту публикации и правило повторной подписки по каждому каналу. Потребитель получает нужные события, а не весь поток — обработка разгружается без потери значимых данных.
4. Отработка разрывов. Описываем поведение при обрыве: повторы с нарастающей паузой, проверка живости соединения, восстановление с последнего обработанного блока или курсора. Пропущенное добираем из истории, уже принятое — не дублируем.
5. Проверка полноты данных. Сверяем поток с независимым источником и историей, считаем расхождение по числу событий и максимальный лаг обработки. Дедупликация идёт по идентификатору события, а не по времени прихода.
6. Передача решения. Отдаём конфигурации подписок, схему потоков, форматы сообщений и регламент действий при сбое. Команда заказчика видит, где смотреть метрики и как поднять поток после аварии.

Что остаётся у заказчика после внедрения потока

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

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

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

Кейс: поток с биржи без пропусков и разрывов соединения

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

Мы зафиксировали метрики до работ, перевели сбор на постоянное соединение WebSocket и сравнили показатели после.

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

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

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

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

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

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

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

Поэтому модели не противопоставляют, а совмещают: подписка держит поток, редкий опрос сверяет состояние и ловит расхождения. Разбираем, как это собирается под конкретную задачу.

Технические сомнения перед стартом работ

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

Как не упереться в лимиты источника?

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

Кто отвечает за сбои на стороне биржи?

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

Как расширять список сетей и площадок?

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