Comunicazione asincrona

La comunicazione su un flusso è asincrona e bidirezionale. Il tuo client invia i record continuamente senza aspettare che ciascuno venga confermato, e il server invia conferme di conferma sulla stessa connessione man mano che i record diventano sostenibili. Questo disaccoppiamento è ciò che consente a un singolo client di mantenere un throughput elevato: continua a inviare dati mentre le conferme arrivano in secondo piano.

Offset e il ciclo di conferma

Ogni sottomissione su un flusso, sia essa un singolo record o un lotto, viene assegnato un offset logico che ne segna la posizione in quel flusso. Invece di confermare ogni invio singolarmente, il server segnala il progresso cumulativo della durabilità tramite l'offset confermato più alto che ha reso durabile finora. Poiché gli offset sono ordinati, una conferma conferma quell'invio e tutti quelli precedenti.

Questo è il loop di conferma, ed è ciò che mantiene la connessione sia veloce che affidabile:

1. Il client invia i record e li conserva in un buffer locale durante il volo.
2. Il server persiste i registri in modo duraturo e periodicamente invia indietro il più alto offset commesso.
3. Ricevuto quell'offset, il client elimina in sicurezza tutti i record nel buffer fino a quell'offset, perché tali record sono ora durevoli.

Quando usi un SDK Zerobus Ingest, l'SDK esegue questo ciclo per te. Traccia gli offset, mantiene il buffer in volo e processa confermi in background mentre il produttore continua a spingere. Non implementi il ciclo da solo. Quello che controlli opzionalmente è come osservi la durabilità:

• Continua a inviare; l'SDK processa i confermi man mano che arrivano.
• Blocca un offset solo quando la tua domanda deve aspettare che un record specifico sia duraturo. Vedere di seguito.
• Registra un callback di conferma per gestire conferme ed errori in modo asincrono, senza bloccare. Vedi richiami ai riconoscimenti.

Implementeresti tu stesso il loop di offset-tracking e buffering solo se costruisci un client personalizzato che non utilizza un SDK.

Il buffer in volo è limitato da un limite configurabile di record in volo. L'ingestione è asincrona fino a quando il buffer non si riempie; a quel punto, le chiamate di ingestione si bloccano finché non arrivano le conferme di ricezione e non si libera spazio. Regola il limite per il carico di lavoro e tieni presente che i record bufferizzati consumano memoria client mentre sono in volo. Per l’opzione e il relativo valore predefinito, consulta il repository di Zerobus SDK.

Se la connessione viene interrotta, i record ancora nel buffer in volo (quelli oltre l'ultimo offset commesso) non sono stati confermati duraturi, quindi possono essere riprodotti. Vedi i modelli di recupero e di nuovo tentativo.

Il riconoscimento conferma la durabilità, non l'interrogabilità. Un offset deciso significa che quei record vengono mantenuti in modo duraturo e non andranno persi. Zerobus Ingest materializza record durevoli nella tabella Delta come passaggio separato poco dopo, a quel punto i dati diventano consultabili in circa 5 secondi. Per maggiori informazioni sulla latenza, vedi Latenza.

Aspettare un record contro massimizzare la velocità di lavoro

Si attende l'offset di un record quando l'applicazione deve bloccare l'ulteriore esecuzione finché non si sa con certezza che quello specifico record sia stato reso persistente, ad esempio prima di confermare il completamento dell'elaborazione a un sistema a monte. L'attesa riguarda la sincronizzazione a livello applicativo, non un requisito di durabilità. Un record diventa duraturo attraverso il ciclo di conferma, che tu lo blocchi o meno.

Il blocco ha un costo di throughput:

• Attendere dopo ogni record trasforma l'ingestione in un flusso di lavoro di fatto sincrono. Bloccare ogni messaggio prima di inviare il successivo impedisce al client di raggiungere la piena capacità di Zerobus Ingest.
• L'ingestione ad alta produttività è continua e asincrona. Il client continua a inviare i record mentre arrivano i riconoscimenti per gruppi di record precedenti, invece di fermarsi su ciascuno di essi. Aspetta un offset specifico solo nei checkpoint dove la tua applicazione ha davvero bisogno di quella garanzia, oppure usa un acknowledgment callback per monitorare i progressi senza bloccare.

Per i metodi di ingestione, quando bloccare su un offset e come funzionano i callback di conferma, vedi Blocco e conferma dei messaggi.

Ordinare su un flusso

Le conferme di ricezione e gli offset sono specifici di ciascuno stream: l'ordine è garantito all'interno di un singolo stream, non globalmente tra stream diversi. Per capire come funziona l'ordine per stream e come progettare attorno ad esso, vedi Garanzie di ordinazione.