Introducción
Varios eventos pueden describir un mismo pedido: su creación, pago y envío. Si los registros relacionados se dirigen de forma coherente, un consumidor puede seguir la secuencia de ese pedido dentro de una partición. Una clave de registro proporciona un valor estable para el enrutamiento; es distinta de event_id, que identifica una ocurrencia de evento concreta.
Publicará eventos intercalados de tres pedidos en un tema con tres particiones, mostrará sus claves y posiciones reales y añadirá otro evento de un pedido existente. Un desplazamiento es la posición de un registro dentro de una partición. Los desplazamientos no son números de fila globales del tema, y los registros de distintas particiones no tienen un único orden global garantizado.
El bróker y los datos de entrada son independientes. Basta con conocimientos básicos de terminal. Los valores de los eventos utilizan texto JSON legible; no se requiere programar en Python o JSON, configurar un clúster ni disponer de temas de actividades anteriores. Mantenga constantes la cantidad de particiones y la estrategia de enrutamiento del cliente durante todo el experimento. Utilice la Terminal.
Publique eventos intercalados con una clave de pedido
En este paso enviará un identificador de pedido estable como clave y conservará el evento completo como valor. Inspeccione el lote de cinco registros suministrado:
cd /home/labex/project
cat /home/labex/project/data/keyed-orders.txt
Cada línea contiene key|value. La clave es un identificador de pedido. El valor JSON utiliza campos con nombre entre llaves: event_id es único, order_id coincide con la clave, sequence es la secuencia de negocio de ese pedido y event_type describe lo ocurrido. El texto JSON es el formato del valor; Kafka no lo interpreta automáticamente como un esquema de tabla.
Cree un tema con tres particiones y una réplica:
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic orders-keyed --partitions 3 --replication-factor 1
Las opciones --reader-property del productor configuran cómo interpreta las líneas de entrada. parse.key=true y key.separator=| dividen cada línea en el separador. El separador no pasa a formar parte de la clave ni del valor. El operador < del intérprete de comandos suministra el archivo como entrada estándar, y el productor termina después de enviar esa entrada finita:
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
El archivo intercala pedidos, de modo que los eventos de order-2001 no son adyacentes en la entrada. Con la misma estrategia de enrutamiento por clave y sin cambiar la cantidad de particiones, las claves iguales se dirigen a la misma partición. Distintas claves pueden compartir una partición; tres pedidos no garantizan tres números de partición diferentes.
Publique este lote de cinco registros una sola vez. Repetir una lectura del consumidor permite inspeccionar los datos; repetir este comando del productor añade otros cinco registros. Si retoma la actividad después de publicar, continúe con la inspección del consumidor sin volver a enviar el archivo.
Ha proporcionado el valor de entrada para el enrutamiento, en lugar de seleccionar manualmente un número de partición. A continuación, consultará las decisiones reales de enrutamiento en vez de adivinarlas.
Inspeccione conjuntamente claves, particiones y desplazamientos
En este paso mostrará los metadatos de cada registro junto a su valor. Las opciones --formatter-property del consumidor de consola controlan la presentación y añaden la clave, la partición y el desplazamiento a su salida habitual. No modifican el contenido almacenado de los eventos. La opción de inicio desde el principio para un consumidor nuevo, el límite de cinco mensajes y el tiempo de espera por inactividad permiten repetir esta inspección finita. Guarde la salida localmente:
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
Cada línea de datos debe mostrar campos con esta estructura general, utilizando números reales y un valor JSON completo:
Partition:... Offset:... order-... {"event_id":"...",...}
Los separadores son tabulaciones. Localice k1 y k3: ambos tienen la clave order-2001 y deben compartir una partición, con k3 en un desplazamiento mayor. Del mismo modo, k2 y k4 deben compartir la partición de order-2002. No exija que esos dos pedidos utilicen particiones diferentes.
Los desplazamientos pertenecen a la partición, no a la clave. Si otras claves comparten esa partición, puede haber saltos entre los desplazamientos sucesivos de un pedido. El campo sequence del contenido es un valor de la aplicación; Kafka no lo ha generado como desplazamiento.
El consumidor puede intercalar registros de distintas particiones, por lo que el orden global que muestra no tiene por qué coincidir con el archivo del productor. Compruebe los eventos relacionados mediante su clave, partición y desplazamientos crecientes, en lugar de interpretar la salida como una única lista con orden global.
Añada otro evento de un pedido existente
En este paso pondrá a prueba la misma regla de enrutamiento con otra invocación del productor. Anticipe el resultado del evento de envío de order-2001: debe ir a la partición que ya utiliza ese pedido y quedar después de sus registros anteriores. Su desplazamiento exacto depende de los demás registros que compartan esa partición.
El patrón printf del primer laboratorio de Kafka envía una línea completa con clave al productor de consola con los mismos ajustes:
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=|'
Lea los seis registros retenidos y guárdelos en una nueva observación:
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
Localice k6 con order-2001 y sequence 3. Compare su partición con la de k1 y k3, y su desplazamiento con los de esos registros. La secuencia del pedido debe seguir siendo created, paid, shipped al consultarla por orden de desplazamiento dentro de la partición. No se exige un número de partición fijo.
La observación original de cinco registros permanece en keyed-first.txt. La nueva ejecución del productor añadió un evento en lugar de reemplazar los anteriores. La cantidad de particiones del tema y la estrategia de enrutamiento pueden afectar a la asignación, por lo que este experimento mantiene ambas constantes de forma deliberada. Los clientes posteriores deberán elegir una estrategia de enrutamiento compatible si necesitan conservar la misma asignación entre implementaciones.
Ahora dispone de pruebas del enrutamiento estable por clave y del orden dentro de cada partición, sin suponer un orden global de eventos ni una partición por pedido. El siguiente desafío aplica estas mismas habilidades de temas, retención y publicación con clave a un lote nuevo.
Resumen
Ha proporcionado claves de pedido, inspeccionado particiones y desplazamientos reales y comprobado que un evento añadido quedó después de los registros anteriores de su pedido bajo la misma regla de enrutamiento. Ha distinguido los identificadores de evento, las claves de pedido, la secuencia del contenido y los desplazamientos de partición, sin suponer un orden global. A continuación, un desafío con un lote nuevo combina estas habilidades con la configuración de retención de temas.
