Semantica exact o dată

Ce anume-o dată este într-adevăr

• Livrare: Mesajul va fi livrat consumatorului exact o dată.
• Procesare: efectul secundar final (scrierea în baza de date, schimbarea soldului, emiterea unui alt eveniment) se va întâmpla exact o dată, chiar dacă au existat mai multe livrări sau încercări.

În sistemele distribuite, este mai fiabil să vorbim despre procesarea semanticii. Livrarea exact o dată este dificilă (duplicatele și replicile sunt inevitabile), dar starea rezultată poate fi făcută să fie echivalentă cu un singur tratament.

Când este nevoie de EOS și când nu

• Tranzacții în numerar și solduri: Nu sunt permise reduceri duble.
• Contabilitate licență/cotă, contoare de facturare.
• Apeluri externe ireversibile (de exemplu, activarea cheii unice).

• Efectele sunt reversibile sau compensabile (sagas, retururi).
• Duplicatele temporare sunt permise în storefronturi/jurnale.
• Este mai ieftin să furnizați o chiuvetă idempotentă decât să trageți tranzacțiile pe întreaga cale.

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

Hop-by-hop EOS: fiecare secțiune (sursă → procesor → receptor) garantează că își va aplica acțiunea exact o dată.
EOS end-to-end: Întregul lanț asigură că, de la „fapt” la „efect secundar”, rezultatul este echivalent cu un singur tratament.

În practică, end-to-end se realizează printr-o combinație de tranzacții și/sau idempotență pe fiecare hop.

Blocuri de bază

1. Operațiuni idempotente

Repetarea aceleiași interogări pe cheia de operare produce același rezultat.

Ключи: 'idempotency _ key '/' event _ id'/' operation _ id'.
Implementare: tabelul operațiunilor „văzut” cu TTL ≥ prezentarea jurnalului de intrare.

2. Tranzactii read-process-write

Într-o unitate atomică de lucru, se înregistrează atât efectul secundar, cât și progresul lecturii (compensări/poziție). Acest lucru elimină „fantome” atunci când se încadrează între trepte.

3. Versionare/SECVENȚĂ

O versiune/contor este stocată pentru agregat; modificările se aplică numai în cazul în care „așteptat _ versiune” meciuri. Repetițiile aceluiași eveniment nu cresc versiunea → efect o singură dată.

4. Eliminarea duplicatelor

Index pe "(consumer_id, event_id)" sau pe "business _ id' natural al tranzacției.

Modele de implementare

1) jurnal tranzacțional + chiuvetă tranzacțională cu fixare offset

Ideal pentru procesarea fluxului.

Citim din jurnal (doar intrările confirmate).
Efectuăm procesarea.

• a) scrie efectul în chiuvetă (bază de date/tabel),
• b) fixați „citiți pentru a compensa N” (în aceeași bază de date).
• Angajează-te. La repornire, fie totul este redus (și offset-ul este mutat), sau nimic.

Proprietăți: execuția repetată nu este dăunătoare; „exact o dată” în vigoare, chiar dacă mesajul a fost citit de două ori.

2) Outbox + consumator idempotent

Pentru servicii tranzactionale de producator.

Într-o singură tranzacție de baze de date: schimbați înregistrarea domeniului și scrieți evenimentul în outbox.
Repetorul livrează evenimentul autobuzului cu același 'event _ id'.
Consumatorii aplică evenimentele idempotent (dedup prin 'event _ id').

Proprietăți: Producătorul asigură că nu se pierde niciun fapt; consumatorii garantează exact un efect.

3) EOS în sistemele Kafka/Flink (conceptual)

Producător idempotent: protejează împotriva preluărilor la trimiterea retragerilor.
Tranzacții de producător: un grup de intrări în subiecte + o schimbare a consumului sunt comise atomic; cititorii folosesc 'read _ committed' isolation.
Partea de procesare stochează magazinul de stat și îl angajează împreună cu tranzacția.

Proprietăți: Re-pornirea magazinului/drag nu duce la un efect dublu; duplicate „nu sunt vizibile” în aval.

4) Idempotent „chiuvete” prin upsert/îmbinare

Chiuveta ia 'operation _ id'/' event _ id' și execută' UPSERT... ACOLO UNDE NU EXISTĂ.
Efectul secundar (de exemplu, acumulare) se efectuează atomic cu verificarea „nu a fost deja aplicată”.

Proprietăți: metodă EOS ieftină la margine cu stocare, fără tranzacții distribuite.

Detalii cheie de implementare

ID-uri de tranzacție

Trebuie să fie determinist pentru repetări (nu genera un nou UUID atunci când se retrage).
Au un domeniu de aplicare stabil (pe consumator/unitate/sistem).

Tabel de eliminare a duplicatelor

Колонки: 'consumer _ id',' operation _ id', 'applied _ at', 'tl _ expires _ at'.
Indexuri pe „(consumer_id, operation_id)”.
TTL ≥ fereastra maximă de repetare (retenție jurnal + întârzieri potențiale).

