Sistema di gestione Multi-Kline per l’automazione del trading su larga scala

Panoramica

Il sistema Multi-Kline Management permette a MagicTradeBot di caricare, memorizzare in cache e mantenere in modo efficiente i dati candlestick (kline) su più timeframe per centinaia di migliaia di simboli di trading contemporaneamente, rispettando rigorosamente i limiti di rate delle API degli exchange. Questa funzionalità supporta strategie di trading molto diverse — dallo scalping ad alta frequenza al position trading a lungo termine — tutte eseguite in parallelo con isolamento completo.

Funzionalità principali

Caricamento degli intervalli basato sulla strategia

Il bot carica dinamicamente i dati kline in base al tipo di strategia attiva. Ogni strategia ha timeframe ottimali predefiniti:

Intervalli per strategia:

  • HFT (High-Frequency Trading): 1m – Esecuzione ultraveloce sui movimenti al minuto
  • Scalp: 15m – Operazioni di momentum breve termine su grafici a 15 minuti
  • Day Trading: 15m, 30m, 1h, 2h, 4h – Analisi intraday su più timeframe
  • Swing Trading: 1h, 2h, 4h, 6h, 12h – Pattern di più ore per entrate in posizione
  • Long-Term: 1d – Grafici giornalieri per analisi macro delle tendenze
  • Default: 5m, 15m, 1h – Approccio multi-timeframe bilanciato

Ogni simbolo può avere uno o più intervalli caricati contemporaneamente in base alla strategia assegnata, consentendo conferme multi-timeframe mantenendo alta efficienza di memoria.

Gestione intelligente dei rate limit

Throttling adattivo delle richieste

Il sistema implementa un algoritmo sofisticato che rispetta le restrizioni delle API degli exchange:

  • maxRequestsPerSecond: 10 – Limite rigido dell’exchange al secondo
  • safeBuffer: 0.2 – Margine di sicurezza (usa l’80% della capacità massima)
  • Tasso effettivo: 8 richieste/secondo (10 × 0.8)

Strategia di distribuzione delle richieste

Elaborazione a chunk di simboli:

  • chunk_size: 20 – Simboli prelevati per ciclo di aggiornamento
  • Distribuisce centinaia di migliaia di simboli nel tempo
  • Previene violazioni di burst API
Tempo elaborazione chunk = chunk_size / tasso_effettivo
Esempio: 20 simboli / 8 req/s = 2,5 secondi per chunk

Ciclo di refresh:

  • kline_refresh_rate: 7 secondi tra cicli completi
  • Garantisce freschezza continua dei dati senza sovraccaricare le API
  • Inserimento adattivo di delay in base ai tempi di risposta

Supporto multi-exchange

  • Binance: 1200 richieste/minuto (20/sec)
  • OKX: 20 richieste/2 secondi
  • Bybit: 120 richieste/5 secondi

Il bot regola automaticamente maxRequestsPerSecond in base all’exchange rilevato.

Archiviazione kline a basso consumo di memoria

Approccio a finestra scorrevole

Per gestire enormi quantità di simboli senza esaurire la RAM:

  • Gestione kline per simbolo:
    • max_kline_length: 100 – Numero massimo di candele mantenute per intervallo
    • Buffer circolare (FIFO)
    • Le candele vecchie vengono automaticamente eliminate all’arrivo delle nuove
Oggetto Kline singolo: ~200 byte
Per simbolo (5 intervalli × 100 candele): ~100 KB
100.000 simboli: ~10 GB di footprint totale

Lazy loading & caching

  • Caricamento iniziale recupera l’intera history max_kline_length
  • Aggiornamenti successivi richiedono solo le ultime candele
  • Cache in memoria con espulsione LRU per simboli inattivi
  • Simboli inattivi da 24 ore vengono automaticamente rimossi dalla memoria

Esecuzione concorrente delle strategie

Mapping simbolo-strategia

