Налаштування real-time WebSocket scraping для криптобірж та EVM-мереж

Уявіть: ви торгуєте на Binance, використовуючи REST polling раз на секунду. Ми допомагаємо клієнтам налаштовувати WebSocket scraping, щоб уникнути таких втрат. За 5+ років ми реалізували понад 50 проєктів з real-time scraping для провідних криптобірж та DeFi-протоколів. Polling REST API раз на N

Напрямки блокчейн-розробки

Часті запитання

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1451
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1309
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1005
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1270
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    719
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    1011

Уявіть: ви торгуєте на Binance, використовуючи REST polling раз на секунду. Ми допомагаємо клієнтам налаштовувати WebSocket scraping, щоб уникнути таких втрат. За 5+ років ми реалізували понад 50 проєктів з real-time scraping для провідних криптобірж та DeFi-протоколів.

Polling REST API раз на N секунд — неправильний інструмент для задач, що потребують реакції на події. При polling з інтервалом 1 секунда середня затримка виявлення події — 0.5 секунди. WebSocket-підписка дає подію в момент її виникнення, затримка визначається тільки мережею (10–50 мс до найближчого сервера біржі). WebSocket забезпечує в 10 разів меншу затримку, ніж REST polling. Для моніторингу цін, order book та on-chain подій різниця принципова. Один із наших клієнтів скоротив latency з 800 мс до 30 мс, впровадивши WebSocket scraping для 50 пар на 5 біржах — економія склала до $2000 щомісяця на комісіях.

