O Apache Kafka é um broker de mensageria assim como Rabbit MQ, Active MQ, IBM MQ e outros. Apesar de similar, possui conceitos distintos que o tornam tão especial. Não é raro nos depararmos com termos desconhecidos, para isso segue abaixo uma lista de termos que podem lhe ajudar a melhorar suas conhecimentos de Kafka.
Este Glossário é vivo e não exaustivo, será atualizado conforme necessidade, fique a vontade para comentar um termo que você gostaria de ver neste post.
Termo | Explicação |
Cluster | Conjunto de instâncias (podendo ser VMs, PODs, Containers, etc …) que garantem a alta disponibilidade do Kafka. |
Nós | Local onde o serviço do Kafka está realmente instalado. Existem muitas maneiras de instalar o Kafka, podendo ser um serviço no SystemD do Linux, um Container no Kubernetes ou mesmo no Docker Compose. Cada um desses serviços Kafka possuem um broker.id e são portanto considerados nós do Cluster. |
Tópico | Fazendo uma analogia com um banco de dados relacional, os tópicos são como tabelas, onde os dados são armazenados. |
Partição | Cada tópico pode possuir uma ou mais partições, são como divisões físicas do tópico, para garantir paralelismo e maior disponibilidade, isso porque cada partição está fisicamente armazenada em um nó distinto. Isso significa que você pode ter um tópico com 3 partições, onde cada partição está localizada fisicamente no nó 0, 1 e 2. |
Consumer Group | Conjunto de consumidores que irão consumir de um tópico-partição. |
Consumer | Cada instância da sua aplicação dentro de um consumer group é chamada de consumer. Por exemplo, se você tem 4 PODs no Kubernetes, então você tem 4 consumers no seu consumer group. |
Rebalance | Cada partição de um tópico aceita apenas um consumer de um consumer group. Quando este consumer “morre”, o Kafka precisa encontrar outro consumer, do mesmo consumer group, para ler desta partição. Esse processo de procurar outro consumer para uma partição é chamado de Rebalanceamento. |
Key | Uma mensagem do Kafka pode conter uma chave/key. Esta é utilizada para ordenação de mensagens, onde toda mensagem com a mesma Key sempre irá ser produzida na mesma partição. |
Value | Conteúdo da mensagem no Kafka, sempre em bytes. Mesmo que você grave em um formato específico, a mensagem é grava em formato de bytes internamente. |
Header | Headers da mensagem Kafka que podem ser utilizados como metadados da mensagem, sempre no formato chave/valor. |
Producer | Produtor responsável por gravar mensagem em um tópico-partição do Kafka. |
Zookeeper | Realiza a eleição de líderes do cluster de Kafka e grava metadados dos clusters. |
Kraft | A partir da versão 2.8 do Kafka, foi implantado um novo mecanismo de eleição de líderes, conhecido como Raft, com algumas modificações este ficou conhecido como Kraft (Kafka + Raft). A ideia é substituir o Zookeeper. |
Kafka Connect | Como parte da Plataforma Kafka, o Kafka Connect tem a função de ler de origens diversas e gravar no Kafka (Source Connector) e ler do Kafka e gravar em origens diversas (Sink Connector). Muito similar a uma ferramenta de ETL. |
MirrorMaker | Se você possuir mais de um Cluster de Kafka e precisa sincronizar os dados entre eles, o MirrorMaker é a ferramenta responsável por esta tarefa. O MirrorMaker 2 inclusive usa o Kafka Connect para realizar essa tarefa de ler de uma origem Kafka e gravar em um destino Kafka. |
kSQL DB | É uma ferramenta de streaming de dados, onde você pode fazer vários operações com os dados que chegam nos tópicos, tais como, join, filter, aggregate e etc. |
Schema Registry | Tem o objetivo de guardar os esquemas das mensagens, evitando que eles precisem ser transportados junto com as mensagens, aumentando o tamanho do payload. Dessa forma as aplicações podem consultar o Schema Registry API para pegar os esquemas corretos de cada mensagem. |
RestProxy | Uso de Rest API para consumir e produzir do Kafka. |
AKHQ | Uma das muitas interfaces gráficas de gerenciamento do Kafka. |
Strimzi | Facilita a instalação do Kafka e suas ferramentas (Kafka connect, Kafka Exporter, Kafka Bridge, Cruise Control e MirrorMaker) no Kubernetes. Além de permitir o gerenciamento do Kafka usando CRDs. |
JMX | Java Management Extensions (JMX) é uma tecnologia responsável por expor informações para monitoria e controle da sua aplicação. |
Jolokia | Em vez usar um protocolo específico como JMX, o Jolokia é uma biblioteca que converte JMX para Rest API, facilitando a consulta de métricas usando HTTP/1. |
ACL | Access control lists (ACLs) permite gerenciar os acessos ao Kafka, tais como, quem pode produzir e consumir em determinado tópico, ou criar tópicos e etc. |
Offset | Posição da mensagem no tópico-partição. Por exemplo, sua mensagem pode estar no offset 100 , da partição 3. |
Lag | LAG = (offset da última mensagem do tópico-partição) – (offset atual do consumer group neste mesmo tópico-partição) . O Lag é a quantidade de mensagens que ainda não foram commitadas. |
Commit | O consumer realiza commits para mover o seu offset. O commit é um marcador da última mensagem que foi lida pelo consumer, assim, se ele reiniciar poderá voltar a mesma posição anterior. |
Free Consumer | Quando um consumer group não possui a propriedade group.id ele é considerado um Free Consumer, neste caso todo controle de offset deve ser feito pela própria aplicação e não pelo Kafka, dado que neste caso o consumer não faz commit das mensagens. |
Poison Pill | o termo refere-se a uma mensagem que, quando consumida por um consumidor, causa uma falha ou exceção durante o processamento. Essas mensagens podem ser problemáticas, pois podem interromper o fluxo normal de processamento e levar a um estado de erro. |
Under-Replicated Partitions | Partições que têm menos réplicas armazenadas do que o desejado, indicando que a replicação não está completa. |
Partition Leader | Broker que atua como a autoridade principal para uma partição específica de um tópico no Apache Kafka. Ele é responsável por gerenciar todas as operações de leitura e gravação para essa partição. |
In-Sync Replicas (ISR) | Conjunto de réplicas de uma partição de um tópico Kafka que estão atualmente alinhadas e sincronizadas com o líder da partição. Para que uma réplica seja considerada “in-sync”, ela deve ter copiado todas as mensagens que foram escritas no líder até um determinado ponto no tempo. |
Idempotência | Trata-se de um conceito onde uma aplicação pode receber a mesma requisição várias vezes e o resultado final será o mesmo, dizemos que ela é idempotente. Por exemplo, você envia 3 operações de débito repetidas mas as próximas duas são ignoradas porque uma já foi efetivada. Esse conceito também se aplica a um produtor Kafka, que pode ter habilitada a flag enable.idempotence |
Acknowledgement ou ack | Quando uma mensagem é produzida no Kafka, você tem a opção de dizer quantos brokers devem persistir a mensagem antes de retornar ao produtor. Podendo ser: todos, apenas o líder da partição ou nenhum. |
Comments
Offset
Author
adicionado.
Free consumer
Author
Adicionado
Perfeito
Dando meu 1 centavo para contribuir:
”poison pill“
o termo refere-se a uma mensagem que, quando consumida por um consumidor, causa uma falha ou exceção durante o processamento. Essas mensagens podem ser problemáticas, pois podem interromper o fluxo normal de processamento e levar a um estado de erro.
”Under-Replicated Partitions“
Partições que têm menos réplicas armazenadas do que o desejado, indicando que a replicação não está completa
”Partition Leader“
e um broker que atua como a autoridade principal para uma partição específica de um tópico no Apache Kafka. Ele é responsável por gerenciar todas as operações de leitura e gravação para essa partição
In-Sync Replicas (ISR) :
In-Sync Replicas são um conjunto de réplicas de uma partição de um tópico Kafka que estão atualmente alinhadas e sincronizadas com o líder da partição. Para que uma réplica seja considerada “in-sync”, ela deve ter copiado todas as mensagens que foram escritas no líder até um determinado ponto no tempo.
Author
Muito bom, já adicionei estes termos. Obrigado
Acknowledgement ou ack
Author
Adicionado