Introducción
Se crea un pedido, se crea otro pedido y después se paga el primero. Una tabla de estado actual podría mostrar únicamente el estado más reciente de cada pedido. Un evento describe algo que sucedió, por lo que los tres hechos pueden seguir siendo útiles como historial. Los sistemas que reaccionan a pedidos nuevos necesitan una forma de pasar esos hechos entre aplicaciones.
Apache Kafka almacena y entrega registros de eventos. Un productor envía registros, un broker es el servidor que los recibe y almacena, un tema (topic) nombra un flujo de registros y un consumidor los lee. Kafka puede conectar aplicaciones que funcionan en momentos o a velocidades diferentes. Otras herramientas de procesamiento pueden calcular informes a partir de esos eventos; este curso se centra primero en la entrega fiable y el progreso de lectura.
Creará un tema, observará un productor y un consumidor en terminales separadas y volverá a leer los mismos eventos después de que termine el primer consumidor. El entorno preparado de un solo broker utiliza una réplica; el despliegue de clústeres es un tema separado. Las seis primeras actividades requieren únicamente uso básico de terminal. Las actividades posteriores de clientes Python requieren funciones, bucles, diccionarios, JSON y ejecución de scripts; la ruta de Python puede prepararle para ellas. Java, Hadoop, Hive, Spark y cuentas externas no son requisitos previos. Utilice el servicio Terminal.
Cree un lugar para los eventos de pedidos
En este paso, confirmará que el servicio preparado de Kafka responde y creará un tema. Mantenga este primer shell como Terminal A. Comience en su espacio de trabajo:
## Terminal A
cd /home/labex/project
Los clientes de línea de comandos ya están instalados. --bootstrap-server proporciona una dirección inicial de broker utilizada para descubrir el clúster. Aquí localhost:9092 es el servicio local preparado, no una cuenta externa. Liste sus temas para confirmar una respuesta real del broker:
## Terminal A
kafka-topics.sh --bootstrap-server localhost:9092 --list
Un entorno didáctico limpio puede no tener todavía temas de aplicación. Cree orders-first. Un tema contiene una o más particiones, registros ordenados que almacenan sus eventos. Comience con una partición para que esta primera secuencia sea fácil de seguir. --replication-factor 1 corresponde al único broker preparado:
## Terminal A
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic orders-first --partitions 1 --replication-factor 1
Examine el tema nuevo:
## Terminal A
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders-first
Busque el nombre del tema, PartitionCount: 1 y ReplicationFactor: 1. Los ID, los identificadores de líder y el formato pueden variar. Crear el tema estableció el destino de almacenamiento; todavía no envió un pedido ni instaló otro servidor.
El broker permanecerá en ejecución mientras los clientes de corta duración de productor y consumidor se inician y terminan. A continuación, utilizará esa separación para observar la llegada de eventos.
Observe cómo un cliente recibe lo que envía otro
En este paso, mantendrá un consumidor esperando en una terminal y enviará tres registros desde otra. El servicio Terminal conserva su shell mediante tmux, un administrador de sesiones de terminal. Una segunda conexión de navegador muestra inicialmente la misma sesión persistente. Cree una sesión de shell separada con nombre para Terminal B, de modo que los clientes tengan indicadores independientes.
En Terminal A, cree la sesión separada. -d mantiene seleccionada la terminal actual, -s nombra la sesión nueva y -c elige su directorio inicial. Esto crea un shell, no otro broker de Kafka:
## Terminal A
tmux new-session -d -s kafka-b -c /home/labex/project
Abra el mismo servicio Terminal en una segunda pestaña del navegador y mantenga Terminal A abierta. Llame a la pestaña nueva Terminal B y cambie esa conexión a la sesión preparada:
## Terminal B
tmux switch-client -t kafka-b
Después del cambio, pulse Ctrl-C una vez para limpiar cualquier entrada de terminal no enviada mientras solo esté activo el shell. Confirme el nombre de la sesión:
## Terminal B
tmux display-message -p '#S'
Espere kafka-b. Terminal A conserva su sesión original; ambos shells acceden a los mismos archivos de la máquina virtual. Mantenga estos papeles al cambiar entre pestañas del navegador. Si ya creó la sesión con nombre durante este ejercicio, reutilícela en lugar de crearla otra vez.
En Terminal B, inicie el consumidor siguiente. Espera hasta leer tres registros y después termina automáticamente. --from-beginning solicita el principio retenido para este consumidor nuevo; --max-messages 3 limita su trabajo y --timeout-ms 30000 limita la espera inactiva. La tubería envía la salida normal a tee, que la muestra y guarda una copia local:
## 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
Deje Terminal B esperando. Cambie a Terminal A y envíe el lote dentro de su límite de inactividad de 30 segundos. Si ese límite vence antes de enviar nada, inicie otra vez el mismo comando de consumidor en Terminal B y después vuelva para enviar el lote. Si ya envió los eventos, repita solo el consumidor para examinar los tres registros retenidos; enviar de nuevo el lote del productor añadiría duplicados:
## 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 imprime cada valor de texto entre comillas seguido de un salto de línea. La tubería proporciona esas líneas al productor; este productor de consola trata cada línea como un registro de evento. Cuando termina printf, se cierra su flujo de entrada, por lo que el productor completa los envíos pendientes y termina. No necesita escribir en un indicador interactivo del productor.
Vuelva a Terminal B. Sus tres líneas de datos deberían ser:
order-1001 created
order-1002 created
order-1001 paid
También puede aparecer en la terminal un conteo de mensajes procesados o diagnósticos del cliente. El archivo guardado debería contener los tres valores de eventos. Los dos hechos de order-1001 son registros separados; el evento paid no sobrescribió su evento created anterior.
El consumidor normalmente vuelve a su indicador después de tres mensajes. Si inicia por accidente un cliente sin límites, Ctrl-C detiene ese cliente en su propia terminal; no detiene el broker ni elimina el tema. Aquí los límites hacen que el recorrido normal termine sin interrupción manual.
Lea los eventos retenidos con un consumidor nuevo
En este paso, comprobará si la lectura eliminó los eventos. El primer consumidor ha terminado. Prediga qué debería ver un consumidor independiente nuevo que empiece al principio retenido: los mismos tres registros.
En Terminal B, ejecute un consumidor nuevo limitado y guarde por separado esta segunda lectura:
## 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
Espere los mismos tres valores en el mismo orden dentro de esta única partición. No envió otro lote. Examine ambas observaciones locales desde Terminal A:
## Terminal A
cat /home/labex/project/output/received-events.txt
## Terminal A
cat /home/labex/project/output/replayed-events.txt
Ambas deberían contener los tres eventos originales. El consumo y la retención en almacenamiento son independientes: leer no elimina un registro del tema. Este primer experimento utiliza consumidores nuevos de consola. Más adelante aprenderá cómo un grupo de consumidores con nombre guarda su progreso de lectura y por qué una opción de inicio no sustituye una posición válida ya confirmada.
Kafka mantuvo disponible el historial de eventos después de que terminaran ambos clientes de corta duración. A continuación, examinará las propiedades de temas y verá cómo la configuración de retención afecta a la política de almacenamiento de forma independiente del progreso de los consumidores.
Resumen
Identificó el papel de Kafka en la entrega de eventos, creó un tema de una partición y observó cómo clientes separados de productor y consumidor intercambiaban tres eventos de pedidos. Un consumidor nuevo leyó el mismo historial retenido después de que terminara el primero, demostrando que leer y eliminar son operaciones diferentes. A continuación, examinará propiedades de partición, réplica y retención de los temas.
