Чому WebSocket scraping ламається на пікових навантаженнях
На спокійному ринку потік угод іде рівно, і WebSocket scraping здається тривіальним: підписалися на канали, пишемо в базу. Відмова приходить на сплеску — біржа під навантаженням закриває з'єднання, а ліміти підключень не дають тримати окремий канал на кожну торгову пару.
Обрив з'єднання біржі — це режим роботи, а не аварія. Поки клієнт перепідключається, в канал ідуть сотні подій: утворюється пропуск угод, а стакан збирається з застарілого знімка та свіжих змін — розсинхрон стакану, за якого розрахункова ціна розходиться з реальною. Найнебезпечніше те, що розходження не впадає в око: цифри виглядають правдоподібно.
Окрема біда — задвоєні записи. Після розриву частина повідомлень приходить повторно, і без дедуплікації за ідентифікатором події обсяг у базі зростає, а агрегати за обсягом торгів завищуються.
Помилка накопичується мовчки і випливає вже в аналітиці, звітності або в ризик-моделі, де їй не місце.
Розбираємо, як це закривається: відновлення знімка стакану з перевіркою контрольної суми, буферизація подій на час розриву, дедуплікація за ключем і рознесення підписок так, щоб упертися в ліміти підключень було нічим.
Що дає безперервний потік даних з бірж і мереж
Безперервний потік котирувань замість опитування за розкладом знімає головну проблему — рух ціни між запитами.
Коли підписка висить постійно, кожна зміна стакану і кожна угода приходять у момент появи, і частка втрачених подій вимірюється десятими долями відсотка, а не відсотками.
На Binance та інших великих майданчиках потік віддається через шлюз з лімітом на кількість одночасних підписок — саме це обмеження задає архітектуру збирача, а не обсяг ринку.
Розрив з'єднання — штатний режим, а не аварія: спрацьовує ліміт, змінюється ключ доступу, відпадає ділянка мережі. Інженерна різниця в тому, чи піднімається потік сам і з якого місця.
Ми зберігаємо ідентифікатор останньої підтвердженої події і після перепідключення довантажуємо пропущений відрізок з історії — час відновлення з'єднання скорочується до одиниць секунд, оператор не потрібен, дублі відсікаються за ключем угоди.
Повнота історії угод перевіряється звіркою з незалежним джерелом: снапшот книги та архівний лог слугують еталоном, а розходження закривається вікном довантаження. Історія залишається відтворюваною — за нею рахуються метрики заднім числом, включно з хвилинами, коли збирач мовчав.
Затримка доставки при цьому має бути передбачуваною: важливий не середній, а хвіст — при зростанні кількості інструментів він не повинен розповзатися.
Навантаження на збирач зростає від кількості підписок, а не від активності ринку: розбиття інструментів на незалежні групи, запис подій пачками та черга зі зворотним тиском тримають споживання рівним.
Тому потік розширюється новими парами і мережами без переробки ядра — додається ще один сегмент, а не другий збирач.
Порівняння режимів збору ринкових даних
Для ринкових даних не існує одного «правильного» режиму збору: схему обирають за тим, що критичніше — швидкість реакції на подію чи повнота історії за період.
Постійна підписка дає реакцію в момент появи події, але не переживає обрив з'єднання; періодичне опитування стійке до розривів, зате відстає і впирається в ліміти запитів біржі. Нижче — чотири варіанти, між якими реально обирають на старті проєкту.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Постійна підписка на потік (WebSocket) | Живий стакан, стрічка угод, реакція на подію одразу після публікації | Обрив з'єднання дає історичні пропуски: без контрольних точок і коректної перепідписки частина подій губиться безповоротно |
| Періодичне опитування | Рідкісні метрики, довідники інструментів, звірка стану за розкладом | Затримка між запитами, ліміти частоти, при зростанні кількості інструментів зростає і кількість звернень |
| Гібридна схема збору | Торгові та аналітичні системи, де потрібні і швидкість, і повнота історії | Потребує ідемпотентної склейки: дедуплікація, зберігання контрольних точок, розбір розходжень між джерелами |
| Власний вузол мережі | Потрібні дані, яких публічні провайдери не віддають: мемпул, повні логи контрактів у EVM-мережах | Синхронізація та зберігання стану, оновлення і чергування, зате немає чужих лімітів і зовнішніх точок відмови |
На практиці робоча зв'язка — постійна підписка на потік плюс довантаження пропусків за контрольними точками; власний вузол мережі підключають там, де публічні джерела не віддають потрібну глибину даних.
Набір режимів визначаємо за задачею і фіксуємо в схемі даних до старту розробки — це дешевше, ніж переробляти сховище, коли в історії виявляються діри.
WebSocket scraping: етапи впровадження та передачі
Живі дані бірж і EVM-мереж існують тільки в момент публікації: ціна, стакан, нові блоки та логи контрактів не відновлюються заднім числом самі по собі. Постійні з'єднання замість періодичного опитування дають мінімальний лаг, але вимагають дисципліни у відновленні.
Впровадження тому будується навколо двох ризиків — втратити подію на розриві та не помітити цю втрату. Порядок робіт нижче.
- Розбір джерел. Фіксуємо, які канали потрібні: угоди, стакан, нові блоки, логи адрес. Для кожного уточнюємо ліміти на кількість одночасних підписок і глибину історії — де потік самодостатній, а де потрібен добір даних.
- Схема потоків даних. Ведемо шлях повідомлення: джерело → підписка → нормалізація → черга → сховище → споживач. Позначаємо точки буферизації, щоб сплеск активності на ринку не перетворювався на втрату подій.
- Налаштування підписок. Задаємо фільтри, частоту публікації та правило повторної підписки за кожним каналом. Споживач отримує потрібні події, а не весь потік — обробка розвантажується без втрати значущих даних.
- Опрацювання розривів. Описуємо поведінку при обриві: повтори з наростаючою паузою, перевірка живучості з'єднання, відновлення з останнього обробленого блоку або курсора. Пропущене добираємо з історії, вже прийняте — не дублюємо.
- Перевірка повноти даних. Звіряємо потік з незалежним джерелом та історією, рахуємо розходження за кількістю подій і максимальний лаг обробки. Дедуплікація йде за ідентифікатором події, а не за часом надходження.
- Передача рішення. Віддаємо конфігурації підписок, схему потоків, формати повідомлень і регламент дій при збої. Команда замовника бачить, де дивитися метрики і як підняти потік після аварії.
Що залишається у замовника після впровадження потоку
Потік на WebSocket-підписках — це не тільки працюючий збирач, а комплект, з яким команда замовника залишається один на один.
Тому в закриваючий пакет входять конфігурації, схеми та регламенти: за ними потік можна підняти з нуля, розширити і передати іншому інженеру без усних пояснень.
- Конфігурація підписок — перелік каналів та інструментів за кожною біржею і мережею, глибина запитуваної історії, інтервали перепідписки та параметри перепідключення. Версіонується, зміна підписки не вимагає правки коду.
- Схема потоків і сховищ — маршрут від точки входу до сирого архіву та аналітичного шару: де виконується нормалізація, які поля обов'язкові, як фіксуються розходження між джерелами.
- Правила доступу — ролі для читання та адміністрування, порядок видачі й ротації ключів, розділення бойового і тестового контурів, відкликання доступу при зміні співробітника.
- Регламент відновлення — дії при обриві зв'язку або збої вузла: автоматичне перепідключення, догін пропущеного діапазону, ручний перезапуск і перевірка цілісності даних за період.
- Документація по збирачу — що саме збирається, які метрики знімаються, за якими ознаками видно деградацію потоку і куди дивитися при розборі інциденту.
- Порядок додавання нового джерела — чек-ліст: чим джерело відрізняється за форматом і лімітами, що перевіряється до включення в роботу, скільки займає підключення.
Окремо передаємо журнал змін конфігурацій і звіт за навантаженням — видно, коли змінювалися підписки і до якого результату це призвело.
Кейс: потік з біржі без пропусків і розривів з'єднання
Клієнт — трейдингова команда, яка збирала угоди та зміни стаканів з кількох майданчиків для сигналів і історичної аналітики.
Потік з Binance забирався періодичними опитуваннями: на спокійному ринку це виглядало робочим, але на сплесках волатильності частина подій не потрапляла у вибірку, а збирач падав через мережеву помилку і чекав ручного перезапуску.
Ми зафіксували метрики до робіт, перевели збір на постійне з'єднання WebSocket і порівняли показники після.
| Показник | До | Після |
|---|---|---|
| Частка пропущених подій | до 1,8% на сплесках | нижче 0,01% |
| Простій збирача | до 40 хвилин на добу | секунди на перепідключення |
| Ручні перезапуски | 6–8 на добу | 0 |
| Повнота відновленої історії | 92% | 100% |
Усередині замість опитування за розкладом — довгоживуче з'єднання з підпискою на потрібні канали та записом кожної події в чергу на диск до підтвердження обробки.
Мовчання з'єднання розпізнається за відсутністю сигналів зв'язку, розрив закривається перепідключенням з наростаючою паузою і довантаженням пропущеного діапазону з історії біржі: останній підтверджений ідентифікатор події зберігається, тому вікно довантаження відоме точно. Запис ідемпотентний — повторне довантаження не створює дублів.
Підсумок: історія без дір годиться і для аналітики, і для перевірки стратегій на минулих даних, а черговий більше не стежить за живучістю збирача.
Звірка добових зрізів з біржовими дає розходження в межах округлення, тоді як раніше діри виявлялися вже після того, як модель навчилася на неповних даних.
Чим відрізняється підписка на потік від періодичного опитування?
Періодичне опитування — клієнт сам раз на заданий інтервал запитує стан: список ордерів, свіжі угоди, баланс. Реалізується тривіально, не вимагає утримання з'єднання і тому часто залишається запасним каналом.
Ціна — затримка: подія потрапляє в систему не раніше наступного циклу, а все, що сталося між двома знімками, губиться.
Підписка на події через WebSocket перевертає схему: з'єднання відкривається один раз, і джерело саме надсилає повідомлення в момент зміни — появи заявки, виконання угоди, виходу нового блоку.
Швидкість реакції визначається часом передачі сигналу, а не половиною інтервалу опитування. Для арбітражу та реакції на ліквідації різниця принципова.
Навантаження на джерело влаштоване інакше. Опитування створює рівний потік запитів незалежно від активності ринку: у затишшя майже всі вони повертають порожню відповідь, але квоти й ліміти витрачаються.
Потік підписок масштабується разом з активністю — сплеск дає багато повідомлень, у штиль канал мовчить.
Повнота картини — другий вододіл. Опитування віддає знімок, і заявка, виставлена і знята всередині вікна, у даних не з'явиться взагалі.
Потік зберігає послідовність подій, але вимагає опрацювання розривів: при перепідключенні пропущене довантажується окремо, а локальний стакан відновлюється — інакше картина роз'їдеться з біржею.
Тому моделі не протиставляють, а поєднують: підписка тримає потік, рідкісне опитування звіряє стан і ловить розходження. Розбираємо, як це збирається під конкретну задачу.
Технічні сумніви перед стартом робіт
Сумніви на старті рідко стосуються архітектури — частіше вони про те, як новий збирач уживається з уже працюючим контуром і хто відповідає за інциденти. Нижче — питання, які задають до підписання плану робіт.
У нас уже розгорнуто збирач — починати з нуля?
Починаємо з аудиту: дивимося, які потоки даних уже йдуть, де губляться повідомлення і як обробляються розриви з'єднання. Зазвичай вигідніше добудувати нормалізацію і догін історії поруч із поточним контуром і перемикати джерела по одному. Старий збирач працює як резерв, поки не зійдуться дані на звірці.
Як не впертися в ліміти джерела?
Ліміти джерела — це обмеження на кількість активних підписок і частоту перепідписок. Планувальник тримає запас за потоками, розподіляє їх за з'єднаннями і при спрацюванні обмеження віддає пріоритет критичним інструментам і мережам, решту ставить у чергу.
Після розриву збирач відновлює стан від найближчого снапшота і доганяє пропущене, а не починає заново.
Хто відповідає за збої на боці біржі?
Ми збираємо телеметрію за кожним джерелом: затримку доставки, частоту розривів, розходження дельт зі снапшотом. Якщо збій підтверджено на боці джерела — це зовнішній інцидент, і ми фіксуємо його окремо від помилок нашого контуру. Відновлення автоматичне: реконнект, перепідписка, догін історії.
Як розширювати список мереж і майданчиків?
Кожне нове джерело підключається окремим адаптером: своя схема підписки, приведення до спільної моделі даних, включення за флагом. Уже працюючі джерела при цьому не чіпаємо — розширення списку не створює ризику для поточного збору.
Що входить у передачу знань?
Схеми потоків і підписок, конфігурації, регламент чергування та розбору інцидентів, розбір з вашою командою на реальних збоях. Після передачі ви можете додавати джерела і змінювати пріоритети без нас.
Обговоримо задачу і повернемося з оцінкою та планом
Щоб розмова була предметною, достатньо надіслати те, що вже є: перелік бірж і мереж, які потрібно покрити, і які дані потрібні з кожної — угоди, стакан, статуси транзакцій, події контрактів.
Додайте частоту оновлення, потрібну глибину історії та те, куди результат має потрапляти: у базу, у чергу чи напряму у ваш сервіс.
У відповідь приходить розбір за пунктами, за яким уже можна ухвалювати рішення.
- Постановка задачі — які потоки і з яких майданчиків піднімаємо, що вважаємо джерелом істини, де втрата подій допустима, а де ні.
- Схема рішення — як влаштовані підключення, перепідписка на інструменти і довантаження пропущеної ділянки після розриву зв'язку.
- План етапів — з чого починаємо, який проміжний результат вважаємо робочим, на якому кроці виходимо на перевірку реальними даними.
- Склад артефактів — сервіси, конфігурації, схема потоків і сховища, інструкції із запуску, набір метрик і логів.
- Критерії приймання — безперервність потоку під навантаженням, поведінка при обриві, повнота історичних даних, розходження з біржовими даними.
- Межі робіт — що закриваємо ми, що залишається на вашому боці і які зовнішні залежності впливають на строки.
Цей набір зручно використовувати і як чек-ліст при виборі підрядника: якщо у відповіді немає схеми, етапів і порядку перевірки — оцінювати нічого.
