Files d'attente : RabbitMQ, Kafka

Files d'attente : RabbitMQ, Kafka

1) Quand quoi choisir

RabbitMQ (AMQP 0-9-1 / 1. 0, files d'attente classiques, Quorum Queues, Streams)

Convient pour : RPC/commandes, flux de travail, tâches courtes, routage fanout/topic, confirmations flexibles, gestion des priorités.
Avantages : riche sémantique de routage (exchanges), 'basic. qos '(prefetch), per-message TTL/delay, modèles RPC confortables (reply-to), démarrage facile.
Inconvénients : l'histoire est stockée dans une file d'attente, mise à l'échelle horizontale par file d'attente/chars ; Coût Throughput élevé avec des flux très importants.

Apache Kafka (journal des événements, lots, groupes de consommateurs)

Convient pour : flux d'événements, audit, event sourcing, ETL/intégrations (Connect), haute RPS/MBps, replay/re-processing, stream-processing (Streams/ksqlDB).
Avantages : journal à long terme, mise à l'échelle par lot, repliement durable, compilation des clés.
Inconvénients : le modèle « pull + lots » n'est pas pour les petits RPC ; l'ordre seulement dans le lot ; la gestion des schémas/interopérabilité est la responsabilité de l'équipe.

2) Sémantique d'expédition et invariants

At-most-once : pas de retraits ; rapide, risque de perte.
At-least-once : avec des retraits ; exige l'idempotence du consommateur.
Exactly-once : réalisable dans des conditions limitées (Kafka TX + revendeur idempotent + sink convenu ; RabbitMQ - via la table de déduplication/clés idempotent).
Ordre : RabbitMQ - ordre dans la file d'attente (peut être perturbé avec les retraits/multi-consumers) ; Kafka - ordre dans les lots, la clé définit le lot.

Invariants du domaine : argent/soldes - à travers des magazines/sagas et des commandes idempotent ; ne comptez pas sur la LWW.

3) Modèles d'intégration

Outbox/InBox : l'inscription atomique de l'événement dans le BD → la publication au tour (outbox) et идемпотентное la consommation avec логом des traitements (inbox).
DLQ (lettres mortes) : après N tentatives/erreurs, dans DLQ + alert.
Retry/Delay: RabbitMQ — TTL + dead-letter exchange; Kafka - retry-topics avec backoff.
Request/Reply: RabbitMQ — `reply_to` + `correlation_id`; Kafka - rarement, seulement des modèles spéciaux.
Compensation : sagas sur les événements ; chaque opération a l'inverse.

4) Conception de clés et topologies

RabbitMQ

Exchanges: `direct`, `topic`, `fanout`, `headers`.
Routing key : définit l'entrée dans la ou les files d'attente. Les files d'attente individuelles sont prioritaires.
QoS : « prefetch » (50-300 par exemple) équilibre vitesse/latence.
Quorum Queues : files d'attente répliquées sur Raft ; remplacement de mirrored classic.
Streams : flux avec offsets (Kafka-like) pour haut-throughput/replay.

Kafka

Topic → partitions : planifiez '# partitions' en fonction de la cible throughput et du parallélisme (il est plus facile d'augmenter que de réduire).
Key : toutes les entrées d'une clé sont dans le même lot (garantie d'ordre par clé).
Replication factor : 3 pour les thèmes productifs, 'min. insync. replicas = 2 '+' acks = all 'pour la fiabilité.
Retraite : par le temps/taille ; compaction - Stocke les dernières valeurs par la clé + tombstones à supprimer.

5) Retrai, DLQ, idempotence

RabbitMQ

Répétitions : per-message TTL + DLX (dead-letter exchange) avec backoff (par exemple 1m → 5m → 15m).
Idempotence : 'correlation _ id '/' message-id' + table des messages traités (TTL) ou commandes déterministes.
Confirmations : manual'basic. ack'après une transaction réussie ; 'basic. nack(requeue=false)` в DLQ.

Kafka

Répétitions : retry-topics séparés ; consumer commit offset après succès side-effect.
Exactly-once processing (EOS): Producer `enable. idempotence = vrai ', producteur/consommateur transactionnel,' read _ committed'sur le consommateur ; sink (par exemple, Kafka→Kafka ou Kafka→DB par le biais d'une transaction) - synchroniser soigneusement.
Dedup : par clé/clé idempotent sur le côté de la base, ou via le compact topic.

6) Performance et dimension

Loi de Little : 'L = λ × W'

Pour les workers : parallélisme requis 'N ≈ arrival_rate × avg_processing_time × réserve (1. 2–1. 5)`.
RabbitMQ prefetch : commencez par 'prefetch = 100' et mesurez p99/temps « in-flyte ».
Kafka partitions : calcul à partir du parallélisme de consommation désiré et de la cible par throughput (par exemple, 1 lot stable 5-20 MB/s sur SSD/10GbE).

7) Observabilité et alertes

• Lag/Backlog (messages/octets), age des messages (p95/p99), error-rate des traitements, DLQ-rate.
• Temps « publikatsiya→obrabotka ».
• Carte des dépendances : vendeur → courtier → consumer.

• Connexions, canaux, messages non ackés, 'memory _ alarm', 'disk _ free _ limit', 'queue length' p95.
• Rapports sur Quorum (leader, Raft log, erreurs 'quorum not enough').

