Kafka, RabbitMQ, ActiveMQ

L'offre les cite comme « appréciés ». Ce n'est pas éliminatoire, mais l'équipe s'appelle Digital Backbone : c'est l'épine dorsale qui fait circuler les données entre les applications de Renault. Savoir en parler clairement te distingue.

Pourquoi un broker de messages

Sans broker, l'appli A appelle l'appli B directement. Si B est en panne ou lente, A est bloquée. Si C, D et E veulent aussi les données de A, A doit les appeler une par une.

Avec un broker, A publie un message (« commande 1234 créée ») et passe à autre chose. Le broker garde le message. B, C, D le consomment chacun à son rythme. Si B tombe, les messages l'attendent.

Bénéfices : découplage (A ne connaît pas ses consommateurs), résilience (une panne en aval ne bloque pas l'amont), absorption des pics (le broker sert de tampon).

Un Digital Backbone, c'est cette idée à l'échelle d'une entreprise : une plateforme commune d'échange de données (messaging, API, événements) que toutes les applications utilisent, au lieu de centaines de connexions point à point.

Les deux grands modèles

	File (queue)	Journal (log)
Représentant	RabbitMQ, ActiveMQ	Kafka
Que devient un message lu ?	Supprimé après acquittement	Conservé selon la rétention (jours, semaines)
Relire le passé	Non	Oui, on rembobine l'offset
Distribution	Le broker pousse vers les consommateurs	Les consommateurs tirent à leur rythme
Point fort	Routage fin, tâches à traiter une fois	Très gros débit, rejeu, flux d'événements

Kafka

Vocabulaire

Broker : un serveur Kafka. Un cluster en compte au moins 3 en prod.
Topic : un flux nommé (ex : vehicle.telemetry).
Partition : un topic est découpé en partitions. Chaque partition est un journal ordonné, ajouté à la fin uniquement. L'ordre est garanti dans une partition, pas entre partitions.
Offset : la position d'un message dans sa partition.
Clé : les messages de même clé (ex : l'ID du véhicule) vont toujours dans la même partition, donc restent ordonnés entre eux.
Réplication : chaque partition a un leader et des followers sur d'autres brokers. Facteur de réplication 3 en prod.
ISR (In-Sync Replicas) : les réplicas à jour. Si le leader tombe, un membre de l'ISR prend le relais.
Producer : écrit. Avec acks=all, il attend que tous les réplicas ISR aient le message.
Consumer group : des consommateurs qui se partagent les partitions d'un topic. Chaque partition est lue par un seul consommateur du groupe. 6 partitions et 3 consommateurs : 2 partitions chacun. 6 partitions et 8 consommateurs : 2 consommateurs inactifs.
Rebalance : redistribution des partitions quand un consommateur arrive ou part. Pendant ce temps, la consommation est en pause.

ZooKeeper et KRaft

Historiquement, Kafka dépendait de ZooKeeper pour les métadonnées du cluster. Depuis Kafka 3.3, le mode KRaft le remplace (Kafka gère son propre consensus). Kafka 4.0 a supprimé ZooKeeper.

Ce qu'on surveille en exploitation

Consumer lag : l'écart entre le dernier message écrit et le dernier lu par un groupe. S'il grandit, les consommateurs ne suivent pas. C'est l'indicateur n°1.
Under-replicated partitions : doit être à 0. Sinon un broker est en retard ou en panne.
Offline partitions : partitions sans leader, donc indisponibles. Incident critique.
Espace disque des brokers (la rétention remplit les disques), latence des producteurs, requêtes en attente.

kafka-topics.sh --bootstrap-server localhost:9092 --list
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic orders --partitions 6 --replication-factor 3
kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group billing   # colonne LAG
kafka-console-producer.sh --bootstrap-server localhost:9092 --topic orders
kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic orders --from-beginning

Scénario : le lag monte

Les consommateurs tournent-ils ? (crash, rebalance en boucle)
Y a-t-il un pic de production ?
Un consommateur bloque-t-il sur un message (message empoisonné qui plante le traitement) ?
La partition est-elle déséquilibrée (une clé très fréquente) ?
Remèdes : ajouter des consommateurs (dans la limite du nombre de partitions), augmenter les partitions (attention : ça change la répartition des clés), corriger le traitement lent, envoyer les messages en échec vers une DLQ.

Garanties de livraison

At most once : peut perdre, ne duplique jamais.
At least once : ne perd pas, peut dupliquer. Le plus courant. Les consommateurs doivent alors être idempotents (traiter deux fois le même message ne fait pas de dégât).
Exactly once : possible dans Kafka avec les transactions et les producteurs idempotents, plus coûteux.

RabbitMQ

Implémente le protocole AMQP 0-9-1. Le producteur n'écrit jamais directement dans une file : il publie vers un exchange, qui route vers des queues selon des bindings.

Types d'exchange :

Type	Routage
direct	Clé de routage exacte (`order.created` vers la file liée avec `order.created`)
topic	Motifs avec jokers : `order.*` ou `vehicle.#`
fanout	Copie à toutes les files liées, ignore la clé
headers	Selon les en-têtes du message

Notions d'exploitation :

Ack : le consommateur confirme le traitement. Sans ack, le message est redistribué si le consommateur meurt.
Prefetch (QoS) : combien de messages non acquittés un consommateur peut avoir. Trop haut, un consommateur lent accapare tout.
Dead Letter Exchange (DLX) : où partent les messages rejetés, expirés (TTL) ou en surplus. On y met une DLQ à surveiller.
Quorum queues : files répliquées sur plusieurs nœuds (algorithme Raft). Le choix recommandé pour la haute dispo, remplace les anciennes mirrored queues.
Streams : un mode journal à la Kafka, ajouté dans RabbitMQ 3.9.
Interface de gestion sur le port 15672, AMQP sur 5672.

rabbitmqctl cluster_status
rabbitmqctl list_queues name messages consumers
rabbitmq-diagnostics check_running

À surveiller : profondeur des files (messages qui s'accumulent), files sans consommateur, mémoire et disque (au-delà d'un seuil, RabbitMQ bloque les producteurs : c'est l'alarme mémoire ou disque).

ActiveMQ

Broker Java de la fondation Apache, implémente JMS (le standard de messaging Java). Très présent dans les SI historiques des grandes entreprises.

Queue (point à point : un seul consommateur reçoit le message) et Topic (publish/subscribe : tous les abonnés reçoivent).
Deux versions : ActiveMQ Classic (l'historique) et ActiveMQ Artemis (la nouvelle génération, plus performante, base de Red Hat AMQ).
Multi-protocole : OpenWire, AMQP, STOMP, MQTT.
Console web sur le port 8161, OpenWire sur 61616.

Sa présence dans l'offre suggère un existant à maintenir, et peut-être des migrations vers Kafka ou Pub/Sub.

Lequel pour quoi

Kafka : télémétrie véhicules, logs, flux d'événements à fort volume, besoin de rejouer.
RabbitMQ : tâches à distribuer (une commande à traiter une fois), routage complexe, latence faible.
ActiveMQ : applications Java legacy en JMS.
Pub/Sub : la version managée sur GCP, quand on ne veut pas opérer de cluster.

Questions d'entretien à préparer

C'est quoi un broker de messages et à quoi ça sert ?
Différence entre Kafka et RabbitMQ ?
C'est quoi une partition, un consumer group, un offset ?
Le consumer lag augmente, que fais-tu ?
Pourquoi ajouter un 10e consommateur sur un topic de 6 partitions ne sert à rien ?
C'est quoi une DLQ ?
Comment garantir qu'un message n'est pas perdu ? (acks=all, réplication 3, min.insync.replicas=2, ack côté consommateur après traitement)