Exactly-once Semantik

Was exactly-once wirklich ist

• Lieferung: Die Nachricht wird dem Verbraucher genau einmal zugestellt.
• Verarbeitung: Der letzte Nebeneffekt (DB-Eintrag, Bilanzänderung, Emission eines anderen Ereignisses) tritt genau einmal auf, auch wenn es mehr Lieferungen oder Versuche gab.

In verteilten Systemen ist es zuverlässiger, über die Semantik der Verarbeitung zu sprechen. Es ist schwierig, genau einmal zu liefern (Duplikate und Wiederholungen sind unvermeidlich), aber Sie können sicherstellen, dass der endgültige Zustand einer einzigen Verarbeitung entspricht.

Wann EOS gebraucht wird und wann nicht

• Geldtransaktionen und Bilanzen: Eine doppelte Belastung ist nicht zulässig.
• Lizenz-/Kontingentbuchhaltung, Abrechnungszähler.
• Irreversible externe Anrufe (z. B. einmalige Schlüsselaktivierung).

• Die Effekte sind reversibel oder kompensierbar (Sagas, Retouren).
• Temporäre Duplikate in Vitrinen/Logs sind erlaubt.
• Es ist billiger, einen idempotenten Sink bereitzustellen, als Transaktionen durch den gesamten Pfad zu ziehen.

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

Hop-by-Hop EOS: Jeder Abschnitt (Quelle → Prozessor → Empfänger) stellt sicher, dass er seine Aktion genau einmal anwendet.
Ende-zu-Ende-EOS: Die gesamte Kette stellt sicher, dass das Ergebnis von „Fakt“ bis „Seiteneffekt“ einer einzigen Verarbeitung entspricht.

In der Praxis wird End-to-End durch eine Kombination von Transaktionen und/oder Idempotenz auf jedem Hop erreicht.

Grundbausteine

1. Idempotente Operationen

Wenn Sie dieselbe Abfrage mit dem Aktivitätsschlüssel wiederholen, erhalten Sie dasselbe Ergebnis.

Ключи: `idempotency_key`/`event_id`/`operation_id`.
Implementierung: Tabelle der „gesehenen“ Operationen mit TTL ≥ Retention des Eingabeprotokolls.

2. Die Transaktion "lese-bearbeite-schreibe ich" (read-process-write)

In einer atomaren Arbeitseinheit werden sowohl der Nebeneffekt als auch der Lesefortschritt (Offset/Position) erfasst. Dadurch werden „Geister“ eliminiert, wenn sie zwischen den Schritten fallen.

3. Versionierung/SEQUENCE

Für die Einheit wird die Version/der Zähler gespeichert; Änderungen werden nur angewendet, wenn 'expected _ version' übereinstimmt. Wiederholungen des gleichen Ereignisses erhöhen die Version → den Effekt nicht einmal.

4. Deduplizierung

Index durch'(consumer_id, event_id) 'oder durch natürliche' business _ id 'Operation.

Implementierungsmuster

1) Transaktionsprotokoll + Transaktionssink mit Offsetfixierung

Ideal für die Stream-Verarbeitung.

Wir lesen aus dem Protokoll (nur bestätigte Einträge).
Wir führen die Bearbeitung durch.

• a) wir schreiben den Effekt in sink (DB/Tabelle),
• b) wir fixieren „gelesen vor Offset N“ (in der gleichen DB).
• Commit. Beim Restart ist entweder alles kommentiert (und der Offset verschoben) oder nichts.

Eigenschaften: wiederholte Ausführung schadet nicht; „genau einmal“ im Effekt, auch wenn die Nachricht zweimal gelesen wurde.

2) Outbox + idempotenter Consumer

Für transaktionale Produzentendienste.

In einer DB-Transaktion: Ändern Sie den Domäneneintrag und schreiben Sie das Ereignis in die Outbox.
Der Repulierer liefert das Ereignis mit der gleichen 'event _ id' an den Bus.
Consumer wenden Ereignisse idempotent an (Dedup durch 'event _ id').

