Introduction
Une commande est créée, une autre est créée, puis la première est payée. Une table d’état actuel pourrait montrer uniquement le dernier état de chaque commande. Un événement décrit quelque chose qui s’est produit ; les trois faits peuvent donc rester utiles comme historique. Les systèmes réagissant aux nouvelles commandes ont besoin d’un moyen de transmettre ces faits entre applications.
Apache Kafka stocke et transmet des enregistrements d’événements. Un producteur envoie les enregistrements, un broker est le serveur qui les reçoit et les stocke, un topic nomme un flux d’enregistrements et un consommateur les lit. Kafka peut relier des applications fonctionnant à des moments ou à des vitesses différents. D’autres outils de traitement peuvent calculer des rapports à partir de ces événements ; ce cours se concentre d’abord sur la transmission fiable et la progression de lecture.
Vous créerez un topic, observerez un producteur et un consommateur dans des terminaux séparés, puis relirez les mêmes événements après la sortie du premier consommateur. L’environnement préparé à un seul broker utilise une réplique ; le déploiement de cluster est un sujet distinct. Les six premières activités nécessitent uniquement les bases du terminal. Les activités suivantes avec des clients Python nécessitent fonctions, boucles, dictionnaires, JSON et exécution de scripts ; le parcours Python peut vous y préparer. Java, Hadoop, Hive, Spark et les comptes externes ne sont pas des prérequis. Utilisez le service Terminal.
Créer un emplacement pour les événements de commande
Dans cette étape, vous confirmerez que le service Kafka préparé répond et créerez un topic. Gardez ce premier shell comme Terminal A. Commencez dans votre espace de travail :
## Terminal A
cd /home/labex/project
Les clients en ligne de commande sont déjà installés. --bootstrap-server fournit une adresse initiale de broker permettant de découvrir le cluster. Ici, localhost:9092 est le service local préparé, et non un compte externe. Listez ses topics pour confirmer une véritable réponse du broker :
## Terminal A
kafka-topics.sh --bootstrap-server localhost:9092 --list
Un environnement pédagogique neuf peut ne pas encore avoir de topics applicatifs. Créez orders-first. Un topic contient une ou plusieurs partitions, des journaux ordonnés stockant ses enregistrements. Commencez avec une partition pour faciliter le suivi de cette première séquence. --replication-factor 1 convient au seul broker préparé :
## Terminal A
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic orders-first --partitions 1 --replication-factor 1
Examinez le nouveau topic :
## Terminal A
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders-first
Repérez le nom du topic, PartitionCount: 1 et ReplicationFactor: 1. Les identifiants, les identifiants de leader et le format peuvent varier. Créer le topic a établi la destination de stockage ; cela n’a pas encore envoyé de commande ni installé un autre serveur.
Le broker continuera de fonctionner pendant que des clients producteurs et consommateurs de courte durée démarrent et s’arrêtent. Vous utiliserez ensuite cette séparation pour observer l’arrivée des événements.
Observer un client recevoir ce qu’un autre envoie
Dans cette étape, vous laisserez un consommateur en attente dans un terminal et enverrez trois enregistrements depuis l’autre. Le service Terminal conserve son shell avec tmux, un gestionnaire de sessions de terminal. Une seconde connexion du navigateur affiche initialement la même session persistante. Créez une session de shell distincte et nommée pour Terminal B afin que les clients aient des invites indépendantes.
Dans Terminal A, créez la session détachée. -d laisse votre terminal actuel sélectionné, -s nomme la nouvelle session et -c choisit son répertoire de départ. Cela crée un shell, et non un autre broker Kafka :
## Terminal A
tmux new-session -d -s kafka-b -c /home/labex/project
Ouvrez le même service Terminal dans un second onglet du navigateur en gardant Terminal A ouvert. Appelez ce nouvel onglet Terminal B et basculez sa connexion vers la session préparée :
## Terminal B
tmux switch-client -t kafka-b
Après la bascule, appuyez une fois sur Ctrl-C pour effacer toute saisie non soumise lorsque seul le shell est actif. Confirmez le nom de session :
## Terminal B
tmux display-message -p '#S'
Vous devez obtenir kafka-b. Terminal A conserve sa session originale ; les deux shells accèdent aux mêmes fichiers de VM. Gardez ces rôles lorsque vous changez d’onglet. Si la session nommée a déjà été créée pendant cet exercice, réutilisez-la au lieu de la recréer.
Dans Terminal B, démarrez le consommateur ci-dessous. Il attend de lire trois enregistrements, puis quitte automatiquement. --from-beginning demande le début conservé pour ce nouveau consommateur ; --max-messages 3 borne son travail et --timeout-ms 30000 limite l’attente inactive. Le pipeline transmet la sortie ordinaire à tee, qui l’affiche et en enregistre une copie locale :
## Terminal B
kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic orders-first --from-beginning --max-messages 3 --timeout-ms 30000 | tee /home/labex/project/output/received-events.txt
Laissez Terminal B attendre. Passez à Terminal A et envoyez le lot avant sa limite d’inactivité de 30 secondes. Si cette limite expire avant tout envoi, relancez la même commande de consommateur dans Terminal B, puis revenez envoyer le lot. Si vous avez déjà envoyé les événements, relancez uniquement le consommateur pour examiner les trois enregistrements conservés ; renvoyer le lot du producteur ajouterait des doublons :
## Terminal A
printf '%s\n' 'order-1001 created' 'order-1002 created' 'order-1001 paid' | kafka-console-producer.sh --bootstrap-server localhost:9092 --topic orders-first
printf affiche chaque valeur textuelle entre apostrophes suivie d’un saut de ligne. Le pipeline fournit ces lignes au producteur ; ce producteur console traite chaque ligne comme un enregistrement d’événement. Lorsque printf se termine, son flux d’entrée se ferme ; le producteur termine donc les envois en attente et quitte. Vous n’avez pas besoin de saisir dans une invite interactive de producteur.
Revenez à Terminal B. Ses trois lignes de données doivent être :
order-1001 created
order-1002 created
order-1001 paid
Un nombre de messages traités ou des diagnostics du client peuvent aussi apparaître dans le terminal. Le fichier enregistré doit contenir les trois valeurs d’événements. Les deux faits concernant order-1001 sont des enregistrements distincts ; l’événement paid n’a pas écrasé l’événement created précédent.
Le consommateur revient normalement à son invite après trois messages. Si vous lancez accidentellement un client non borné, Ctrl-C l’arrête dans son propre terminal ; cela n’arrête pas le broker et ne supprime pas le topic. Ici, les limites permettent au chemin normal de se terminer sans interruption manuelle.
Lire les événements conservés avec un nouveau consommateur
Dans cette étape, vous vérifierez si la lecture a retiré les événements. Le premier consommateur a quitté. Prévoyez ce qu’un nouveau consommateur indépendant partant du début conservé doit voir : les trois mêmes enregistrements.
Dans Terminal B, exécutez un nouveau consommateur borné et enregistrez séparément cette seconde lecture :
## Terminal B
kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic orders-first --from-beginning --max-messages 3 --timeout-ms 30000 | tee /home/labex/project/output/replayed-events.txt
Vous devez obtenir les trois mêmes valeurs dans le même ordre au sein de cette partition unique. Vous n’avez pas envoyé d’autre lot. Examinez les deux observations locales depuis Terminal A :
## Terminal A
cat /home/labex/project/output/received-events.txt
## Terminal A
cat /home/labex/project/output/replayed-events.txt
Les deux doivent contenir les trois événements originaux. Consommation et conservation du stockage sont séparées : lire ne retire pas un enregistrement du topic. Cette première expérience utilise de nouveaux consommateurs console. Vous apprendrez plus tard comment un groupe de consommateurs nommé enregistre sa progression de lecture et pourquoi une option de début ne remplace pas une position valide déjà validée.
Kafka a gardé l’historique des événements disponible après la sortie des deux clients de courte durée. Vous examinerez ensuite les propriétés des topics et verrez comment la configuration de conservation affecte la politique de stockage indépendamment de la progression des consommateurs.
Résumé
Vous avez identifié le rôle de transmission d’événements de Kafka, créé un topic à une partition et observé des clients producteur et consommateur séparés échanger trois événements de commande. Un nouveau consommateur a lu le même historique conservé après la sortie du premier, montrant que lecture et suppression sont des opérations différentes. Vous examinerez ensuite les propriétés de partition, de réplique et de conservation des topics.
