Code di messaggi Kafka e RabbitMQ

Code di messaggi Kafka, RabbitMQ

(Sezione Tecnologia e infrastruttura)

Breve riepilogo

• Apache Kafka - Registro eventi distribuito (log), incentrato sull'elaborazione in streaming, la replica e lo skailing orizzontale attraverso partiture.
• RabbitMQ - broker di code AMQP con routing flessibile (exchanges/bindings), priorità, TTL, conferme e attività classiche di coda.

Entrambi gli strumenti sono maturi, ma affrontano sfide diverse: Kafka per gli striam scalabili e gli analisti, RabbitMQ per l'orchestrazione operativa delle attività, RPC e routing variegato.

Dove è appropriato il iGaming

• Sono necessari eventi TPS elevati (scommesse, eventi di gioco, telemetria) e skale orizzontale attraverso partiture.
• Importante è il rà-consum freddo/caldo (rileggere i dati in nastro), il retensh e la compagine per le unità (bilanciamento, condizione del giocatore).
• Sono necessari processi strim (Kafka) per le apparecchiature realtime, come i leader dei tornei, i limiti del gioco responsabile, i segnali antifrode.

• Sono necessarie le classiche code di lavoro: verifica KYC, pagamenti ritardati/ripetuti, invio di e-mail/SMS/push, webhooks a PSP.
• Routing flessibile (topic/direct/fanout), priorità, TTL, delay, dead-letter e RPC-pattern.
• Sono necessari vincoli rigorosi per-consumer (prefetch/QoS), semplici controlli del carico e rapidi ritrai.

Il risultato frequente è Kafka per eventi e analisti + per orchestrazioni e integrazioni.

Modello di dati e routing

Kafka

I topic si dividono in una partitura, ognuna è una loga ordinata.
La chiave del messaggio determina la partizione e l'ordinamento all'interno della chiave.
Le console leggono per offset e i gruppi di consulenti scalano l'elaborazione.
Ritensh in termini di tempo/volume; log compettion memorizza l'ultima versione della chiave.

RabbitMQ

Exchanges (direct/fanout/topic/headers) + bindings messaggi finiscono nei queues.
Conferme (ack/nack/sollue), publisher conferms, priorities, TTL, dead-letter (DLX/DLQ).
Quorum queues (Raft) per l'elevata disponibilità lazy queues per risparmiare RAM.

Garanzia di spedizione e idipotenza

At-just-once: senza retrai; Rischio di perdita, ritardo minimo.
At-least-once - Lo standard predefinito di può essere duplicato da hender idipotenti (chiave query/transazione, upsert, tabella dedup, outbox).
Exactly-once: in Kafka si ottiene un venditore idompotente + top transazionali + consumo coerente, ma più spesso più costoso e più complesso; Nel RabbitMQ è limitato e con le ossa. Per i flussi effettivi di pagamento/tasso, si applica at-least-once + idampotenza rigorosa.

• Idempotency-keys univoci (UUID/ULID) per l'evento/comando.
• Outbox Pattern nel database del servizio + Change Data Capture (Debezium) impedisce la «doppia scrittura».
• Dedup per (key, created _ at) in uno store separato con TTL.

Ordine/ordine dei messaggi