Eigenschaften: Der Hersteller garantiert, dass die Tatsache nicht verloren geht; Die Verbraucher garantieren genau einen Effekt.

3) EOS in Kafka/Flink-ähnlichen Systemen (konzeptionell)

Idempotent Producer: schützt vor Takes bei Retrays des Versands.
Produzententransaktionen: eine Gruppe von Einträgen in Topics + Consumer Shift werden atomar ausgeführt; Leser verwenden die Isolation 'read _ committed'.
Die Verarbeitungsseite speichert den Status (state store) und löst ihn zusammen mit der Transaktion aus.

Eigenschaften: Wiederanlauf von Stor/Tasca führt nicht zu Doppeleffekt; Duplikate sind im Downstream „nicht sichtbar“.

4) Idempotente „Siki“ (sinks) durch upsert/merge

Sink akzeptiert 'operation _ id '/' event _ id' und führt 'UPSERT... WHERE NOT EXISTS`.
Die Nebenwirkung (z.B. Anrechnung) wird atomar mit der Prüfung „ob nicht schon beantragt wurde“ ausgeführt.

Eigenschaften: günstige EOS-Methode an der Grenze zum Tresor, keine verteilten Transaktionen.

Wesentliche Details der Umsetzung

Transaktions-IDs

Muss für Wiederholungen bestimmt werden (erzeugen Sie keine neue UUID beim Retrace).
Haben Sie einen stabilen Sichtbereich (pro Consumer/pro Aggregat/pro System).

Deduplizierungstabelle

Колонки: `consumer_id`, `operation_id`, `applied_at`, `ttl_expires_at`.
Indizes nach'(consumer_id, operation_id)'.
TTL ≥ das maximale Wiederholungsfenster (Log-Retention + mögliche Verzögerungen).

Optimistischer Wettbewerb

Speichern Sie im Schreibmodell die Version des Aggregats.
Wenn Sie ein Ereignis/einen Befehl anwenden, verwenden Sie' WHERE version =: expected'; Duplikat vergrößert die Version nicht.

Bestellung/Bestellung

EOS ist nicht gleich „genau die gleiche Reihenfolge“. Stellen Sie die Konsistenz durch den Partienschlüssel (alle Ereignisse der Einheit → eine Partitur) und/oder den Vergleich von „sequence“ sicher.

Idempotente externe Herausforderungen

Für unsichere Methoden (z.B. HTTP-Webhooks zu einem Drittanbieter-Dienst) fügen Sie den 'Idempotency-Key' hinzu und verlangen, dass der Partner ihn unterstützt.

Häufige Fallen

EOS nur an einem Ort: Wenn sink idempotent ist, man aber Nebenereignisse ohne Idempotenz ausgibt, bekommt man „genau viele Male“ nachgelagert.
Zwei Commits: erst in der DB, dann ein Offset-Commit im Broker - ein Sturz dazwischen erzeugt doppelte Effekte.
Rohe CDCs nach außen: Die Änderung des OBD-Schemas bricht die Idempotenz der Verbraucher.
Instabile Schlüssel: 'operation _ id' ist zeitabhängig/random und ändert sich im Retrace.

Kosten und Kompromisse

Latenz: Transaktionen/isolierte Lesungen → p95/p99 Wachstum.
Overhead-Speicher: Deduplizierungstabellen, State Stores, Transaktionsprotokolle.
Komplexität der Bedienung: Transaktionszeiträume, Rebalance von Streams, „festgefahrene“ Sitzungen.
Diagnose: mehr Zustände ("im Kamit", "sichtbar als read_committed", "zurückgerollt").

Wählen Sie EOS punktgenau: für kritische Aggregate und Effekte; Decken Sie den Rest mit Idempotenz und Entschädigung.

