Kafka : topics, partitions et offsets
Kafka conserve des flux d'événements dans des journaux partitionnés que plusieurs applications lisent à leur rythme. On l'utilise pour diffuser des événements en continu entre systèmes.
- kafka
- topic
- partition
- offset
- consumer group
- at-least-once
- streaming
- commit
Syntaxe
topic « commandes » (journal append-only, conservé N jours) partition 0 : [o0][o1][o2][o3] … ← l'offset est la position dans la partition partition 1 : [o0][o1][o2] … partition 2 : [o0][o1] …Producteur : clé du message → choix de la partition (même clé = même partition)Groupe de consommateurs « facturation » : chaque partition est lue par un seulmembre du groupe ; le groupe enregistre l'offset atteint par partition (commit).Exemple
# Bibliothèque : confluent-kafkafrom confluent_kafka import Consumerconsommateur = Consumer({ "bootstrap.servers": "kafka:9092", "group.id": "facturation", "enable.auto.commit": False, # on valide nous-mêmes l'offset "auto.offset.reset": "earliest", # premier démarrage : depuis le début})consommateur.subscribe(["commandes"])while True: msg = consommateur.poll(1.0) if msg is None: continue if msg.error(): journaliser(msg.error()) continue facturer(msg.key(), msg.value()) # traitement idempotent (clé = n° de commande) consommateur.commit(message=msg, asynchronous=False)# Topic à 3 partitions, 2 consommateurs dans le groupe « facturation » :# l'un lit 2 partitions, l'autre 1.# Panne entre facturer() et commit() : au redémarrage, le message est relu.# C'est la livraison « au moins une fois » : d'où le traitement idempotent.À retenir
- L'ordre n'est garanti qu'à l'intérieur d'une partition. Choisissez comme clé l'entité dont l'ordre compte (numéro de commande, identifiant client).
- Le nombre de partitions plafonne le parallélisme d'un groupe : avec 3 partitions, un quatrième consommateur du même groupe reste inactif.
- Plusieurs groupes lisent le même topic indépendamment : la facturation et l'entrepôt ont chacun leurs offsets, sans se gêner.
- Piège : valider l'offset avant d'avoir fini le traitement. Une panne entre les deux perd le message (« au plus une fois ») ; validez après, et rendez le traitement idempotent.
Voir aussi
- Capture des changements (CDC)La CDC lit le journal de transactions de la base source pour émettre chaque insertion, modification et suppression. On l'utilise pour répliquer en quasi temps réel sans requêter les tables.
- Idempotence : rejouer sans doublonUne tâche idempotente produit le même résultat qu'on la lance une fois ou dix. C'est la condition pour relancer un pipeline après une panne sans créer de doublons ni perdre de lignes.
- Formats de fichiers : CSV, JSON, Avro, ParquetLe format d'un fichier décide de ce qui coûte cher : écrire, lire, typer ou faire évoluer. On choisit CSV ou JSON pour échanger, Avro pour des messages, Parquet pour analyser.