Garantien der Nachrichtenreihenfolge

1) Was ist „Ordnung“ und warum ist es notwendig

Die Reihenfolge der Nachrichten ist die „Was muss früher verarbeitet werden“ -Beziehung für Ereignisse einer einzelnen Entität (Bestellung, Benutzer, Wallet) oder für den gesamten Thread. Es ist wichtig für Invarianten: „Status A vor B“, „Saldo vor Abschreibung“, „Version n vor n + 1“.
In verteilten Systemen ist eine globale Gesamtordnung teuer und selten notwendig; in der Regel genügt eine lokale Reihenfolge „pro Schlüssel“.

2) Arten von Auftragsgarantien

1. Per-partition (lokale Ordnung im Logabschnitt) - Kafka: die Ordnung innerhalb der Partei bleibt erhalten, zwischen den Parteien nicht.
2. Per-key (ordering key/message group) - Alle Nachrichten mit einem Schlüssel werden in einen „Thread“ der Verarbeitung (Kafka key, SQS FIFO MessageGroupId, Pub/Sub ordering key) geroutet.
3. Globale Gesamtbestellung - Das gesamte System sieht eine einzige Reihenfolge (verteiltes Protokoll/Sequenzer). Teuer, beeinträchtigt Verfügbarkeit und Durchschlag.
4. Causal Order (Ursache und Wirkung) - „Ereignis B nach A, wenn B den Effekt A beobachtet“. Erreichbar über Metadaten (Versionen, Lamport-Zeiten/Vektoruhren) ohne globalen Sequenzer.
5. Best-effort order - der Broker versucht, die Reihenfolge beizubehalten, aber im Falle von Ausfällen sind Permutationen möglich (oft in NATS Core, RabbitMQ mit mehreren Consumern).

3) Wo die Ordnung bricht

Parallelkonsumenten einer Warteschlange (RabbitMQ: Mehrere Konsumenten pro Warteschlange → interleaving).
Retrays/Re-Lieferungen (at-least-once), Timeouts' ack', Re-Staging in der Warteschlange.
Rebalance/Failover (Kafka: Umzug der Partei/des Führers).
DLQ/Reprocessing - Die „giftige“ Nachricht geht an DLQ, die nächsten gehen weiter → die logische Lücke.
Multi-Region und Replikation - unterschiedliche Verzögerungen → nicht synchron.

4) Gestaltung der „Reihenfolge nach Schlüssel“

• Verwenden Sie die natürlichen Schlüssel: 'order _ id', 'wallet _ id', 'aggregate _ id'.
• Achten Sie auf „Hot Keys“ - ein Schlüssel kann den Stream „blockieren“ (Head-of-Line-Blocking). Teilen Sie bei Bedarf den Schlüssel: 'order _ id # shard (0.. k-1)' mit deterministischer Rekonstruktion der Ordnung auf dem Sync.
• In Kafka - ein Schlüssel → eine Partei, die Reihenfolge bleibt innerhalb des Schlüssels.

java producer.send(new ProducerRecord<>("orders", orderId, eventBytes));

(Der Schlüssel = 'orderId' garantiert die lokale Ordnung.)

5) „Ordnung versus Bandbreite“

• Ein Consumer pro Warteschlange behält die Reihenfolge bei, verringert jedoch die Parallelität.
• At-least-once + Parallelität erhöht die Produktivität, erfordert aber Idempotenz und/oder Wiederherstellung der Ordnung.
• Global Order fügt dem Sequenzer Hop → ↑latentnost und Ausfallrisiko hinzu.

Kompromiss: Per-Key-Ordnung, Parallelität = Anzahl der Parteien/Gruppen, + idempotente Syncs.

6) Ordnungskontrolle bei bestimmten Brokern

Kafka

Ordnung in der Partei.
Beobachten Sie' max. in. flight. requests. per. connection ≤ 5` с `enable. idempotence = true', damit die Produzenten-Retrays nicht die Reihenfolge ändern.
Consumer Group: Eine Partei → ein Worker zu einem Zeitpunkt. Wiederholte Lieferungen sind möglich → halten Sie sequence/version in der Geschäftsschicht.
Transaktionen (Read-Process-Write) behalten die „Read/Write/Compmetil Offset“ -Konsistenz bei, schaffen aber keine globale Ordnung.

