Message Queues: Kafka und RabbitMQ

Message Queues: Kafka, RabbitMQ

(Abschnitt: Technologie und Infrastruktur)

Kurze Zusammenfassung

• Apache Kafka ist ein verteiltes Ereignisprotokoll (Log), das sich auf Streaming, Replikation und horizontales Scaling durch Parties konzentriert.
• RabbitMQ ist ein AMQP-Warteschlangenbroker mit flexiblem Routing (Exchanges/Bindings), Prioritäten, TTL, Bestätigungen und klassischen Warteschlangenaufgaben.

Beide Tools sind ausgereift, lösen aber unterschiedliche Aufgaben: Kafka für skalierbare Streams und Analysen, RabbitMQ für die operative Aufgabenorchestrierung, RPC und diverses Routing.

Wo es in iGaming angemessen ist

• Wir brauchen hohe TPS von Ereignissen (Wetten, Spielereignisse, Telemetrie) und horizontales Scalen durch Parteien.
• Wichtig sind Kalt/Heiß-Re-Consum (Wiederlesen der Banddaten), Retention und Compaction für Aggregate (Balance, Spielerzustand).
• Wir brauchen Streamingprozesse (Kafka Streams/ksqlDB/Flink) für Realtime-Aggregate: Turnierleiter, verantwortungsvolle Spielgrenzen, Anti-Fraud-Signale.

• Wir brauchen klassische Aufgabenwarteschlangen: KYC-Check, verzögerte/wiederholte Auszahlungen, E-Mail/SMS/Push-Versand, Webhooks zur PSP.
• Flexibles Routing (topic/direct/fanout), Prioritäten, TTL, Delay, Dead-Letter und RPC-Muster.
• Strenge Per-Consumer-Limits (Prefetch/QoS), einfaches Lastmanagement und schnelle Retrays sind gefordert.

Häufiges Ergebnis: Kafka für Events und Analytics + RabbitMQ für Orchestrierung und Integrationen.

Datenmodell und Routing

Kafka

Die Topics werden → in Parteien aufgeteilt, jede ist ein geordnetes Protokoll.
Der Schlüssel der Nachricht bestimmt die Partei → die Reihenfolge innerhalb des Schlüssels.
Consumer lesen aus Offset, Consumer-Gruppen skalieren die Verarbeitung.
Retention nach Zeit/Volumen; log compaction speichert die neueste Version des Schlüssels.

RabbitMQ

Exchanges (direct/fanout/topic/headers) + bindings → Nachrichten landen in queues.
Bestätigungen (ack/nack/requeue), publisher confirms, priorities, TTL, dead-letter (DLX/DLQ).
Quorum queues (Floß) für hohe Verfügbarkeit; lazy queues, um RAM zu sparen.

Liefergarantien und Idempotenz

At-most-once: keine Rückblenden; Verlustrisiko, minimale Verzögerung.
At-least-once: Standardstandard → Duplikate → idempotente Handler (Request/Transaction Key, Upsert, Dedup-Tabelle, Outbox) sind möglich.
Exactly-once: in Kafka wird in einem Bündel von idempotent producer + transactional tops + konsistenter Verbrauch erreicht, aber häufiger teurer und komplizierter; in RabbitMQ - eingeschränkt und mit Knochen. In realen Zahlungs-/Wettströmen gilt at-least-once + strikte Idempotenz.

• Einzigartige idempotency-keys (UUID/ULID) pro Event/Team.
• Das Outbox-Muster im Service DB + Change Data Capture (Debezium) → die Vermeidung von „Double Writing“.
• Dedup durch (Schlüssel, created_at) in einem separaten Stapel mit TTL.

Bestellung/Reihenfolge der Nachrichten

Kafka garantiert Ordnung innerhalb der Partei. Wählen Sie den Schlüssel so aus, dass sich das gesamte „Leben“ der Entität in einem Schlüssel befindet (z. B. „player _ id“ für das Gleichgewicht).
RabbitMQ Bestellung ist nicht streng garantiert bei wiederholten Lieferungen/mehrere Verbraucher; ordnungskritische Pipelines - am besten in Kafka oder durch Single-Active-Consumer und Flow-Serialisierung.