Kafka garantisce l'ordine all'interno della partitura. Scegli la chiave in modo che l'intera «vita» di un'entità (ad esempio, «player _ id» per l'equilibrio) sia in una sola chiave.
l'ordine RabbitMQ non è garantito rigorosamente per le consegne ripetute/più consoomer; pipline critiche all'ordine - meglio in Kafka o tramite single-active consumer e seriatizzazione del flusso.

Progettazione di topic e code

• Granularia'domain '. event '(es.' payments. deposit. created`).
• Le chiavi sono «player _ id», «account _ id», «bet _ id» per l'ordinamento.
• Partizioni = N per TPS target (regola: 1 partitura X messaggi/secondi/console); Mettere una scorta sulla crescita.
• Retenschn: eventi - ore/giorni; La compagine è per «stati».

• Exchanges per dominio: 'payments. direct`, `risk. topic`.
• Le code per i consumatori sono: 'kyc. checker. q`, `psp. webhooks. retry. q`.
• DLQ per coda di lavoro delay per backoff.
• Prefetch imposta parallelismo, code quorum per HA.

Errori, retrai e DLQ

Classificare gli errori temporanei (rete/PSP 5xx) dei retrai; fatali (convalida, schema) subito DLQ.
Exponential backoff + jitter, limite dei retrai, rilevazione «poison-pill».
Retry-queues singoli per passo (5s, 1m, 5m, 1h).
Elaboratore DLQ: alert, trance, analisi manuale, pi-iniezione con patch.

Contratto dati e schemi

Utilizzare Avro/Protobuf + Schema Registry (per Kafka è uno standard di fatto).
Versioning: modifiche backward-compatibile (aggiunta di campi opzionali), impedimento migrazioni interruttive.
Campi PII - crittografia/tornizzazione attenersi al GDPR e alle norme locali.

Monitoraggio, osservabilità e SLO

Metriche dei produttori/consulenti: lag, throughput, errori, retrai, tempo di lavorazione.
Loga + tracking (ID correlato: «trace _ id», «messaggistica _ id»).
SLO: p99-latitanza pubblicazione/consegna, consumer lag valido, tempo di ripristino dopo i feed.
Alert sulla crescita del DLQ, eccesso di lag, calo delle partizioni/quorum.

Protezione e compliance

TLS in transito, crittografia dei segreti (SOPS/Vault), ACL/RBAC limitate.
Singoli top/code per domini sensibili (pagamenti, KYC).
Controllo-riepilogo delle pubblicazioni/iscrizioni, archiviazione delle chiavi fuori dal codice.
Requisiti regionali (EU/Turchia/LatAm) - Ritensh, localizzazione dello storage, occultamento.

Elevata disponibilità, disponibilità e DR

• Cluster 3-5 broker minimo; replication. factor ≥ 3.
• min. insync. replica e acks = all per record robusti.
• Replica crociata regionale (MirrorMaker-2) per DR.

• Quorum queues per HA, numero pari/dispari di nodi con quorum.
• Federation/Shovel per MJ-Center di replica, script DR.
• Stand freddo/caldo, test di cambio.

Prestazioni e tuning

• `linger. ms` и `batch. size «per il batching;» compassion. type` (lz4/zstd).
• «acks = all», ma tenere d'occhio la latenza; tun'max. in. flight. requests. per. connection "con idipotenza.

• Bastano le partiture; unità NVME griglia 10/25G; Impostazioni GC JVM.

• Corretta gestione di gruppo, 'max. poll. interval. ms', pausare le partizioni al bacof.

• Publisher confirms in batch Tuttavia, è necessario riutilizzare.

• «prefetch» (ad esempio 50-300) in base al tempo di lavorazione; lazy queues per grandi backlogs.
• Distribuire le code calde sui nodi; thon TSD/descrittori di file.

Pattern tipici per i iGaming

Outbox + Kafka per la pubblicazione affidabile degli eventi di dominio (tasso postato, deposito iscritto).
RPC per le richieste sincronizzate di integrazione (verifica documento KYC, calcolo bonus).
Saga-pattern: orchestrazione attraverso eventi (Kafka) e squadre (RabbitMQ) con passaggi compensativi.
Notifiche fan-out da un evento CRM, antifrode, analista.
Smart-retry PSP con ritardi progressivi e DLQ.

Migrazione e architettura ibride

Inizia con il RabbitMQ per «operation», aggiungi Kafka per gli eventi e gli analisti.
Doppie pubblicazioni: il servizio → outbox → connettore in entrambe le direzioni (Kafka + RabbitMQ) fino alla completa stabilizzazione.
Trasferite gradualmente gli analisti/aggregazioni strim a Kafka Streams/ksqlDB.

Foglio di scelta mini

1. Carico di lavoro/TPS> decine di migliaia/secondi?
2. Hai bisogno di un reset e di una ripetizione del registro?
3. Routing flessibile, priorità, consegna ritardata, RPC?
4. Ordine rigoroso sulla chiave e skale orizzontale su Kafka (chiave/partitura).
5. Semplici attività/work-kue con controllo parallelismo .
6. La combinazione ideale è Kafka (eventi) + RabbitMQ (orchestrazione).

Esempi di configurazioni minime

Esempio: ritai ritardati e DLQ in RabbitMQ (tramite policy)

Coda di lavorò psp. webhooks. q`

Coda di retrò: 'psp. webhooks. retry. 1m. q '(TTL = 60s, DLX indica indietro sul lavoro)

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' → monitoraggio e analisi manuale.

Esempio: il top di Kafka per le scommesse

Topic, 'bets'. placed. v1 ', partenze: 24, RF = 3, 7 giorni.
La chiave del messaggio è «player _ id» o «bet _ id» (scegli cosa è più importante per l'ordine).
Схема: Protobuf/Avro с `bet_id`, `player_id`, `stake`, `odds`, `ts`, `idempotency_key`.

Test e qualità

Test Contract Producer/Consister + Convalida schemi (Schema Registry).
Test Chaos: caduta di nodi, ritardi di rete, split-brain.
Test di carico con target TPS, controllo p99, crescita e ripristino.

Riepilogo

Kafka è un'autostrada di eventi e di streaming: ordinamento in chiave, ritensh/compagine, alta TPS, analisi in tempo reale.
RabbitMQ - Coda operativa di routing flessibile, conferma, priorità, retrai/DLQ, RPC.
Nel iGaming, la migliore pratica è l'uso complementare: eventi e analisi in Kafka, attività di integrazione/orchestrazione nel RabbitMQ, con standard comuni di schemi, idipotenza, monitoraggio e severi SLO.