Exactly-once semantica

Cosa è effettivamente exactly-once

• Consegna: il messaggio verrà inviato al consumatore esattamente una volta.
• Elaborazione: l'effetto collaterale finale (scrittura nel database, bilanciamento, emissione di un altro evento) avverrà esattamente una volta, anche se le consegne o i tentativi sono stati maggiori.

Nei sistemi distribuiti è più affidabile parlare di semantica di elaborazione. La consegna è una sola volta difficile da fornire (duplicati e ripetizioni sono inevitabili), ma si può fare in modo che lo stato finale sia equivalente all'unica lavorazione.

Quando EOS è necessario e quando no

• Transazioni in denaro e bilanci: il doppio prelievo non è valido.
• Registrazione licenze/quote, contatori in bilingue.
• Chiamate esterne irreversibili, ad esempio l'attivazione singola della chiave.

• Gli effetti sono reversibili o compensabili (saghe, restituzioni).
• Sono consentiti i duplicati temporanei nelle vetrine o nei fogli.
• È più economico fornire un sink idipotente che trascinare transazioni attraverso l'intero tratto.

Modello: end-to-end vs. hop-by-hop

Hop-by-hop EOS: ogni pezzo (sorgente, processore, ricevitore) garantisce che la sua azione venga applicata esattamente una volta.
End-to-end EOS - L'intera catena garantisce che dal fatto all'effetto side il risultato sia equivalente all'unica lavorazione.

In pratica, end-to-end è raggiunto da una combinazione di transazioni e/o idampotenza su ogni hop.

Blocchi di costruzione di base

1. Operazioni idipotenti

Ripetere la stessa richiesta di chiave di un'operazione ha lo stesso effetto.

Ключи: `idempotency_key`/`event_id`/`operation_id`.
Implementazione: tabella delle operazioni «viste» con TTL di ritenzione del cavo di input.

2. Transazioni «lettura-elaborazione-scrittura» (read-process-write)

Una singola unità di lavoro atomica registra l'effetto collaterale e il progresso della lettura (offset/posizione). Questo elimina i fantasmi quando cadono tra i passi.

3. Versioning/SEQUENCE

Per l'unità viene memorizzata la versione/contatore; le modifiche si applicano solo se 'expected _ version'corrisponde. Ripetizioni dello stesso evento non aumentano la versione dell'effetto → una volta sola.

4. Deduplicazione

Indice per '(consumer _ id, event _ id)' o per operazione naturale 'business _ id'.

Modelli di implementazione

1) Loga transazionale + sink transazionale con fissazione offset

Ideale per il processore strim.

Leggiamo dal tasto (solo voci confermate).
Stiamo eseguendo l'elaborazione.

• a) scriviamo l'effetto in un link (database/tabella),
• b) fissiamo «letto prima dell'offset N» (nello stesso database).
• Commit. In caso di restart, tutto è sigillato (e l'offset viene spostato) o niente.

Proprietà: l'esecuzione non è dannosa; «esattamente una volta» per effetto, anche se il messaggio è stato letto due volte.

2) Outbox + idipotente

Per i servizi di produzione di transazioni.

In una transazione database, modificare il record di dominio e scrivere l'evento in outbox.
Il replicatore consegna l'evento al bus con lo stesso «event _ id».
I concimatori applicano gli eventi in modo idempotente (deduzione dì event _ id ").

Proprietà: il produttore garantisce che il fatto non si perda; Le consolle garantiscono esattamente un effetto.

3) EOS in sistemi simili Kafka/Flink (concettuale)

Produttore Idempotent: protegge dalle riprese durante i ritai di invio.
Transazioni produttore: gruppo di record in topic + cambio consumatore si commette atomonicamente; i lettori usano'read _ committed '.
Il lato del processore memorizza lo stato (state store) e lo commette insieme alla transazione.

Proprietà: riavviare lo store/porta non produce un doppio effetto; duplicati «non visibili» downstream.

4) «siki» idempotenti (sinks) tramite upsert/merge

Sink accetta "operation _ id "/" event _ id" e esegue "UPSERT... WHERE NOT EXISTS`.
L'effetto collaterale (ad esempio, l'addebito) viene eseguito in modo atomico con il controllo «non è già stato applicato».

Proprietà: EOS a basso costo al limite dello storage, senza transazioni distribuite.

Dettagli chiave per l'implementazione

ID operazione

Devono essere determinati per le ripetizioni (non generare un nuovo UUID durante il retro).
Avere un'area di visibilità resistente (per la combinazione/per l'aggregazione/per il sistema).

Tabella di deduplicazione

Колонки: `consumer_id`, `operation_id`, `applied_at`, `ttl_expires_at`.
Indici per '(consumer _ id, operation _ id)'.
Il TTL è collegato alla finestra massima di ripetizione (ritenzione del login + ritardi potenziali).

Concorrenza ottimistica

Nel modello write, memorizzare la versione dell'aggregazione.
Quando si applica un evento/comando, usà WHERE variante =: expected '; il duplicato non aumenterà la versione.