BTCUSDT:
  strategy: "day"
  intervals: ["15m", "1h", "4h"]
 
ETHUSDT:
  strategy: "scalp"
  intervals: ["15m"]
XRPUSDT:
  strategy: "swing"
  intervals: ["1h", "4h", "12h"]

Elaborazione segnali isolata

  • signal_refresh_interval: 20 secondi (configurabile per strategia)
  • Scalp → ogni 20 secondi
  • Long-term → ogni 1800 secondi (30 min)

Ogni simbolo calcola i propri indicatori in modo indipendente, senza contaminazione tra strategie. Le attività pesanti per la CPU vengono eseguite in parallelo da worker thread.

Architettura di scalabilità

Recupero distribuito delle kline

Sistema a coda prioritaria:

  1. Simboli alta priorità (trade attivi)
  2. Priorità media (segnali forti)
  3. Bassa priorità (solo monitoraggio)
  4. Dati obsoleti (non aggiornati da più di 2× il refresh rate)

Ottimizzazione richieste batch:

  • Una singola chiamata API può recuperare più intervalli dello stesso simbolo
  • Riduce il numero totale di richieste di circa il 40%
  • Utilizza endpoint batch specifici per exchange

Tolleranza ai guasti

  • Rate limit raggiunto → backoff esponenziale (2x, 4x, 8x)
  • Richiesta fallita → fino a 3 tentativi
  • Errori persistenti → simbolo temporaneamente disabilitato
  • Perdita connessione → richieste accodate fino al ripristino

La validazione dei dati include:

  • Rilevamento gap di timestamp
  • Rilevamento anomalie di prezzo
  • Backfill automatico
  • Esclusione dati obsoleti

Ottimizzazioni delle prestazioni

Workflow del ciclo di aggiornamento

Ogni ciclo di refresh (ogni 7 secondi):

  1. Fase di selezione (0,1 s)
  2. Fase di recupero (2,5 s)
  3. Fase di elaborazione (1,5 s)
  4. Fase idle (2,9 s)

Throughput totale:

  • 2,86 simboli/secondo
  • 10.285 simboli aggiornati all’ora
  • 100.000 simboli aggiornati ogni ~9,7 ore

Ottimizzazioni specifiche per strategia

  • Scalp: refresh più rapido, buffer più piccoli
  • Long-Term: refresh più lento, buffer standard

Best practice di configurazione

Portafoglio piccolo (<1.000 simboli)

chunk_size: 50
kline_refresh_rate: 5
maxRequestsPerSecond: 15
safeBuffer: 0.3

Portafoglio medio (1.000–10.000 simboli)

chunk_size: 20
kline_refresh_rate: 7
maxRequestsPerSecond: 10
safeBuffer: 0.2

Portafoglio grande (>100.000 simboli)

chunk_size: 10
kline_refresh_rate: 10
maxRequestsPerSecond: 8
safeBuffer: 0.15
max_kline_length: 50

Tuning specifico per exchange

  • Binance: chunk più grandi, refresh più veloce
  • Exchange restrittivi: chunk più piccoli, refresh più lento

Esempio reale

Scenario: Trading di 50.000 simboli su Binance

chunk_size: 25
kline_refresh_rate: 8
maxRequestsPerSecond: 12
safeBuffer: 0.2
max_kline_length: 80

Prestazioni:

  • Tasso effettivo: 9,6 req/sec
  • Elaborazione chunk: 2,6 secondi
  • Refresh completo: ogni ~4,4 ore
  • Consumo memoria: ~8 GB
  • API/giorno: ~275.000

Analisi di riepilogo

L’impostazione summary_interval: "1d" fornisce statistiche giornaliere:

  • Totale simboli monitorati
  • Utilizzo API
  • Percentuale utilizzo rate limit
  • Freschezza dei dati
  • Segnali per strategia
  • Consumo memoria

📎 Related Topics