Files d'attente : Kafka et RabbitMQ

Files d'attente : Kafka, RabbitMQ

(Section : Technologie et infrastructure)

Résumé succinct

• Apache Kafka est un journal d'événements distribué (log), axé sur le streaming, la réplication et le skating horizontal par lots.
• RabbitMQ est un courtier de file d'attente AMQP avec routage flexible (échanges/bindings), priorités, TTL, confirmations et tâches classiques de file d'attente.

Les deux instruments sont matures, mais résolvent des problèmes différents : Kafka - pour les strimes et les analyses évolutives, RabbitMQ - pour l'orchestration opérationnelle des tâches, RPC et routage multiple.

Le cas échéant dans iGaming

• Il faut des événements TPS élevés (paris, jeux, télémétrie) et un skale horizontal à travers les lots.
• L'important est le ré-consum froid/chaud (lecture répétée des données lentes), la rétention et la compaxe pour les agrégats (équilibre, état du joueur).
• Il faut des processus de stream (Kafka Streams/ksqlDB/Flink) pour les agrégats de réalité : leaders du tournoi, limites du jeu responsable, signaux antifrod.

• Il faut des files d'attente de tâches classiques : vérification KYC, paiements différés/répétés, envoi d'e-mail/SMS/push, webhooks à PSP.
• Routage flexible (topic/direct/fanout), priorités, TTL, delay, dead-letter et modèles RPC.
• Des contraintes per-consumer strictes (prefetch/QoS), une gestion simple de la charge et des retraits rapides sont nécessaires.

Résultat fréquent : Kafka pour les événements et les analyses + RabbitMQ pour l'orchestration et les intégrations.

Modèle de données et routage

Kafka

Les tops sont → divisés en lots, chacun est un journal ordonné.
La clé de message définit le lot → l'ordre dans la clé.
Les consumers lisent par offset, les groupes de consumers évoluent le traitement.
Rétention en temps/volume ; log compaction stocke la dernière version de la clé.

RabbitMQ

Exchanges (direct/fanout/topic/headers) + bindings → les messages sont envoyés aux queues.
Confirmations (ack/nack/requeue), confirmations d'éditeur, priorities, TTL, lettre morte (DLX/DLQ).
Quorum queues (Raft) pour une haute disponibilité ; lazy queues pour économiser RAM.

Garanties d'expédition et d'idempotence

At-most-once : pas de retraits ; risque de perte, délai minimum.
At-least-once : la norme par défaut → peut être dupliquée → handler idempotent (clé de requête/transaction, upsert, dedup-table, outbox).
Exactly-once : chez Kafka, on obtient dans un ensemble un fournisseur idempotent + tops transactionnels + consommation cohérente, mais plus souvent plus cher et plus complexe ; chez RabbitMQ - limité et avec des os. Dans les flux réels de paiement/taux, l'idempotence at-least-once + stricte est appliquée.

• Idempotency-keys uniques (UUID/ULID) par événement/commande.
• Le modèle Outbox dans la base de données du service + Change Data Capture (Debezium) → la prévention du « double enregistrement ».
• Dedup par (clé, created_at) dans un store séparé avec TTL.

Commande/ordre des messages

Kafka garantit l'ordre à l'intérieur du lot. Sélectionnez la clé pour que la « vie » entière de l'entité (par exemple, 'player _ id'pour l'équilibre) soit dans la même clé.
L'ordre RabbitMQ n'est pas strictement garanti dans les livraisons répétées/plusieurs consumers ; les piplines critiques à l'ordre - mieux dans Kafka ou par le biais d'un simple-active consumer et la sérialisation du flux.

Conception des tops et files d'attente