Ordine/ordine

L'EOS non è uguale allo stesso ordine. Assicurati la consistenza attraverso la chiave di partitura (tutti gli eventi dell'unità sono una partitura) e/o il confronto «sequence».

Chiamate esterne idipotenti

Per i metodi non sicuri (ad esempio, webhoop HTTP in un servizio di terze parti) aggiungete «Idempotency-Key» e richiedete che il partner lo supporti.

Trappole frequenti

EOS è in un solo punto: se il sink è idempotentato, ma si emettono eventi secondari senza idampotenza, si ottiene «molte volte» downstream.
Due committenti, prima nel database, poi nel broker, una caduta tra di loro crea effetti duplicati.
CDC crudi verso l'esterno: la modifica dello schema di database rompe l'idimpotenza dei consumatori.
Chiavi instabili: «operation _ id» dipende dal tempo/random e cambia in caso di retrai.

Costi e compromessi

Latenza: transazioni/letture isolate → p95/p99.
Overhead dello storage: tabelle di deduplicazione, state stores, logi di transazione.
Complessità operativa: timeout delle transazioni, ricalance dei flussi, sessioni «piene».
Diagnostica: più stati («in camita», «visibile come read _ committed», «ritroso»).

Selezionare l'EOS per le unità e gli effetti critici. il resto è coperto da idipotenza e risarcimenti.

Test exactly-once

1. Fault-injection - La caduta del processo tra i passaggi «ha registrato l'effetto» e «ha rilevato l'offset».
2. Duplicati: pompare lo stesso messaggio 2-5 volte, verificare un unico effetto.
3. Restart e rebalance: arresto/riavvio dei worker, verifica che non sia stata eseguita una doppia lavorazione.
4. Flappy di rete: timeout a metà transazione, ripetizione commit.
5. Test di carico: la crescita delle code, se il degrado è «per sempre nella transazione».

Modelli minimi (pseudo)

Sink Idempotent con fissaggio offset

pseudo begin tx if not exists(select 1 from dedup where consumer_id=:c and op_id=:id)
then apply_effect(...)    -- upsert / merge / add_one_time_action insert into dedup(c, id, applied_at) values(:c,:id, now)
end if update offsets set pos=:pos where consumer_id=:c commit

Comando con versione dell'aggregazione

pseudo begin tx update account set balance = balance +:delta,
version = version + 1 where id=:account_id and version=:expected_version;
if row_count=0 then error CONCURRENT_MODIFICATION commit

Sicurezza e compilazione

PII/PCI nelle tabelle di deduplicazione: conservare il minimo, utilizzare i token invece dei dati crudi.
Controllo: logica «operation _ id», «trace _ id», esito (APPLIED/ALREADY _ APPLIED).
Criteri di conservazione: TTL nelle tabelle di deducibilità, archiviazione di offset/login.

Anti-pattern

«Presente spedizione exactly-once» - Tentativo di escludere le riprese a livello di protocollo di trasporto senza l'idipotenza dell'effetto.
Transazioni distribuite globalmente su tutto: XA/2PC attraverso tutti i servizi è fragile e lento.
Miscelare i collaterali non identificati (ad esempio, e-mail inviata prima del commit offset).
Nessuna chiave di operazione: affidamento all'unicità del carico utile.

Assegno foglio di produzione

• Ogni effetto critico ha una chiave idipotente.
• L'offset/posizione di lettura viene registrato in una singola transazione con effetto.
• Le tabelle di deduplicazione sono indicizzate; La TTL è stata ritrattata.
• Le unità includono una concorrenza ottimistica (versione/sequence).
• I flussi/topici vengono letti in modalità «solo sottozero» (se disponibile).
• I test di duplicazione e caduta sono presenti in CHI/CD.
• Dashboard: percentuale di ripetizioni, transazioni non riuscite, tempi di blocco, laghe.
• Documentazione per gli integratori dì Idempotency-Keu '/ripetizioni/timeout.

FAQ

È possibile fornire EOS senza transazioni?
Spesso sì - attraverso l'idampotenza del sink'ov (upsert/merge) e la versioning degli apparecchi. Le transazioni semplificano le garanzie, ma aumentano i costi.

Tutti hanno bisogno dì exactly-once "?
No, no. È costoso. Usate i punti dove il risarcimento è impossibile/strada.

Come collegare email/webhoop a EOS?
Tampona la notifica prima del commit, invia dopo aver bloccato l'effetto; memorizzate'notification _ id ', e fare in modo che l'invio sia idipotente.

Cosa c'è di più importante, consegna o lavorazione?
Elaborazione. Le consegne possono ripetersi; lo stato finale deve essere corretto e unico.

Totale

Exactly-once è la correttezza dell'effetto, non la mancanza di riprese nel cablaggio. Essa è raggiunta da una combinazione di idempotenza, fissazione atomatica degli effetti e progresso della lettura, partizionamento intelligente e disciplina di versioning. Utilizzare EOS dove il costo dell'errore è inaccettabile e verificare la realtà con test di caduta e ripresa - non credere nei trasporti.