Introduction
Plusieurs événements peuvent décrire la même commande : sa création, son paiement et son expédition. Si les enregistrements liés sont acheminés de manière cohérente, un consommateur peut suivre la séquence de cette commande au sein d'une partition. Une clé d'enregistrement fournit une donnée stable pour le routage ; elle se distingue de event_id, qui identifie une occurrence d'événement.
Vous allez publier des événements entrelacés pour trois commandes dans un topic à trois partitions, afficher leurs clés et positions réelles, puis ajouter un événement pour une commande existante. Un offset est la position d'un enregistrement dans une partition. Les offsets ne sont pas des numéros de ligne globaux du topic, et aucun ordre global unique n'est garanti entre les enregistrements de partitions différentes.
Le broker et les données d'entrée sont indépendants des autres labs. Des connaissances élémentaires du terminal suffisent. Les valeurs des événements sont du texte JSON lisible ; aucune programmation en Python ou en JSON, aucune configuration de cluster ni aucun topic issu d'un lab précédent ne sont nécessaires. Conservez le même nombre de partitions et la même stratégie de routage du client pendant toute l'expérience. Utilisez le terminal.
Publier des événements entrelacés avec une clé de commande
Dans cette étape, vous allez envoyer un identifiant de commande stable comme clé tout en conservant l'événement complet comme valeur. Inspectez le lot fourni de cinq enregistrements :
cd /home/labex/project
cat /home/labex/project/data/keyed-orders.txt
Chaque ligne suit le format key|value. La clé est un identifiant de commande. La valeur JSON contient des champs nommés entre accolades : event_id est unique, order_id correspond à la clé, sequence indique la séquence métier de cette commande et event_type décrit l'événement survenu. Le texte JSON est le format de la valeur ; Kafka ne l'interprète pas automatiquement comme un schéma de table.
Créez un topic avec trois partitions et un réplica :
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic orders-keyed --partitions 3 --replication-factor 1
Les options --reader-property du producteur définissent la façon dont il interprète les lignes d'entrée. parse.key=true et key.separator=| découpent chaque ligne au niveau du séparateur. Le séparateur lui-même ne fait partie ni de la clé ni de la valeur. L'opérateur < du shell fournit le fichier comme entrée standard, et le producteur se termine après avoir envoyé cette entrée de taille finie :
kafka-console-producer.sh --bootstrap-server localhost:9092 --topic orders-keyed --reader-property parse.key=true --reader-property 'key.separator=|' < /home/labex/project/data/keyed-orders.txt
Le fichier entrelace les commandes : les événements de order-2001 ne sont donc pas adjacents dans l'entrée. Lorsque la stratégie de routage par clé et le nombre de partitions restent identiques, les clés égales sont acheminées vers la même partition. Des clés différentes peuvent partager une partition ; trois commandes ne garantissent pas trois numéros de partition différents.
Publiez ce lot de cinq enregistrements une seule fois. Répéter une lecture avec un consommateur permet d'inspecter les données ; répéter cette commande du producteur ajoute cinq enregistrements supplémentaires. Si vous reprenez après la publication, passez à l'inspection avec le consommateur sans renvoyer le fichier.
Vous avez fourni la donnée utilisée pour le routage au lieu de choisir manuellement un numéro de partition. Vous allez maintenant lire les décisions de routage réelles plutôt que de les deviner.
Examiner ensemble les clés, les partitions et les offsets
Dans cette étape, vous allez afficher les métadonnées des enregistrements avec chaque valeur. Les options --formatter-property du consommateur en console contrôlent l'affichage en ajoutant la clé, la partition et l'offset à la sortie habituelle. Elles ne modifient pas le contenu des événements stockés. L'option de lecture depuis le début pour un nouveau consommateur, la limite de cinq messages et le délai d'inactivité rendent cette inspection finie reproductible. Enregistrez la sortie localement :
kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic orders-keyed --from-beginning --max-messages 5 --timeout-ms 30000 --formatter-property print.key=true --formatter-property print.partition=true --formatter-property print.offset=true > /home/labex/project/output/keyed-first.txt
cat /home/labex/project/output/keyed-first.txt
Chaque ligne de données doit présenter des champs sous cette forme générale, avec des nombres réels et une valeur JSON complète :
Partition:... Offset:... order-... {"event_id":"...",...}
Les séparateurs sont des tabulations. Repérez k1 et k3 : tous deux ont la clé order-2001 et doivent partager une partition, avec un offset plus grand pour k3. De même, k2 et k4 doivent partager la partition de order-2002. N'exigez pas que ces deux commandes utilisent des partitions différentes.
Les offsets appartiennent à la partition, pas à la clé. Si d'autres clés partagent cette partition, les offsets successifs d'une commande peuvent présenter des écarts. Le champ sequence du contenu est une valeur applicative ; Kafka ne l'a pas généré comme offset.
Le consommateur peut entrelacer les enregistrements de partitions différentes : l'ordre global de son affichage peut donc différer de celui du fichier du producteur. Vérifiez les événements liés à partir de leur clé, de leur partition et de leurs offsets croissants, sans considérer la sortie comme une liste unique dotée d'un ordre global.
Ajouter un événement pour une commande existante
Dans cette étape, vous allez tester la même règle de routage avec une nouvelle exécution du producteur. Anticipez le résultat pour l'événement shipped de order-2001 : il doit rejoindre la partition existante de cette commande et y suivre ses enregistrements précédents. Son offset exact dépend des autres enregistrements qui partagent cette partition.
La construction avec printf présentée dans le premier lab Kafka envoie une ligne complète avec clé au producteur en console configuré de la même manière :
printf '%s\n' 'order-2001|{"event_id":"k6","order_id":"order-2001","sequence":3,"event_type":"shipped"}' | kafka-console-producer.sh --bootstrap-server localhost:9092 --topic orders-keyed --reader-property parse.key=true --reader-property 'key.separator=|'
Lisez les six enregistrements conservés et enregistrez cette nouvelle observation :
kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic orders-keyed --from-beginning --max-messages 6 --timeout-ms 30000 --formatter-property print.key=true --formatter-property print.partition=true --formatter-property print.offset=true > /home/labex/project/output/keyed-with-shipped.txt
cat /home/labex/project/output/keyed-with-shipped.txt
Repérez k6 avec order-2001 et sequence 3. Comparez sa partition à celle de k1 et k3, puis son offset aux leurs. La séquence de la commande doit rester created, paid, shipped lorsqu'on la lit dans l'ordre des offsets de la partition. Aucun numéro de partition fixe n'est exigé.
L'observation initiale des cinq enregistrements reste dans keyed-first.txt. La nouvelle exécution du producteur a ajouté un événement sans remplacer les précédents. Le nombre de partitions du topic et la stratégie de routage peuvent influencer le routage ; cette expérience conserve donc volontairement les deux. Les clients utilisés par la suite devront choisir une stratégie de routage compatible s'ils ont besoin de la même correspondance entre différentes implémentations.
Vous disposez maintenant d'observations confirmant la stabilité du routage par clé et l'ordre propre à chaque partition, sans supposer un ordre global des événements ni une partition par commande. Le prochain défi applique ces mêmes compétences de gestion des topics, de rétention et de publication avec clés à un nouveau lot.
Résumé
Vous avez fourni des clés de commande, inspecté les partitions et les offsets réels, puis vérifié qu'un événement ajouté suivait les enregistrements précédents de sa commande avec la même règle de routage. Vous avez distingué les identifiants d'événement, les clés de commande, la séquence du contenu et les offsets de partition, sans supposer un ordre global. Le prochain défi combine ces compétences avec la configuration de la rétention d'un topic pour un nouveau lot.