• Granularité : 'domain. event '(par exemple' payments. deposit. created`).
• Clés : 'player _ id', 'account _ id', 'bet _ id' pour ordonner.
• Lots = N par TPS cible (règle : 1 lot ≈ X messages/s/consumer) ; mettre une marge sur la croissance.
• Rétention : événements - heures/jours ; compaxn - pour les « états ».

• Échanges par domaine : 'payments. direct`, `risk. topic`.
• Files d'attente sous les consommateurs : 'kyc. checker. q`, `psp. webhooks. retry. q`.
• DLQ pour chaque file d'attente de travail ; delay pour backoff.
• Prefetch définit le parallélisme, quorum files - pour HA.

Erreurs, retraits et DLQ

Classer les erreurs : temporelles (réseau/PSP 5xx) → rétroactions ; fatal (validation, schéma) → DLQ à la fois.
Backoff exponentiel + jitter, limite de rétroaction, détection « poison-pill ».
Retry-queues séparées par étapes (5s, 1m, 5m, 1h).
Manipulateur DLQ : alert, remorque, démontage manuel, ré-injection avec patch.

Contrat de données et schémas

Utilisez Avro/Protobuf + Schema Registry (pour Kafka - standard de facto).
Versioning : modifications backward-compatibles (ajout de champs optionnels), interdiction des migrations cassantes.
Champs PII - chiffrement/tokenisation ; respecter le RGPD et les normes locales.

Surveillance, observabilité et SLO

Métriques des producteurs/consumers : lag, throughput, erreurs, retraits, temps de traitement.
Logs + tracing (corrélation ID : 'trace _ id', 'message _ id').
SLO : p99-latence de publication/livraison, consumer lag admissible, temps de récupération après feel.
Alerte sur la croissance du DLQ, excès de lag, chute des lots/quorum.

Sécurité et conformité

TLS en transit, cryptage secret (SOPS/Vault) limité à ACL/RBAC.
Topics/files d'attente séparées pour les domaines sensibles (paiements, KYC).
Audit-journal des publications/abonnements, stockage des clés en dehors du code.
Exigences régionales (UE/Turquie/LatAm) : rétention, localisation du stockage, masquage.

Haute disponibilité, tolérance aux pannes et DR

• Groupe de 3 à 5 courtiers minimum ; replication. factor ≥ 3.
• min. insync. replicas et acks = tous pour les enregistrements robustes.
• Réplication croisée régionale (MirrorMaker-2) pour DR.

• Quorum queues pour HA, nombre pair/impair de nodes avec quorum.
• Federation/Shovel pour la réplication inter-centres de données, scripts DR.
• Stand froid/chaud, tests de commutation.

Performances et tuning

• `linger. ms` и `batch. size 'pour le batch ;' compression. type` (lz4/zstd).
• 'Acks = all ', mais surveiller la latence ; tun 'max. in. flight. requests. per. connection 'avec idempotence.

• Assez de lots ; Disques NVMe ; une grille de 10/25G ; Réglages GC JVM.

• Gestion de groupe correcte, 'max. poll. interval. ms', arrêter les lots au backof.

• Publisher confirmes dans les batchs ; channels à réutiliser.

• « prefetch » (par exemple 50-300) en fonction du temps de traitement ; lazy queues pour les gros backlogs.
• Distribuer les files d'attente chaudes par node ; TSR/descripteurs de fichiers.

Modèles types pour iGaming

Outbox + Kafka pour une publication fiable des événements de domaine (taux placé, dépôt crédité).
RabbitMQ RPC pour les demandes d'intégration synchrone (vérification du document KYC, calcul du bonus).
Saga pattern : orchestration à travers des événements (Kafka) et des commandes (RabbitMQ) avec des étapes compensatoires.
Notifications fan-out : à partir d'un événement → CRM, antifrod, analyste.
Smart-retry PSP webhooks avec des retards progressifs et DLQ.

Migrations et architectures hybrides

Commencez par RabbitMQ pour « operation », ajoutez Kafka pour les événements et les analyses.
Dupliquez les publications : service → outbox → connecteur dans les deux sens (Kafka + RabbitMQ) jusqu'à la stabilisation complète.
Transférez progressivement les abonnés d'analyse/stream-agrégation vers Kafka Streams/ksqlDB.

Mini-chèque de sélection

1. Charge/TPS> dizaines de milliers/s ? → Kafka.
2. Besoin d'une relecture et d'une relecture comme dans le magazine ? → Kafka.
3. Routage flexible, priorités, livraison différée, RPC ? → RabbitMQ.
4. Ordre strict par clé et skale horizontal → Kafka (clé/lot).
5. Tâches simples/work-kew avec gestion du parallélisme → RabbitMQ.
6. Idéalement, une combinaison : Kafka (événements) + RabbitMQ (orchestration).

Exemples de configurations minimales

Exemple : Retrai et DLQ détenus à RabbitMQ (via politique)

File d'attente de travail : 'psp. webhooks. q`

File d'attente des rétrogrades : 'psp. webhooks. retry. 1m. q '(TTL = 60s, DLX indique en arrière le travail)

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 '→ surveillance et analyse manuelle.

Exemple : Top Kafka pour les paris

Topic : 'bets. placed. v1 ', lots : 24, RF = 3, rétention 7 jours.
Clé de message : 'player _ id' ou 'bet _ id' (sélectionnez ce qui est plus important pour l'ordre).
Схема: Protobuf/Avro с `bet_id`, `player_id`, `stake`, `odds`, `ts`, `idempotency_key`.

Tests et qualité

Tests Contract Producteur/Consumer + Check of Schema Registry.
Tests de chaos : chute de nodules, retards de réseau, split-brain.
Essais de charge avec TPS cible, vérification p99, croissance lag et récupération.

Résultats

Kafka est une autoroute d'événements et de streaming : ordonnancement par clé, rétention/compactage, TPS élevés, analyse en temps réel.
RabbitMQ est la file d'attente des tâches : routage flexible, confirmations, priorités, retrai/DLQ, RPC.
Dans iGaming, les meilleures pratiques sont l'utilisation complémentaire : événements et analyses chez Kafka, les tâches d'intégration/orchestration chez RabbitMQ, avec des standards de schémas uniformes, l'idempotence, le suivi et des SLO stricts.