Exactly-once-Tests

1. Fault-Injection: Der Abfall des Prozesses zwischen den Schritten „recorded effect“ und „fixed offset“.
2. Duplikate: Pumpen Sie die gleiche Nachricht 2-5 Mal, stellen Sie sicher, dass Sie einen Effekt haben.
3. Restarts und Rebalance: Stopp/Neustart der Worker, Überprüfung auf keine doppelte Bearbeitung.
4. Netzwerk-Flappies: Timeouts in der Mitte der Transaktion, Wiederholung des Commits.
5. Belastungstests: Anstieg der Warteschlangen → Gibt es eine Degradation zu „für immer in der Transaktion“?

Mini-Vorlagen (Pseudo)

Idempotenter Sink mit Offset-Fixierung

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

Befehl mit Aggregatversion

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

Sicherheit und Compliance

PII/PCI in Deduplizierungstabellen: Minimum speichern, Token anstelle von „rohen“ Daten verwenden.
Audit: Loggen Sie' operation _ id', 'trace _ id', Ergebnis (APPLIED/ALREADY_APPLIED).
Aufbewahrungsrichtlinie: TTL auf Dedup-Tabellen, Offset/Logarchivierung.

Anti-Muster

„Echte exactly-once-Lieferung“: Versuch, Takes auf Transportprotokollebene ohne Idempotenz des Effekts auszuschließen.
Globale verteilte Transaktionen für alles: XA/2PC durch alle Dienste - zerbrechlich und langsam.
Mischen von nicht-identischen Nebenprodukten (z. B. E-Mail vor dem Offset-Commit gesendet).
Fehlende Betriebsschlüssel: Vertrauen auf die „Einzigartigkeit“ der Nutzlast.

Checkliste der Produktion

• Jeder kritische Effekt hat einen idempotenten Schlüssel.
• Offset/Leseposition wird in einer Transaktion mit Wirkung fixiert.
• Deduplex-Tabellen sind indiziert; TTL ≥ Log Retention.
• Für Aggregate ist ein optimistischer Wettbewerb (Version/Sequenz) enthalten.
• Threads/Topics werden im Modus „Nur kommentiert“ gelesen (falls verfügbar).
• Dubletten- und Drop-Tests sind in CI/CD vorhanden.
• Dashboards: Anteil der Wiederholungen, fehlgeschlagene Transaktionen, Blockzeiten, Verzögerungen.
• Dokumentation für Integratoren zu 'Idempotency-Keu '/Wiederholungen/Timeouts.

FAQ

Ist es möglich, EOS ohne Transaktionen bereitzustellen?
Oft ja - durch die Idempotenz der Sinks (upsert/merge) und die Versionierung der Aggregate. Transaktionen vereinfachen Garantien, erhöhen aber den Wert.

Braucht jeder „exactly-once“?
Nein. Er ist teuer. Punktweise dort anwenden, wo kein Ausgleich möglich/teuer ist.

Wie verknüpfe ich E-Mails/Webhooks mit EOS?
Puffern Sie die Benachrichtigung vor dem Commit, senden Sie nach dem Fixieren des Effekts; speichern Sie' notification _ id 'und senden Sie idempotent.

Was ist wichtiger - Lieferung oder Verarbeitung?
Verarbeitung. Lieferungen können wiederholt werden; Der endgültige Zustand sollte korrekt und der einzige sein.

Ergebnis

Bei Exactly-once geht es um die Korrektheit des Effekts, nicht um das Fehlen von Takes bei der Verdrahtung. Erreicht wird sie durch eine Kombination aus Idempotenz, atomarer Wirkungsfixierung und Leseprozess, vernünftiger Partizipation und Versionierungsdisziplin. Wenden Sie EOS dort an, wo die Fehlerkosten nicht akzeptabel sind, und testen Sie seine Realität mit Drop-and-Take-Tests - nicht mit dem Glauben an den Transport.