Apache Kafka — Conceitos
Neste texto comentarei sobre a teoria e os principais conceitos do Kafka. Pretendo compartilhar um pouco do conhecimento que estou adquirindo em um curso e nos projetos que trabalho atualmente.
O que é Apache Kafka?
Segundo a própria Apache, Kafka é uma plataforma distribuída de streaming de dados que tem basicamente 3 capacidades:
- Publicar e subscrever fluxos (stream) de dados semelhante a uma fila de mensagens;
- Armazenar stream de dados em um sistema tolerante a falhas;
- Processar esse stream de dados.
Porém seguimos com a dúvida. Como o Kafka funciona? Simples, o produtor envia uma mensagem para um tópico, o tópico armazena essa mensagem e um consumidor lê essa mensagem. Na imagem a seguir temos um exemplo do fluxo mais básico do Kafka:
Conceitos
Broker
O Broker ou Kafka Node é uma instância de servidor que roda dentro do Kafka Cluster. O Kafka Cluster pode ser formado por um ou mais brokers. Além de atuar como um servidor, o broker tem a responsabilidade de armazenar partições dos tópicos (explicação item Tópico).
A capacidade de um broker na escrita e leitura de dados pode chegar as centenas de megabytes por segundo. Justamente por essa alta performance no processamento de mensagens, o Kafka, que inicialmente era um sistema interno do LinkedIn, passou a ser utilizada por várias empresas com altíssimas transações de dados (Uber, Netflix, Spotify, etc).
Durante o artigo veremos mais algumas diferenças entre os servidores tradicionais e os Kafka Brokers.
Mensagem
A mensagem dentro do Kafka é o elemento que transita entre todos os pontos da arquitetura. Ela contém os dados preenchidos pelo produtor, é armazenada dentro do tópico aguardando a leitura por parte um ou mais consumidores, até finalmente, ser utilizada pelo consumidor.
Cada mensagem é composta, sobretudo, por estes 3 itens:
- Header
- Key (opcional) [geralmente String]
- Valor [array de bytes, por exemplo String, JSON, etc]
Tópico (Topic)
O tópico é onde separamos as mensagens pelo seu objetivo, pela sua categoria.
Para ser criado, um tópico precisa de um nome, o número de partições (partitions) que ele terá e o fator de replicação (replication factory) que é o número de partições em sincronismo que esse tópico terá.
Temos alguns pontos importantes e fundamentais sobre tópicos:
- As mensagens publicadas dentro de uma partição são imutáveis.
- Cada mensagem dentro de uma partição recebe um identificador: offset. Este offset é sequencial e nunca é repetido dentro da mesma partição.
- Dentro de cada partição as mensagens estão ordenadas.
Mensagens, uma vez envidas para um tópico têm por padrão 7 dias para serem apagadas tendo sido consumidas ou não. Este comportamento é bem específico, por exemplo no RabbitMQ quando uma mensagem é lida, ela é automaticamente removida da fila.
Produtor (Producer)
O produtor pode ser um comando no terminal ou qualquer aplicação responsável por enviar uma mensagem para um tópico do Kafka.
Cabe ao produtor também definir o modo como a mensagem será armazenada dentro do tópico. Caso o produtor não envie nenhuma key junto com a mensagem, o load balancer enviará a mensagem para as partições de forma escalonável cíclica (round-robin). Já se o produtor enviar uma key junto com o valor da mensagem, é garantido que todas as mensagens para aquele tópico com aquela key irão sempre para a mesma partição. Esta regra somente se mantém válida enquanto o número de partições de um tópico se mantém igual.
Existem outras propriedades importantes dentro do producer como o acknowledgement, mas entraremos em detalhes no próximo post com a utilização de comandos em terminais.
Consumidor (Consumer)
O consumidor é responsável por ler uma mensagem de uma ou mais partições contidas em um tópico. Quando um consumidor está online e pronto para ler uma mensagem, ele solicita ao tópico a próxima mensagem para leitura.
O Kafka tem uma garantia que mensagens enviadas pelo produtor para uma mesma partição sempre serão adicionadas em ordem. Complementando essa regra, outra garantia é que o consumidor sempre lerá as mensagens da mesma partição na ordem em que foram armazenadas na partição.
Uma vez que um consumer faz parte de um Consumer Group, o Kafka armazena o offset da última mensagem lida em cada partição. Este offset tem o nome de consumer offset. Desta forma, ele consegue saber exatamente onde parou, caso tenha ficado offline por algum momento.
Na imagem anterior, o consumidor dentro de um consumer group leu até a mensagem de offset 4262, com isso, o Kafka sabe que assim que esse consumidor estiver ativo novamente, ele deve continuar da mensagem 4263 em diante.
Para finalizar, temos o último ponto a ser tratado neste post que é a vantagem de adicionar várias partições a um tópico. Um tópico separado em várias partições permite que consumers diferentes leiam cada partição separadamente, gerando assim maior performance de leitura e estabilidade do serviço. Cada consumer dentro de um grupo é responsável por ler partições exclusivas. Por exemplo, um tópico com 3 partições pode ser lido por até 3 consumidores diferentes.
Na imagem acima, vemos o consumer-group-application-1 com 2 consumers sendo que o Consumer 1 é responsável pelas partições 0 e 1 e o Consumer 2 é responsável pela partição 2. Este cenário só se alterará no caso de um consumer cair. Se isso acontecer, o outro consumer assume a(s) partição(ões) enquanto o outro não retorna. Assim que estiver com os 2 consumidores em pé novamente, retorna para o cenário inicial.
No conceito de Consumer Offsets, falta comentar apenas sobre Delivery semantics (modos de entrega). Trataremos no próximo post.
Conclusão
Sei que foi um post com pura teoria, mas são conceitos importantes para prosseguirmos para a prática que colocará muitas destas regras a prova.
