Introdução
Um pedido é criado, outro pedido é criado e, depois, o primeiro é pago. Uma tabela de status atual talvez mostre apenas o estado mais recente de cada pedido. Um evento descreve algo que aconteceu, portanto os três fatos podem continuar sendo úteis como histórico. Sistemas que reagem a novos pedidos precisam de uma forma de transmitir esses fatos entre aplicações.
O Apache Kafka armazena e entrega registros de eventos. Um produtor envia registros, um broker é o servidor que os recebe e armazena, um tópico dá nome a um fluxo de registros e um consumidor os lê. O Kafka pode conectar aplicações que operam em momentos ou velocidades diferentes. Outras ferramentas de processamento podem calcular relatórios a partir desses eventos; este curso se concentra primeiro na entrega confiável e no progresso da leitura.
Você criará um tópico, observará um produtor e um consumidor em terminais separados e lerá os mesmos eventos novamente depois que o primeiro consumidor encerrar. O ambiente preparado tem um único broker e usa uma réplica; a implantação de clusters é um assunto separado. As seis primeiras atividades exigem apenas conhecimentos básicos de terminal. As atividades posteriores com clientes Python exigem funções, laços, dicionários, JSON e execução de scripts; a trilha de Python pode preparar você para elas. Java, Hadoop, Hive, Spark e contas externas não são pré-requisitos. Use o serviço Terminal.
Crie um lugar para os eventos de pedidos
Nesta etapa, você confirmará que o serviço Kafka preparado responde e criará um tópico. Mantenha este primeiro shell como Terminal A. Comece no seu diretório de trabalho:
## Terminal A
cd /home/labex/project
Os clientes de linha de comando já estão instalados. --bootstrap-server fornece um endereço inicial de broker usado para descobrir o cluster. Aqui, localhost:9092 é o serviço local preparado, e não uma conta externa. Liste seus tópicos para confirmar uma resposta real do broker:
## Terminal A
kafka-topics.sh --bootstrap-server localhost:9092 --list
Um ambiente de ensino limpo pode ainda não ter tópicos de aplicação. Crie orders-first. Um tópico contém uma ou mais partições, logs ordenados que armazenam seus registros. Comece com uma partição para facilitar o acompanhamento desta primeira sequência. --replication-factor 1 é adequado ao único broker preparado:
## Terminal A
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic orders-first --partitions 1 --replication-factor 1
Inspecione o novo tópico:
## Terminal A
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders-first
Localize o nome do tópico, PartitionCount: 1 e ReplicationFactor: 1. IDs, identificadores de líder e formatação podem variar. A criação do tópico estabeleceu o destino de armazenamento; ela ainda não enviou nenhum pedido nem instalou outro servidor.
O broker continuará em execução enquanto clientes produtores e consumidores de curta duração iniciam e encerram. A seguir, você usará essa separação para observar a chegada dos eventos.
Observe um cliente receber o que outro envia
Nesta etapa, você manterá um consumidor aguardando em um terminal e enviará três registros de outro. O serviço Terminal preserva seu shell com o tmux, um gerenciador de sessões de terminal. Uma segunda conexão no navegador inicialmente mostra a mesma sessão persistente. Crie uma sessão de shell separada e nomeada para o Terminal B, para que os clientes tenham prompts independentes.
No Terminal A, crie a sessão desacoplada. -d mantém seu terminal atual selecionado, -s nomeia a nova sessão e -c escolhe seu diretório inicial. Isso cria um shell, não outro broker Kafka:
## Terminal A
tmux new-session -d -s kafka-b -c /home/labex/project
Abra o mesmo serviço Terminal em uma segunda aba do navegador, mantendo o Terminal A aberto. Chame a nova aba de Terminal B e mude essa conexão para a sessão preparada:
## Terminal B
tmux switch-client -t kafka-b
Após a troca, pressione Ctrl-C uma vez para limpar qualquer entrada ainda não enviada ao terminal enquanto apenas o shell estiver ativo. Confirme o nome da sessão:
## Terminal B
tmux display-message -p '#S'
Espere kafka-b. O Terminal A mantém sua sessão original; os dois shells acessam os mesmos arquivos da VM. Mantenha esses papéis ao alternar entre as abas do navegador. Se a sessão nomeada já tiver sido criada durante este exercício, reutilize-a em vez de criá-la novamente.
No Terminal B, inicie o consumidor abaixo. Ele aguarda até ler três registros e encerra automaticamente. --from-beginning solicita o início dos registros retidos para este novo consumidor; --max-messages 3 limita seu trabalho e --timeout-ms 30000 limita a espera sem mensagens. O pipe envia a saída comum para tee, que a exibe e salva uma cópia 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
Deixe o Terminal B aguardando. Alterne para o Terminal A e envie o lote dentro do limite de 30 segundos sem mensagens. Se esse limite expirar antes de você enviar algo, inicie novamente o mesmo comando de consumidor no Terminal B e volte para enviar o lote. Se você já enviou os eventos, execute novamente apenas o consumidor para inspecionar os três registros retidos; reenviar o lote do produtor acrescentaria duplicatas:
## 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 aspas seguido de uma quebra de linha. O pipe fornece essas linhas ao produtor; este produtor de console trata cada linha como um registro de evento. Quando printf termina, seu fluxo de entrada fecha, então o produtor conclui os envios pendentes e encerra. Você não precisa digitar em um prompt interativo do produtor.
Volte ao Terminal B. Suas três linhas de dados devem ser:
order-1001 created
order-1002 created
order-1001 paid
Uma contagem de mensagens processadas ou diagnósticos do cliente também podem aparecer no terminal. O arquivo salvo deve conter os três valores de evento. Os dois fatos sobre order-1001 são registros separados; o evento paid não sobrescreveu seu evento created anterior.
O consumidor normalmente retorna ao prompt após três mensagens. Se você iniciar acidentalmente um cliente sem limites, Ctrl-C interrompe esse cliente em seu próprio terminal; isso não interrompe o broker nem exclui o tópico. Aqui, os limites permitem que o fluxo normal termine sem interrupção manual.
Leia os eventos retidos com um novo consumidor
Nesta etapa, você verificará se a leitura removeu os eventos. O primeiro consumidor já encerrou. Preveja o que um novo consumidor independente, começando no início dos registros retidos, deve encontrar: os mesmos três registros.
No Terminal B, execute um novo consumidor com limites e salve esta segunda leitura separadamente:
## 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 os mesmos três valores na mesma ordem dentro desta única partição. Você não enviou outro lote. Inspecione as duas observações locais pelo Terminal A:
## Terminal A
cat /home/labex/project/output/received-events.txt
## Terminal A
cat /home/labex/project/output/replayed-events.txt
Ambos devem conter os três eventos originais. Consumo e retenção no armazenamento são separados: ler não remove um registro do tópico. Este primeiro experimento usa novos consumidores de console. Mais adiante, você aprenderá como um grupo nomeado de consumidores salva seu progresso de leitura e por que uma opção de início não substitui uma posição válida já confirmada.
O Kafka manteve o histórico de eventos disponível depois que os dois clientes de curta duração encerraram. A seguir, você inspecionará propriedades de tópicos e verá como a configuração de retenção afeta a política de armazenamento independentemente do progresso do consumidor.
Resumo
Você identificou o papel do Kafka na entrega de eventos, criou um tópico com uma partição e observou clientes produtores e consumidores separados trocarem três eventos de pedidos. Um novo consumidor leu o mesmo histórico retido depois que o primeiro encerrou, mostrando que leitura e exclusão são operações diferentes. A seguir, você inspecionará as propriedades de partições, réplicas e retenção dos tópicos.