Concurență optimistă

În modelul de scriere, stocați versiunea unității.
Atunci când aplicați un eveniment/comandă, utilizați 'WHERE version =: așteptat'; duplicat nu va crește versiunea.

Comandă/comandă

EOS nu este "exact același ordin. "Asigurați coerența prin intermediul tastei lotului (toate evenimentele agregate →-un singur lot) și/sau comparația" echivalență ".

Apeluri externe idempotente

Pentru metode nesigure (de exemplu, HTTP webhooks la un serviciu terț), adăugați „Idempotency-Key” și solicitați partenerului să-l sprijine.

Capcane frecvente

EOS într-un singur loc: dacă chiuveta este idempotentă, dar emiteți evenimente secundare fără idempotență, veți obține „exact de multe ori” în aval.
Două comite: mai întâi în baza de date, apoi offset-ul se angajează în broker - căderea dintre ele creează efecte duplicate.
CDC-uri brute: Schimbarea sistemului DB întrerupe idempotența consumatorilor.
Chei instabile: "operation _ id' depinde de timp/aleatoriu și modificări în timpul retray.

Costuri și compromisuri

Latență: tranzacții/citiri izolate → creșterea p95/p99.
Stocare aeriană: tabele de eliminare a duplicatelor, magazine de stat, jurnale de tranzacții.
Complexitatea operațională: temporizări de tranzacție, reechilibrarea firului, sesiuni blocate.
Diagnosticare: mai multe stări („în kamit”, „vizibil ca read_committed,” „laminat înapoi”).

Alegeți punctul de vedere EOS: pentru agregate și efecte critice; acoperă restul cu idempotență și compensație.

Testarea exact o dată

1. Injecție de eroare: scăderea procesului între etapele „a înregistrat efectul” și „a înregistrat offsetul”.
2. Duplicate: descărcați același mesaj de 2-5 ori, asigurați-vă de un singur efect.
3. Reporniri și reechilibre: oprirea/repornirea lucrătorilor, verificarea absenței procesării duble.
4. Flappies de rețea: timeout-uri de tranzacție medie, comite din nou.
5. Teste de sarcină: creșterea cozii → dacă nu există nici o degradare a „pentru totdeauna în tranzacție”.

Mini șabloane (Pseudo)

Chiuvetă Idempotent cu fixare 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

Comandă cu versiunea unității

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

Siguranță și conformitate

PII/PCI în tabelele de eliminare a duplicatelor: stocați un minim, utilizați jetoane în loc de date brute.
Audit: log 'operation _ id',' trace _ id', rezultat (APPLIED/ALREADY_APPLIED).
Politica de stocare: TTL pe tabelele dedup, arhivarea compensărilor/jurnalelor.

Anti-modele

„Livrare reală exactă”: o încercare de a exclude duplicatele la nivelul protocolului de transport fără idempotență de efect.
Tranzacții globale distribuite pentru orice: XA/2PC prin toate serviciile este fragilă și lentă.
Amestecarea efectelor secundare non-idempotente (de exemplu, e-mail trimis înainte de comiterea offset).
Lipsa cheilor de funcționare: bazându-se pe „unicitatea” sarcinii utile.

Lista de verificare a producției

Fiecare efect critic are o cheie idempotentă.

• Poziția offset/read este fixată într-o singură tranzacție cu efect.
• Tabele de eliminare a duplicatelor indexate; Păstrarea jurnalului ≥ TTL.
• Concurența optimistă (versiune/secvență) este activată pentru agregate.
• Threads/Topics sunt citite în modul „Rep Only” (dacă este disponibil).
• Testele duplicat și drop sunt prezente în CI/CD.
• Tablouri de bord: cota de repetiții, tranzacții eșuate, timp de blocare, lag-uri.
• Documentația integratorului pentru 'Idempotency-Key '/retries/timeout.

ÎNTREBĂRI FRECVENTE

EOS poate fi furnizat fără tranzacții?
Adesea da - prin idempotența chiuvetei (upsert/fuziune) și versionarea agregatelor. Tranzacțiile simplifică garanțiile, dar cresc costurile.

Are toată lumea nevoie de exact-o dată?
Nu, nu este. Este scump. Aplicați pointwise în cazul în care compensația nu este posibilă/costisitoare.

Cum se asociază scrisorile/cărțile web cu EOS?
Tamponați notificarea înainte de comitere, trimiteți după fixarea efectului; stoca 'notification _ id' și de a face trimiterea idempotent.

Ce este mai important - livrare sau procesare?
Prelucrare. Livrările pot fi repetate; starea finală trebuie să fie corectă și singura.

Rezultat

Exact-o dată este despre corectitudinea efectului, și nu despre absența duplicatelor în cabluri. Se realizează printr-o combinație de idempotență, fixarea atomică a efectului și progresul lecturii, disciplina de partiționare și versionare rezonabilă. Aplicați EOS în cazul în care costul de eroare este inacceptabil, și testați realitatea cu căderi și ia teste - nici o credință în transport.