properties enable.idempotence=true acks=all retries=2147483647 max.in.flight.requests.per.connection=5

RabbitMQ (AMQP)

Die Reihenfolge ist in einer Warteschlange für einen Consumer garantiert. Bei mehreren Message Consumers kann „gemischt“ kommen.
Für die Reihenfolge: ein consumer oder prefetch = 1 + ack nach Abschluss. Für Parallelität - Trennen Sie die Warteschlangen nach Schlüssel (sharding exchanges/consistent-hash exchange).

NATS / JetStream

NATS Core - Best-Effort, geringe Latenz, Ordnung kann gestört werden.
JetStream: Anordnung innerhalb des Streams/der Sequenz; Bei Seltenheitswerten können Sie den Consumer neu ordnen → Sequenz- und Wiederherstellungspuffer verwenden.

SQS FIFO

Exactly-once processing (effizient, durch Deduplizierung) und Reihenfolge innerhalb der MessageGroupId. Parallelität ist die Anzahl der Gruppen innerhalb einer Head-of-Line-Gruppe.

Google Pub/Sub

Ordering Schlüssel gibt die Reihenfolge innerhalb des Schlüssels; Bei Fehlern wird die Veröffentlichung bis zur Wiederherstellung blockiert - achten Sie auf Backpress.

7) Muster der Erhaltung und Wiederherstellung der Ordnung

7. 1 Sequence/Versionierung

• akzeptiert ein Ereignis nur, wenn 'seq = last_seq + 1';
• ansonsten - setzt in den Wartepuffer, bis die Fehlenden eintreffen ('last _ seq + 1').

pseudo if seq == last+1: apply(); last++
else if seq > last+1: buffer[seq] = ev else: skip // дубль/повтор

7. 2 Puffer und Fenster (Stream-Verarbeitung)

Zeitfenster + Wasserzeichen: Wir akzeptieren Out-of-Order innerhalb des Fensters, durch das Wasserzeichen „schließen“ wir das Fenster und ordnen es an.
Erlaubt Latenz: Kanal für Nachzügler (recompute/ignore).

7. 3 Sticky-Routing nach Schlüssel

Das Hash-Routing 'hash (key)% shards' sendet alle Schlüsselereignisse an einen Worker.
In Kubernetes - Halten Sie die Sitzung (sticky) auf der Warteschlangen-/Sherd-Ebene, nicht auf dem L4-HTTP-Balancer.

7. 4 Akteursmodell/„ ein Thread pro Schlüssel “

Für kritische Aggregate (Wallet): Der Akteur verarbeitet sequentiell, der Rest der Parallelität durch die Anzahl der Akteure.

7. 5 Idempotenz + Reordering

Auch mit der Wiederherstellung der Ordnung sind Wiederholungen möglich. Kombinieren Sie UPSERT nach Schlüssel + Version und Inbox (siehe „Exactly-once vs At-least-once“).

8) Umgang mit „giftigen“ Botschaften (Poison Pills)

Die Aufrechterhaltung der Ordnung steht vor der Aufgabe: „Wie soll man leben, wenn eine Nachricht nicht verarbeitet wird?“

Strikte Reihenfolge: Schlüsselfluss sperren (SQS FIFO: gesamte Gruppe). Die Lösung ist by-key DLQ: Wir übersetzen nur den problematischen Schlüssel/die Gruppe in eine separate Warteschlange/manuelle Analyse.
Flexibles Verfahren: Wir erlauben einen Ausweis/Ausgleich; logging und weiter (nicht für Finanzen/kritische Aggregate).
Rückverfolgbarkeitspolitik: begrenzt 'max-deliver' + backoff + avidempotente Effekte.

9) Multiregion und globale Systeme

Cluster-Linking/Replikation (Kafka) garantiert keine interregionale globale Ordnung. Priorisieren Sie die lokale Per-Key-Reihenfolge und die idempotenten Syntax.
Verwenden Sie für eine truly-globale Bestellung einen Sequenzer (zentrales Protokoll), was sich jedoch auf die Verfügbarkeit auswirkt (CAP: minus A bei Netzwerkunterbrechungen).
Alternative: causal order + CRDT für einige Domains (Zähler, Mengen) - keine strenge Reihenfolge erforderlich.

10) Beobachtbarkeit der Ordnung

