Парсинг данных криптобирж: REST API, WebSocket, CCXT

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

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

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

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

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

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

Что даёт налаженный сбор рыночных данных

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

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

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

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

Парсинг криптобирж: периодические запросы или потоковые подключения

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

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

Унифицированные адаптеры

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

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

Этапы внедрения: от аудита источников до передачи регламентов

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

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

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

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

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

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

Кейс: рассинхрон стакана на трёх площадках и как его убрали

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

До переделки картина выглядела так: на активных парах терялось 4–6% обновлений, окно восстановления после обрыва занимало до 30 секунд, суммарный простой сбора доходил до пары часов в сутки. Дежурная смена получала 6–8 обращений за ночь и каждый раз разбиралась вручную.

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

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

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

Чем потоковые подключения отличаются от периодических запросов?

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

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

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

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

Что уточняем до старта: лимиты, блокировки и хранение истории

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

Что делать, если подписка разорвалась ночью?

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

Насколько глубоко хранится история?

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

Как подключается новая площадка?

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

Обсудим вашу задачу и вернёмся с планом внедрения

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

Что заметно ускоряет оценку:

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

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

Опишите задачу — вернёмся с оценкой объёма работ, сроками и планом внедрения по этапам.