Topics und Warteschlangen entwerfen

• Granularität: 'Domäne. event'(z.B. 'Zahlungen. deposit. created`).
• Schlüssel: 'player _ id', 'account _ id', 'bet _ id' für die Reihenfolge.
• Partition = N durch Ziel TPS (Regel: 1 Partei ≈ X Nachrichten/sec/consumer); Reserve für Wachstum legen.
• Retention: Ereignisse - Stunden/Tage; Compaction - für „Zustände“.

• Exchanges nach Domains: 'payments. direct`, `risk. topic`.
• Warteschlangen für Verbraucher: 'kyc. checker. q`, `psp. webhooks. retry. q`.
• DLQ für jede Arbeitswarteschlange; delay für backoff.
• Prefetch setzt Parallelität, quorum Warteschlangen sind für HA.

Fehler, Retrays und DLQs

Klassifizieren Sie Fehler: temporäre (Netzwerk/PSP 5xx) → Retrays; fatal (Validierung, Schema) → sofort DLQ.
Exponentieller Backoff + Jitter, Retraylimit, „Poison-Pill“ -Detektion.
Einzelne Retry-Queues in Schritten (5s, 1m, 5m, 1h).
DLQ-Handler: Alert, Trace, manuelle Analyse, Re-Injection mit Patch.

Datenvertrag und Diagramme

Verwenden Sie Avro/Protobuf + Schema Registry (für Kafka - de facto Standard).
Versionierung: backward-kompatible Änderungen (optionale Felder hinzufügen), Unterbindung von störenden Migrationen.
PII-Felder - Verschlüsselung/Tokenisierung; Beachten Sie die DSGVO und lokale Vorschriften.

Überwachung, Beobachtbarkeit und SLO

Producer/Consumer Metriken: lag, throughput, bugs, retrays, processing time.
Logs + Tracing (Korrelations-IDs: 'trace _ id', 'message _ id').
SLO: p99-Veröffentlichungs-/Lieferlatenz, zulässige Verbraucherverzögerung, Erholungszeit nach Fails.
Alerts auf DLQ-Wachstum, Lag-Überschreitung, sinkende Parteien/Quorum.

Sicherheit und Compliance

TLS im Transit, Geheimverschlüsselung (SOPS/Vault), eingeschränkte ACL/RBAC.
Separate Tops/Warteschlangen für sensible Domains (Payments, KYC).
Audit-Log von Publikationen/Abonnements, Speicherung von Schlüsseln außerhalb des Codes.
Regionale Anforderungen (EU/Türkei/LatAm): Retention, Lagerlokalisierung, Maskierung.

Hohe Verfügbarkeit, Fehlertoleranz und DR

• Cluster 3-5 Broker Minimum; replication. factor ≥ 3.
• min. insync. replicas und acks = all für starke Einträge.
• Regionalübergreifende Replikation (MirrorMaker-2) für DR.

• Quorum queues für HA, gerade/ungerade Anzahl von Knoten mit Quorum.
• Federation/Shovel für Replikations-Rechenzentren, DR-Szenarien.
• Kalt-/Warmstand, Schaltversuche.

Leistung und Tuning

• `linger. ms` и `batch. Größe' für batching; 'compression. type` (lz4/zstd).
• „acks = all“, aber auf Latenz achten; tune' max. in. flight. requests. per. Verbindung 'mit Idempotenz.

• Genügend Parteien; NVMe-Laufwerke; Netz der 10/25G; GC-Einstellungen von JVM.

• Das richtige Gruppenmanagement, 'max. poll. interval. ms', pausieren die Parteien im Hinterhof.

• Publisher confirms in battles; channels verwenden.

• „prefetch“ (z. B. 50-300) nach Bearbeitungszeit; lazy queues für große Backlogs.
• Verteilen Sie heiße Warteschlangen auf den Knoten; TCP-Tune/Datei-Deskriptoren.

Typische Muster für iGaming

Outbox + Kafka für die zuverlässige Veröffentlichung von Domain-Events (Wette platziert, Einzahlung gutgeschrieben).
RabbitMQ RPC für synchrone Anforderungen an Integrationen (KYC-Dokumentenprüfung, Bonusberechnung).
Saga-Muster: Orchestrierung durch Events (Kafka) und Teams (RabbitMQ) mit Kompensationsschritten.
Fan-out-Benachrichtigungen: von einem Ereignis → CRM, Betrugsbekämpfung, Analytik.
Smart-retry PSP-Webhooks mit progressiver Latenz und DLQ.

Migration und hybride Architekturen

Beginnen Sie mit RabbitMQ für „Betriebssysteme“, fügen Sie Kafka für Ereignisse und Analysen hinzu.
Duplizieren Sie Publikationen: Service → Outbox → Konnektor in beide Richtungen (Kafka + RabbitMQ) bis zur vollständigen Stabilisierung.
Schrittweise Übertragung von Analytics/Stream-Aggregation-Abonnenten auf Kafka Streams/ksqlDB.

Mini-Checkliste für die Auswahl

1. Last/TPS> Zehntausende/sec? → Kafka.
2. Brauchen Sie retention und re-reading wie aus einer Zeitschrift? → Kafka.
3. Flexibles Routing, Prioritäten, verzögerte Lieferung, RPC? → RabbitMQ.
4. Strikte Reihenfolge nach Schlüssel und horizontale scale → Kafka (Schlüssel/Parteien).
5. Einfache Aufgaben/Work-Q mit Parallelitätsmanagement → RabbitMQ.
6. Idealerweise eine Kombination aus: Kafka (Veranstaltungen) + RabbitMQ (Orchestrierung).

Beispiele für minimale Konfigurationen

Beispiel: verzögerte Retrays und DLQs in RabbitMQ (über Policy)

Arbeitswarteschlange: 'psp. webhooks. q`

Warteschlange der Retrays: 'psp. webhooks. retry. 1m. q'(TTL = 60s, DLX zeigt zurück zur Arbeit)

DLQ: `psp. webhooks. dlq`

• `psp. webhooks. q` → `x-dead-letter-exchange=psp. retry. exchange`
• `psp. webhooks. retry. 1m. q` → `x-message-ttl=60000`, `x-dead-letter-exchange=psp. work. exchange`
• `psp. webhooks. dlq '→ Überwachung und manuelle Analyse.

Beispiel: Kafka-Spitze für Wetten

Topic: 'bets. placed. v1', Anteile: 24, RF = 3, retention 7 Tage.
Nachrichtenschlüssel: 'player _ id' oder 'bet _ id' (wählen Sie, was für die Reihenfolge wichtiger ist).
Схема: Protobuf/Avro с `bet_id`, `player_id`, `stake`, `odds`, `ts`, `idempotency_key`.

Prüfung und Qualität

Contract-Tests producer/consumer + Schemaüberprüfungen (Schema Registry).
Chaos-Tests: Drop-Nodes, Netzwerkverzögerungen, Split-Brain.
Lastläufe mit Ziel-TPS, p99-Check, Lag-Wachstum und Erholung.

Ergebnisse

Kafka - Event-Backbone und Streaming: Reihenfolge nach Schlüssel, Retention/Compaction, hohe TPS, Echtzeitanalyse.
RabbitMQ ist eine operative Aufgabenwarteschlange: flexibles Routing, Bestätigungen, Prioritäten, Retrays/DLQ, RPC.
Bei iGaming ist die beste Praxis die komplementäre Nutzung: Veranstaltungen und Analysen bei Kafka, Integrations-/Orchesteraufgaben bei RabbitMQ, mit einheitlichen Schemastandards, Idempotenz, Monitoring und strengen SLOs.