Метрики: `out_of_order_total`, `reordered_in_window_total`, `late_events_total`, `buffer_size_current`, `blocked_keys_total`, `fifo_group_backlog`.

11) Anti-Muster

Eine Warteschlange + viele Consumer ohne Schlüssel-Sharding - die Reihenfolge bricht sofort.
Retrays durch Pere-Pablish in der gleichen Warteschlange ohne idempotency - takes + out-of-order.
Eine globale Ordnung „nur für den Fall“ ist eine Explosion von Latenz und Kosten ohne wirklichen Nutzen.
SQS FIFO eine Gruppe für alles - voller Head-of-Line. Verwenden Sie MessageGroupId per key.
Ignorieren der „heißen Schlüssel“ - eine „Brieftasche“ bremst alles; Teilen Sie den Schlüssel nach Möglichkeit in Unterschlüssel auf.
Mischen von kritischen und Bulk-Threads in einer Warteschlange/Gruppe - gegenseitige Beeinflussung und Ordnungsverlust.

12) Checkliste Umsetzung

• Garantiestufe definiert: per-key/per-partition/causal/global?
• Ein Ordnungsschlüssel und eine Strategie gegen „Hot Keys“ wurden entworfen.
• Router konfiguriert: Partitionierung/MessageGroupId/Bestellschlüssel.
• Konsumenten werden durch Schlüssel isoliert (Sticky-Routing, Shard-Workers).
• Idempotenz und/oder Inbox/UPSERT auf Syncs enthalten.
• Implementierte Sequenz-/Versions- und Reordering-Puffer (falls erforderlich).
• DLQ-Richtlinie nach Schlüssel und Backoff-Retrays.
• Ordnungs- und Alert-Metriken: Out-of-Order, blocked_keys, late_events.
• Spieltag: Rebalance, Knotenverlust, „giftige“ Nachricht, Netzwerkverzögerungen.
• Dokumentation: Auftragsinvarianten, Fenstergrenzen, Auswirkungen auf SLA.

13) Beispiele für Konfigurationen

13. 1 Kafka Consumer (Minimierung der Ordnungswidrigkeit)

properties max.poll.records=500 enable.auto.commit=false  # коммит после успешной обработки батча isolation.level=read_committed

13. 2 RabbitMQ (Ordnung auf Kosten der Parallelität)

Ein Consumer pro Warteschlange + 'basic. qos(prefetch=1)`

bash rabbitmq-plugins enable rabbitmq_consistent_hash_exchange публикуем с хедером/ключом для консистентного хеша

13. 3 SQS FIFO

Stellen Sie MessageGroupId = key ein. Parallelität = Anzahl der Gruppen.
MessageDeduplicationId zum Schutz vor Doubles (im Anbieterfenster).

13. 4 NATS JetStream (bestellter Verbraucher, Skizze)

bash nats consumer add ORDERS ORD-KEY-42 --filter "orders.42.>" --deliver pull \
--ack explicit --max-deliver 6

14) FAQ

F: Brauche ich eine globale Ordnung?
A: Fast nie. Fast immer reicht ein Per-Key. Globale Ordnung ist teuer und schlägt auf die Verfügbarkeit.

F: Was ist mit der „giftigen“ Botschaft unter strenger Reihenfolge?
A: Nur seinen Schlüssel/seine Gruppe in DLQ übersetzen, der Rest geht weiter.

F: Ist es möglich, gleichzeitig Ordnung und Maßstab zu erhalten?
A: Ja, Schlüsselreihenfolge + viele Schlüssel/Parteien + idempotente Operationen und Pufferreordering, wo nötig.

F: Was ist wichtiger: Ordnung oder exactly-once?
A: Für die meisten Domains - Schlüsselreihenfolge + effektiv exactly-once Effekte (Idempotenz/UPSERT). Transport kann at-least-once sein.

15) Ergebnisse

Ordnung ist eine lokale Garantie rund um den Geschäftsschlüssel, keine teure globale Disziplin. Entwerfen Sie Schlüssel und Parteien, begrenzen Sie „heiße“ Schlüssel, verwenden Sie Idempotenz und, wo nötig, Sequenzierung + Pufferreordering. Behalten Sie die Metriken „Out-of-Order“ und „Blocked Keys“ im Auge, testen Sie Abstürze - und Sie erhalten eine vorhersehbare Verarbeitung ohne Verluste bei Leistung und Verfügbarkeit.