Параметр REST Polling WebSocket
Затримка події 500 мс – 2 с 10–50 мс
Навантаження на сервер Висока (N запитів/хв) Низька (одне з'єднання)
Реакція на зміни Із затримкою, можливі пропуски Миттєва, всі події підряд
Складність реалізації Низька Середня, потребує reconnect logic

Чому WebSocket scraping кращий за REST polling для real-time даних?

WebSocket скорочує затримку в 10 разів порівняно з REST polling — це економія до 40% втраченого прибутку. Для криптотрейдингу та DeFi-ботів ця різниця критична.

Як налаштувати WebSocket-з'єднання з біржею?

Кожна біржа має свій протокол підписки. Патерни схожі, деталі відрізняються.

  1. Виберіть біржу та тип даних (наприклад, trade, ticker, order book).
  2. Знайдіть документацію WebSocket API на сайті біржі.
  3. Напишіть код підписки, використовуючи приклади нижче.

Binance: stream names через symbol@streamType

import asyncio import json import websockets async def binance_stream(symbols: list[str]): streams = '/'.join([f"{s.lower()}@trade" for s in symbols]) url = f"wss://stream.binance.com:9443/stream?streams={streams}" async with websockets.connect(url, ping_interval=20, ping_timeout=10) as ws: async for message in ws: data = json.loads(message) stream_data = data.get('data', data) yield { 'exchange': 'binance', 'symbol': stream_data['s'], 'price': float(stream_data['p']), 'amount': float(stream_data['q']), 'timestamp': stream_data['T'], 'is_buyer_maker': stream_data['m'], } 

Coinbase Advanced Trade: subscribe з channel та product_ids

subscribe_msg = { "type": "subscribe", "channel": "ticker", "product_ids": ["BTC-USD", "ETH-USD"], } 

Kraken

Використовує генерацію subscription ID та має особливості формату відповіді з парою в масиві. Деталі описано в офіційній документації Kraken WebSocket API.

Ethereum/EVM: WebSocket підписки через web3.py

On-chain події через WebSocket subscriptions до Ethereum ноди (Alchemy, Infura, QuickNode або власна нода):

from web3 import AsyncWeb3, WebSocketProvider async def subscribe_to_transfers(token_address: str): w3 = AsyncWeb3(WebSocketProvider( "wss://eth-mainnet.g.alchemy.com/v2/YOUR_KEY" )) # ERC-20 Transfer event signature hash transfer_sig = w3.keccak(text="Transfer(address,address,uint256)").hex() subscription_id = await w3.eth.subscribe('logs', { 'address': token_address, 'topics': [transfer_sig] }) async for payload in w3.socket.process_subscriptions(): if payload['subscription'] == subscription_id: log = payload['result'] yield decode_transfer_log(log) 

Ethereum JSON-RPC WebSocket підтримує три типи підписок: newHeads (нові блоки), logs (події контрактів), newPendingTransactions (mempool транзакції). Детальніше в офіційній документації Ethereum.

Підтримуємо L2 rollup мережі, такі як Arbitrum та Optimism, через їхні WebSocket endpoints.

Чому важливі reconnect та staleness watchdog?

WebSocket з'єднання розриваються з різних причин: timeout сервера, network hiccup, перезапуск сервісу біржі. Production система повинна автоматично відновлюватися:

Приклад реалізації RobustWebSocketClient
import asyncio import websockets from datetime import datetime class RobustWebSocketClient: def __init__(self, url: str, reconnect_delay: float = 1.0): self.url = url self.reconnect_delay = reconnect_delay self.max_reconnect_delay = 60.0 self.last_message_at = None self.stale_threshold = 30 # секунд без повідомлень = staleness async def connect_with_retry(self, on_message, on_subscribe): delay = self.reconnect_delay while True: try: async with websockets.connect( self.url, ping_interval=20, ping_timeout=10, close_timeout=5, ) as ws: await on_subscribe(ws) delay = self.reconnect_delay # скидаємо при успіху async for msg in ws: self.last_message_at = datetime.utcnow() await on_message(msg) except (websockets.ConnectionClosed, websockets.InvalidHandshake, OSError) as e: print(f"Connection error: {e}, reconnecting in {delay}s") await asyncio.sleep(delay) delay = min(delay * 2, self.max_reconnect_delay) async def staleness_watchdog(self): """Детектує зависле з'єднання без явного розриву""" while True: await asyncio.sleep(10) if self.last_message_at: elapsed = (datetime.utcnow() - self.last_message_at).seconds if elapsed > self.stale_threshold: raise RuntimeError(f"Connection stale: {elapsed}s without data") 

Експоненційна затримка перепідключення та watchdog на stale connection — обов'язковий мінімум для промислового scraping.

Як керувати order book через WebSocket?

Більшість бірж віддають order book через incremental updates — тільки змінені рівні. Локальне підтримання актуального стану order book:

Приклад класу LocalOrderBook
from sortedcontainers import SortedDict class LocalOrderBook: def __init__(self): self.bids = SortedDict(lambda k: -k) # descending self.asks = SortedDict() # ascending self.last_update_id = 0 def apply_snapshot(self, snapshot: dict): self.bids.clear() self.asks.clear() for price, qty in snapshot['bids']: self.bids[float(price)] = float(qty) for price, qty in snapshot['asks']: self.asks[float(price)] = float(qty) self.last_update_id = snapshot['lastUpdateId'] def apply_update(self, update: dict): if update['u'] <= self.last_update_id: return # застарілий update, ігноруємо for price, qty in update['b']: # bids p, q = float(price), float(qty) if q == 0: self.bids.pop(p, None) else: self.bids[p] = q for price, qty in update['a']: # asks p, q = float(price), float(qty) if q == 0: self.asks.pop(p, None) else: self.asks[p] = q self.last_update_id = update['u'] def best_bid(self) -> tuple[float, float]: k = next(iter(self.bids)) return k, self.bids[k] def best_ask(self) -> tuple[float, float]: k = next(iter(self.asks)) return k, self.asks[k] 

Важно: при старті потрібно отримати снапшот через REST, потім застосовувати WebSocket updates починаючи з lastUpdateId > snapshotId. Оновлення до снапшоту відкидаються, пропуск у послідовності Uu потребує повторного снапшоту.

Масштабування: багато пар та бірж

Одна async event loop у Python справляється з 50–200 одночасними WebSocket з'єднаннями. Для більшої кількості — кілька процесів або Go-сервіс (goroutines значно легші за asyncio tasks).

Fanout результатів: оброблені повідомлення публікуються в Redis Pub/Sub або Kafka для downstream consumers. WebSocket handler повинен мінімально обробляти дані та швидко публікувати — важку обробку робить окремий consumer.

Моніторинг здоров'я

Метрики для кожного WebSocket з'єднання: messages per second, reconnect count, last message timestamp, lag від біржевого timestamp до processing timestamp. Використовуємо Grafana + Prometheus alerting на stale connections (> 60 сек без повідомлень по активній парі).

Метрика Опис Поріг алерту
messages/sec Кількість повідомлень на секунду < 0.5 очікуваного
reconnects Кількість перепідключень за годину > 5
last_message_age Час з останнього повідомлення > 60 с
lag Затримка від біржевого часу > 500 мс

Що входить у налаштування WebSocket scraping

  • Підключення до бірж / блокчейн-нод по WebSocket (Binance, Coinbase, Kraken, Ethereum, Polygon, Solana та ін.)
  • Реалізація reconnect logic з exponential backoff та staleness watchdog
  • Локальна агрегація order book з синхронізацією через снапшоти
  • Публікація нормалізованих даних у Redis Pub/Sub або Kafka
  • Моніторинг та алерти (Grafana, Prometheus)
  • Документація з архітектури та налаштування
  • Навчання вашої команди роботі з системою

Наш досвід та гарантії

Маємо досвід реалізації понад 50 проєктів real-time scraping для криптобірж, DeFi-протоколів та NFT-маркетплейсів. Гарантуємо стабільну роботу, автоматичне відновлення після збоїв та моніторинг 24/7. Працюємо з Ethereum, Binance, Polygon, Arbitrum, Solana та іншими мережами.

Налаштування real-time парсингу для 3–5 бірж з моніторингом 20–50 пар, reconnect логікою та публікацією в Redis/Kafka займає 1–2 дні. Зв'яжіться з нами для розрахунку вартості. Замовте налаштування вже сьогодні — отримайте консультацію.