Introduzione
Quando si elabora dati in streaming, massimizzare il tempo di connessione e ricevere tutti i dati corrispondenti è un obiettivo fondamentale. Ciò significa che è importante sfruttare connessioni ridondanti, rilevare automaticamente le disconnessioni, riconnettersi rapidamente e avere un piano per il recupero dei dati persi. In questa guida all’integrazione, illustreremo diverse funzionalità di ripristino e ridondanza: connessioni ridondanti, backfill e recovery. Connessioni ridondanti Una connessione ridondante consente di stabilire più di una connessione simultanea al filtered stream. Questo garantisce ridondanza permettendoti di connetterti allo stesso stream con due consumer distinti, ricevendo gli stessi dati su entrambe le connessioni. In questo modo, la tua App dispone di un hot failover per varie situazioni, ad esempio se uno stream si disconnette o se il server primario della tua applicazione ha un guasto. Filtered stream attualmente consente solo ai Project con accesso Enterprise di connettersi con un massimo di due connessioni ridondanti. Per utilizzare uno stream ridondante, è sufficiente connettersi allo stesso URL usato per la connessione primaria. I data per il tuo stream verranno inviati attraverso entrambe le connessioni.Recupero dei dati mancati dopo una disconnessione: Backfill
Dopo aver rilevato una disconnessione, il tuo sistema dovrebbe essere in grado di riconnettersi allo stream. Se possibile, dovrebbe anche registrare la durata della disconnessione, così da poter utilizzare la funzione di recupero appropriata per eseguire il backfill dei dati. Se stai utilizzando un Project con accesso Enterprise e hai verificato che la disconnessione è durata cinque minuti o meno, puoi utilizzare il parametro di backfill, backfill_minutes. Se includi questo parametro nella richiesta GET /tweets/search/stream, riceverai i Post che corrispondono alle tue regole relativi all’ultimo intervallo compreso tra uno e cinque minuti. In genere consegniamo prima questi Post meno recenti rispetto a quelli di nuova corrispondenza e non eseguiamo la deduplicazione dei Post. Ciò significa che, se sei stato disconnesso per 90 secondi ma richiedi due minuti di backfill, riceverai 30 secondi di Post duplicati, che il tuo sistema dovrebbe gestire senza problemi. Ecco un esempio di come potrebbe apparire una richiesta con il parametro di backfill:curl 'https://api.x.com/2/tweets/search/stream?backfill_minutes=5' -H "Authorization: Bearer $ACCESS_TOKEN"
Se non hai accesso Enterprise oppure hai riscontrato che la disconnessione è durata più di cinque minuti, puoi utilizzare il recent search endpoint o la funzione di recovery per richiedere i dati mancati. Tieni però presente che gli endpoint di ricerca dei Post non includono gli operatori sample:, bio:, bio_name: o bio_location:, e presentano alcune differenze nel comportamento di corrispondenza quando si utilizzano accenti e diacritici con gli operatori keyword e #hashtag. Queste differenze potrebbero comportare il mancato recupero completo di tutti i Post che sarebbero stati ricevuti tramite gli endpoint di filtered stream.
Recupero dei dati mancati dopo una disconnessione: Recovery
Se stai utilizzando un Project con accesso Enterprise, puoi utilizzare la funzione Recovery per recuperare i dati mancati entro le ultime 24 ore se non riesci a riconnetterti entro la finestra di backfill di 5 minuti.
La funzione di recovery dello streaming ti consente di disporre di una finestra di backfill estesa a 24 ore. Recovery ti permette di “riprodurre” l’intervallo temporale dei dati mancati. Uno stream di recovery viene avviato quando effettui una richiesta di connessione utilizzando i parametri di richiesta ‘start_time’ ed ‘end_time’. Una volta connesso, Recovery ritrasmetterà l’intervallo indicato e quindi si disconnetterà.
Puoi effettuare 2 richieste concorrenti a Recovery nello stesso momento, ossia “due job di recovery”. Recovery funziona tecnicamente allo stesso modo del backfill, tranne per il fatto che vengono definiti un orario di inizio e uno di fine. Un periodo di recovery riguarda un singolo intervallo temporale.
| Nome | Tipo | Descrizione |
| start_time | date (ISO 8601) | YYYY-MM-DDTHH:mm:ssZ (ISO 8601/RFC 3339). Data e ora in UTC che indica l’istante iniziale da cui recuperare. |
| end_time | date (ISO 8601) | YYYY-MM-DDTHH:mm:ssZ (ISO 8601/RFC 3339). Data e ora in UTC che indica l’istante finale fino a cui recuperare. |