• Under-replicated partitions, ISR shrink/expand, controller changes.
• Producer errors (timeouts, `request latency`), consumer lag per group/partition.
• Broker I/O, page cache hit, GC, ZooKeeper/KRaft health.

8) Sécurité et multi-ténacité

Chiffrement TLS en transit, authentification (SASL/PLAIN/SCRAM/OAuth, mTLS).
Autorisation : vhost/permissions (RabbitMQ), ACL sur les tops/groupes (Kafka).
Quotas : connexions, canaux, taille de la file d'attente/topic, vitesse de publication/lecture.
Isolation par mercredi (dev/stage/prod) et par namespace/vhost.

9) Exploitation et tuning

RabbitMQ

Répartir les échanges/queues par nœuds (capacite CPU/IO).
Lazy queues (messages sur disque) pour les grands tampons ; évitez les files d'attente « chaudes » sans être charriées.
Queues Quorum pour HA ; prévoir la taille du Raft-magazine et du disque.
Les politiques TTL/length-limit, la priorité de la file d'attente seulement dans le besoin réel (cher).

bash rabbitmqctl set_policy DLX "^task\." \
'{"dead-letter-exchange":"dlx","message-ttl":60000,"max-length":100000}' --apply-to queues

Kafka

SSD/NVMe, réseaux rapides ; OS tuning (swapp....est faible, limites de fichiers).
`acks=all`, `linger. ms' (battage), 'compression. type = zstd'/lz4 pour le débit.
Paramètres du consommateur : 'max. poll. interval. ms`, `max. poll. records`, `fetch. min. bytes`.
Retraite et compaction - équilibre stockage/repli.

java props. put("acks","all");
props. put("enable. idempotence", "true");
props. put("max. in. flight. requests. per. connection","1");
props. put("retries","10");

10) Intégrations et écosystème

Kafka Connect (Sinks/Sources), Schema Registry (Avro/JSON/Protobuf) et compatibilité ("BACKWARD/FORWARD/FULL').
Kafka Streams/ksqlDB : opérations stateful, fenêtres, agrégats.
RabbitMQ Shovel/Federation : transfert entre les clusters/centres.
Opérateurs de K8s : Strimzi (Kafka), RabbitMQ Cluster Operator ; Les manifestes GitOps.

11) Chèque de mise en œuvre (0-45 jours)

0-10 jours

Définissez use-case's : commandes/tasks (RabbitMQ), événements/audits (Kafka).
Sélectionnez les clés (« routing key »/« partition key »), définissez le SLO « publikatsiya→obrabotka ».
Politiques de sécurité de base (TLS, ACL), quotas, DLQ/TTL.

11-25 jours

Implémenter outbox/inbox, idempotence et dedup.
Configurer les retraits avec backoff (Rabbit : TTL + DLX ; Kafka: retry topics).
Dashboards : lag, age, DLQ-rate, fin-à-fin latitude ; alerte.

26-45 jours

Réglage de la bande passante : prefetch/acks (Rabbit) ; partitions/acks/batch (Kafka).
Procédures DR (mise en miroir/réplication), tests de défaillance de nœud.
Documenter les contrats d'événements (schémas) et la politique d'interopérabilité.

12) Anti-modèles

Un outil « universel » pour toutes les tâches.
Absence de DLQ/TTL : empoisonneurs éternels (messages poison).
Illimité 'prefetch' → jeûne des consommateurs, croissance p99.
Kafka sans clés → perte d'ordre/lots chauds par défaut.
« Exactly-once » sans réel besoin/discipline est un faux sentiment de sécurité.
Secrets/logins dans le code, sans TLS/ACL.
Hardcode de schémas/versions de messages sans enregistrement et migrations.

13) Métriques de maturité

Lag/age SLO est exécuté ≥ 99 % du temps ; DLQ-rate sous contrôle.
L'idempotence couvre 100 % des voies critiques ; outbox/inbox mis en œuvre.
La retraite/compaction est documentée, la réplique ne brise pas les consommateurs.
Les alertes ISR/URP (Kafka) et Raft/Disk Limites (Rabbit) sont configurées.
Les contrats d'événements sont versionnés (Schema Registry), l'interopérabilité est testée dans CI.
Jours de jeu réguliers : panne de nœud/courtier/AZ, vérification de récupération.

14) Exemples de configues (résumé)

python channel. basic_qos(prefetch_count=200)
for msg in consume("tasks"):
try:
handle(msg)
channel. basic_ack(msg. delivery_tag)
except Transient:
channel. basic_nack(msg. delivery_tag, request = False) # will go to DLQ

java props. put("enable. auto. commit","false");
props. put("isolation. level","read_committed"); // при EOS
//...
poll -> process(idempotent) -> commitSync()

15) Conclusion

RabbitMQ et Kafka résolvent différentes classes de tâches : commandes/tasks et routage riche contre le journal d'événements à long terme et le streaming évolutif. Le succès réside dans les bonnes sémantiques de livraison, la discipline de l'idempotence, la clé réfléchie, les retraits/DLQ, l'observabilité et la sécurité stricte. Construisez autour des files d'attente une pratique d'ingénierie - outbox/inbox, schémas et politiques GitOps - et votre intégration deviendra prévisible, évolutive et durable.