Kafka broker, topic et partition : les concepts de base — chapitre 0

C’est quoi Kafka ?

Un Kafka broker est un serveur du cluster : il stocke les partitions des topics et répond aux producteurs comme aux consommateurs. Kafka est une plateforme distribuée de streaming d’événements conçue pour traiter des flux de données à grande échelle, en temps réel, avec une fiabilité et une performance exceptionnellement élevées.

• Publication et consommation de messages en temps réel.
• Très haut débit et faible latence.
• Résilience grâce à la réplication et au partitionnement.

Kafka = Messagerie + Journal distribué + Stockage persistant + Scalabilité horizontale

Concepts clés de Kafka

Partitionnement Kafka

Le partitionnement est la clé de la scalabilité de Kafka. Il permet d’augmenter le débit, de garantir la résilience et d’assurer le parallélisme des traitements.

• Scalable – le débit augmente avec le nombre de partitions.
• Rapide – traitement parallèle.
• Fiable – réplication automatique.

1. Principe

Un topic est divisé en plusieurs partitions réparties sur plusieurs brokers. Chaque message appartient à une seule partition.

2. Clé de partition

• Kafka utilise partition = murmur2(key) % nombre_de_partitions
• Même clé → même partition → ordre garanti
• Sans clé → partitionneur « sticky » : un lot entier sur une partition, puis la suivante (équilibrage, mais pas d’ordre)

3. Parallélisme

Dans un consumer group :

• 1 partition = 1 seul consumer du groupe à la fois (un consumer peut en lire plusieurs ; les consumers en surplus restent inactifs)
• En cas de panne → redistribution automatique

4. Réplication

• 1 leader : écritures / lectures (les followers peuvent servir les lectures si l’on active le « fetch from follower », KIP-392)
• Plusieurs followers : répliques synchronisées
• Failover automatique

5. Orchestration

• Jusqu’à Kafka 3.x → ZooKeeper (KRaft disponible en test dès 2.8, prêt pour la production en 3.3)
• Kafka 4.0+ → KRaft uniquement (quorum de contrôleurs interne, ZooKeeper supprimé)

6. Exemple de configuration

kafka-topics.sh --bootstrap-server localhost:9092 --create \
  --topic transactions \
  --partitions 6 \
  --replication-factor 3

Bonnes pratiques

Kafka = Topic → Partitions → Brokers → Consumers
Clé → ordre • Partitions → scalabilité • Réplication → tolérance aux pannes

Questions diverses

Le schéma : topic, partitions et offsets

Sous le capot : une partition sur le disque

Une partition n’est pas une abstraction : c’est un dossier sur le disque du broker, par exemple /var/lib/kafka/node1/orders-0/. Il contient des segments :

Fichier	Rôle
00000000000000000000.log	Les messages eux-mêmes, à la suite. Le nom = offset du premier message du segment
.index	Index offset → position dans le fichier, pour retrouver un message vite
.timeindex	Index date → offset, utilisé pour relire « depuis hier 10 h »
leader-epoch-checkpoint	Historique des leaders, pour réparer les répliques après une panne

• Quand un segment atteint segment.bytes (1 Go par défaut) ou segment.ms (7 jours), Kafka en ouvre un nouveau. La rétention supprime des segments entiers, jamais un message isolé.
• La partition est choisie par murmur2(clé) % nombre_de_partitions. Conséquence : augmenter le nombre de partitions change la destination des clés et casse l’ordre par client. Choisissez-le bien dès le départ.
• Sans clé, le producteur remplit une partition par lot puis passe à la suivante (partitionneur « sticky ») : bon débit, mais aucun ordre garanti.

Lab VM Ubuntu : voir une partition de ses propres yeux

kafka-lab.sh status   # le cluster du Chapitre 1 doit être UP
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic lab-orders --partitions 3 --replication-factor 3
# 100 000 commandes réparties sur 1 000 clients (format clé|valeur)
seq 1 100000 | awk '{printf "client-%d|{\"order\":%d,\"amount\":%d}\n", $1%1000, $1, ($1*7)%500}' > /tmp/orders.txt
kafka-console-producer.sh --bootstrap-server localhost:9092 --topic lab-orders \
  --property parse.key=true --property key.separator='|' < /tmp/orders.txt
# Où sont les messages ?
ls -lh /var/lib/kafka/node1/lab-orders-0/
kafka-dump-log.sh --files /var/lib/kafka/node1/lab-orders-0/00000000000000000000.log --print-data-log | head -20

Vérifiez qu’un même client tombe toujours dans la même partition :

# Le consommateur affiche "Partition:N<TAB>clé<TAB>valeur"
kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic lab-orders --from-beginning \
  --property print.key=true --property print.partition=true --max-messages 100000 2>/dev/null \
  | awk -F'\t' '$2 == "client-42" {print $1}' | sort | uniq -c
# Attendu : une seule ligne, par ex. "    100 Partition:1"

Ce que vous observez	Pourquoi
Environ 33 000 messages par partition	1 000 clés réparties par le hachage
client-42 apparaît dans une seule partition (100 fois)	Même clé → même partition
Le .log fait quelques Mo, le .index quelques Ko	L’index est « clairsemé » : une entrée tous les 4 Ko de données