Palestra do Edgar Mantovani sobre o Kafka

1. 29/04/2021 – Edgar Messias Mantovani
[São Paulo] MuleSoft Meetup Group
Conectando seu primeiro Hello World Mule ao
Apache Kafka

2. 2
● 10 anos de experiência no desenvolvimento e implementação de serviços
(SOA) e integrações utilizando tecnologias de empresas como TIBCO,
Oracle, Microsoft e MuleSoft.
● Atendendo a clientes de grande porte como Vale, Petrobrás, B2W, Latam e
Alpargatas.
Apresentador
Edgar Messias Mantovani – Integration/API Architect

3. 3
● Introdução
● Apache Kafka: Teoria e conceitos
● Conector Apache Kafka do Mulesoft Anypoint
● Demonstração
Agenda

4. O que que tem de bom aí?
Introdução

5. 5
O Apache Kafka foi criado por ex-engenheiros
de dados do LinkedIn, escrito em Scala e Java,
foi entregue em 2011 à comunidade open source
como um sistema de mensagens altamente
escalonavel podendo lidar com trilhões de
eventos diariamente.
Introdução
Desempenhando um papel significativo no cenário de streaming de eventos, o Kafka permite que
dados e registros envolvidos nos sistemas complexos de hoje sejam processados,
reprocessados, analisados ​​e manipulados - muitas vezes em tempo real. Os princípios de design
do Kafka foram formados com base na necessidade crescente de arquiteturas de alto rendimento
que sejam fáceis de escalonar​.

6. 6
Introdução
B R O K E R
T Ó P I C O
PA R T I Ç Ã O
0
A P L I C A Ç Ã O A P L I C A Ç Ã O
A PA C H E K A F K A
PA R T I Ç Ã O
1
PA R T I Ç Ã O
2
Baseado em publish-subscribe (publicação-assinatura) é um sistema que envia mensagens entre
processos, aplicativos e servidores. Os tópicos (pense como categorias) são definidos e as
aplicações podem adicionar, processar e reprocessar esses eventos.

7. Largue suas botas e mergulhe neste céu
Apache Kafka teoria e conceitos

8. Sem fila, vamos disseca-lo!
Tópicos no Kafka

9. 9
●Tópico é um determinado fluxo de dados
○Similar a uma tabela em um banco de dados;
○Possibilidade de ter o número de tópicos que quiser;
○Identificado por um nome único.
●Tópicos são divididos em partições
○Cada partição tem sua ordem;
○Cada mensagem tem um id incremental, que
chamamos de offset (deslocamento).
Tópicos, partições e deslocamentos (offsets)
my_first_topic
PARTIÇÃO 0
PARTIÇÃO 1
PARTIÇÃO 2
0 1 2 3 4 5 6 7 8 9
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7
escreve
escreve
escreve
o f f s e t s
> > >

10. 10
Tópicos, partições e deslocamentos (offsets)
E
B Y K E S _ T O P I C
S T A T I O N S _ T O P I C
●Imagine uma frota de bicicletas de uso compartilhado;
●Ao retirar uma bicicleta de uma estação via smartphone, o ID da mesma é associado à sua
conexão;
●Cada estação de bicicletas também tem seu ID;
●As estações enviam a localização (lat/lon) com os IDs das bicicletas estacionadas informando
quantas vagas existem disponíveis na estação em tempo real;
B Y K E S _ T O P I C
S T A T I O N S _ T O P I
C

11. 11
●Um offset só tem importância para aquela determinada partição (uma mensagem por
partição);
●O offset 3 na partição 0 não é a mesma mensagem do offset 3 na partição 1;
●A ordem é garantida somente na partição (não através das partições);
●Os dados são mantidos apenas por determinado período, sendo o padrão 7 dias de retenção;
●Um dado incluído não pode ser alterado (imutabilidade);
●Um dado é associado randomicamente a uma partição a menos que uma KEY seja
Tópicos, partições e deslocamentos (offsets)
stations_topic
PARTIÇÃO 0
PARTIÇÃO 1
PARTIÇÃO 2
1 2 3
1 2 3
1 2 3
{
"station":{
"id":10,
"occupied_positions":[1,3,5],
"free_positions":[2,4,6]
}
}
{
"station":{
"id":6,
"occupied_positions":[1,2,3],
"free_positions":[4,5,6]
}
}
0
0
0

12. Distribuir para conquistar.
Brokers e fator de replicação

13. 13
●Um cluster Kafka é composto de múltiplos
brokers (servidores);
●Cada broker é identificado por um ID;
●Cada broker contém certas partições do
tópico;
●Quando você se conectar a um broker,
estará conectado a um cluster inteiro;
●3 brokers seria um bom número para se
iniciar;
Brokers
B R O K E R 1
b y k e s _ t o p i c
PA R T I Ç Ã O
0
B R O K E R 3
B R O K E R 2
b y k e s _ t o p i c
PA R T I Ç Ã O
1
s t a t i o n s _ t o p i c
PA R T I Ç Ã O
0
s t a t i o n s _ t o p i c
PA R T I Ç Ã O
1
b y k e s _ t o p i c
PA R T I Ç Ã O
2
A PA C H E K A F K A C L U S T E R

14. 14
●Exemplo do bykes_topic com 3 partições;
●Exemplo do stations_topic com 2 partições;
●Exemplo do orders_topic com 4 partições (mais partições do que brokers) ;
Brokers
B R O K E R 1
b y k e s _ t o p i c
PA R T I Ç Ã O
1
B R O K E R 3
B R O K E R 2
b y k e s _ t o p i c
PA R T I Ç Ã O
2
s t a t i o n s _ t o p i c
PA R T I Ç Ã O
0
s t a t i o n s _ t o p i c
PA R T I Ç Ã O
1
b y k e s _ t o p i c
PA R T I Ç Ã O
0
A PA C H E K A F K A C L U S T E R
o r d e r s _ t o p i c
PA R T I Ç Ã O
1
o r d e r s _ t o p i c
PA R T I Ç Ã O
2
o r d e r s _ t o p i c
PA R T I Ç Ã O
0
o r d e r s _ t o p i c
PA R T I Ç Ã O
3

15. 15
●Tópicos podem ter fatores de replicação > 1 (usualmente entre 2 e 3);
●Assim, se um broker cai outro serve o dado no seu lugar.
●Exemplo: bykes_topic com 2 partições e fator de replicação igual a 2
Fator de replicação de um tópico
B R O K E R 1 B R O K E R 3
B R O K E R 2
A PA C H E K A F K A C L U S T E R
b y k e s _ t o p i c
PA R T I Ç Ã O
0
b y k e s _ t o p i c
PA R T I Ç Ã O
1
b y k e s _ t o p i c
PA R T I Ç Ã O
1
b y k e s _ t o p i c
PA R T I Ç Ã O
0
R É P L I C A
R É P L I C A

16. 16
Fator de replicação de um tópico
B R O K E R 1 B R O K E R 3
B R O K E R 2
A PA C H E K A F K A C L U S T E R
b y k e s _ t o p i c
PA R T I Ç Ã O
0
b y k e s _ t o p i c
PA R T I Ç Ã O
1
●Exemplo: perdemos o BROKER 2;
●Resultado: O BROKER 1 e o BROKER 3 continuam servindo dados.
●Zookeeper: mantém e gerencia informações de configuração, convenções de nomenclatura e
sincronização para ambientes em cluster distribuído.

17. 17
●Somente um broker pode ser um líder para
uma determinada partição (regra de ouro);
●Apenas esse líder recebe e serve dados para
uma partição;
●Os demais brokers irão sincronizar os dados;
●Cada partição tem um líder e múltiplos ISRs
(in-sync replicas)
Fator de replicação de um tópico: Líder
B R O K E R 1 B R O K E R 3
B R O K E R 2
A PA C H E K A F K A C L U S T E R
T Ó P I C O A
PA R T I Ç Ã O
0 L Í D E R
T Ó P I C O A
PA R T I Ç Ã O
0 I S R
R É P L I C A
T Ó P I C O A
PA R T I Ç Ã O
1 L Í D E R
T Ó P I C O A
PA R T I Ç Ã O
1 I S R
R É P L I C A

18. 18
●Somente um broker pode ser um líder para
uma determinada partição (regra de ouro);
●Apenas esse líder recebe e serve dados para
uma partição;
●Os demais brokers irão sincronizar os dados;
●Cada partição tem um líder e múltiplos ISRs
(in-sync replicas)
Fator de replicação de um tópico: Líder
B R O K E R 1 B R O K E R 3
B R O K E R 2
A PA C H E K A F K A C L U S T E R
T Ó P I C O A
PA R T I Ç Ã O
0 L Í D E R
T Ó P I C O A
PA R T I Ç Ã O
1 L Í D E R
T Ó P I C O A
PA R T I Ç Ã O
1 I S R
R É P L I C A

19. Foco na produção
Produtores

20. 20
●Produtores escrevem dados em um tópico;
●Produtores automaticamente sabem para qual broker e partição devem escrever;
●Em caso de falha no broker, o produtor é automaticamente recuperado.
Produtores
P R O D U T O R
B R O K E R 1
T Ó P I C O A
P A R T I Ç Ã O 0
B R O K E R 2
T Ó P I C O A
P A R T I Ç Ã O 1
B R O K E R 3
T Ó P I C O A
P A R T I Ç Ã O 2
E N V I A D A D O S
0 escreve
1 2 3 4 5
0 escreve
1 2 3
0 escreve
1 2 3 4
Automaticamente
balanceado por broker

21. 21
●Produtores podem escolher receber o reconhecimento (ack) da escrita do dado:
○acks=0: O produtor não espera pelo ack (possibilidade de perda de dados);
○acks=1: O produtor espera pelo ack do Líder (possibilidade limitada de perda de dados);
○acks=all: O produtor espera pelo ack do Líder e ISRs (sem perda de dados);
Produtores
P R O D U T O R
B R O K E R 1
T Ó P I C O A
P A R T I Ç Ã O 0
B R O K E R 2
T Ó P I C O A
P A R T I Ç Ã O 1
B R O K E R 3
T Ó P I C O A
P A R T I Ç Ã O 2
E N V I A D A D O S
0 escreve
1 2 3 4 5
0 escreve
1 2 3
0 escreve
1 2 3 4

22. 22
●Produtores podem escolher enviar uma KEY com a mensagem (string, number, etc);
●Se a KEY for nula, o dado é enviado de forma aleatória (round robin) para um dos brokers;
●Se uma KEY for enviada, todas as mensagens com a mesma KEY sempre irão para a mesma
partição;
●Uma KEY é basicamente enviada caso você precise de ordenação para um campo específico.
Produtores
B R O K E R 1
T Ó P I C O A
P A R T I Ç Ã O 0
B R O K E R 2
T Ó P I C O A
P A R T I Ç Ã O 1
E N V I A
D A D O S
E
P
R
O
D
U
T
O
R
●Exemplos:
○station_id_13 sempre estará na
partição 0
○station_id_17 sempre estará na
partição 0
○station_id_30 sempre estará na
partição 1
K E Y =
S T AT I O N _ I
D

23. 23
●No Kafka >= 0.11, você pode definir um “produtor idempotente” que não insere mensagens
duplicadas.
Produtores
PR OD U TOR
A PA C H E
K A FK A
1. Produz a mensagem
3. ACK não alcança o
produtor por erro de
rede
4. Tenta novamente
6. ACK recebido
2. Commit
Requisição idempotente
5. Detecta a
duplicação e não
executa o commit

24. Único propósito de toda produção.
Consumidores

25. 25
●Consumidores leem dados em um tópico (identificado pelo nome);
●Consumidores sabem de qual broker devem ler;
●Em caso de falha no Broker, o consumidor sabe como se recuperar automaticamente;
●Os dados são lidos em ordem em cada partição.
Consumidores
B R O K E R 1
T Ó P I C O A
P A R T I Ç Ã O 0
B R O K E R 2
T Ó P I C O A
P A R T I Ç Ã O 1
B R O K E R 3
T Ó P I C O A
P A R T I Ç Ã O 2
0 1 2 3 4 5
0
Leem em ordem
1 2 3
0 1 2 3 4
C O N S U M I D O R
C O N S U M I D O R

26. G R U P O C O N S . A
26
●Os consumidores leem dados em um grupo de consumidores;
●Cada consumidor em um grupo lê de uma partição específica;
●Se você tiver mais consumidores que partições, alguns consumidores ficarão inativos.
Consumidores
T Ó P I C O A
PA R T I Ç Ã O
0
T Ó P I C O A
PA R T I Ç Ã O
1
T Ó P I C O A
PA R T I Ç Ã O
2
C O N S U M I D O R
1
C O N S U M I D O R
2

27. 27
●Os consumidores leem dados em um grupo de consumidores;
●Cada consumidor em um grupo lê de uma partição específica;
●Se você tiver mais consumidores que partições, alguns consumidores ficarão inativos.
Consumidores
T Ó P I C O A
PA R T I Ç Ã O
0
T Ó P I C O A
PA R T I Ç Ã O
1
T Ó P I C O A
PA R T I Ç Ã O
2
G R U P O C O N S . B
C O N S U M I D O R
1
C O N S U M I D O R
2
C O N S U M I D O R
3

28. 28
●Os consumidores leem dados em um grupo de consumidores;
●Cada consumidor em um grupo lê de uma partição específica;
●Se você tiver mais consumidores que partições, alguns consumidores ficarão inativos.
Consumidores
T Ó P I C O A
PA R T I Ç Ã O
0
T Ó P I C O A
PA R T I Ç Ã O
1
T Ó P I C O A
PA R T I Ç Ã O
2
G R U P O C O N S . C
C O N S U M I D O R
1

29. 29
Consumidores
T Ó P I C O A
PA R T I Ç Ã O
0
T Ó P I C O A
PA R T I Ç Ã O
1
T Ó P I C O A
PA R T I Ç Ã O
2
G R U P O
C O N S U M I D O R
2
C O N S U M I D O R
3
C O N S U M I D O R 4
( I N A T I V O )
C O N S U M I D O R
1
●Os consumidores leem dados em um grupo de consumidores;
●Cada consumidor em um grupo lê de uma partição específica;
●Se você tiver mais consumidores que partições, alguns consumidores ficarão inativos.

30. Ú l t i m o c o n f i r m a d o
G R U P O D E
C O N S U M I D O R E S
30
●Kafka salva os offsets (deslocamentos) de cada grupo de consumidores que já foram lidos;
●Os offsets confirmados (commited) ficam registrados em um tópico Kafka chamado
__consumer_offsets;
●Quando o consumidor de um grupo de consumidores processa dados recebidos do Kafka, ele
fica comprometido a confirmar (fazer o commit) do offset lido;
●Como consumidor, ele será capaz de ler de onde parou (último offset confirmado).
Consumidores
0 1 2 3 4 5 C O N S U M I D O R
6 7
l i d o s
p e n d e n t e s

31. 31
●Os consumidores escolhem quando confirmar (commit) os offsets.
○Existem 3 semânticas de entrega:
Consumidores
At most once (Immediate) At least once (AUTO/MANUAL) Exactly once (Kafka para Kafka)
mensagem puxada uma vez mensagem puxada uma ou várias
vezes;
processada a cada vez
mensagem puxada uma ou várias
vezes;
processado uma vez
pode ou não ser recebida recebimento garantido recebimento garantido
sem duplicações prováveis duplicações sem duplicações
possibilidade de perda de dados sem perda de dados sem perda de dados
?


32. Hora de publicar e consumir
Conector Apache Kafka para o Mulesoft
Anypoint

33. 33
Simplifica processos de negócios à mover dados entre aplicativos e serviços corporativos
provendo conectividade para consumir e publicar no Apache Kafka de maneira rápida e
consistente.
Versão atual: 4.5.2
Data: 8 de Abril de 2021
Compatibilidade:
Conector Apache Kafka
Software Versão
Mule 4.1.1 and later
Apache Kafka 2.4.0, 2.5.0 e 2.7.0
OpenJDK 8 e 11

34. 34
Fonte de eventos:
Message listener Batch message listener
Operações:
Publish Consume
Commit Seek
Conector Apache Kafka

35. Hora de publicar e consumir
Demo

36. 36
● Recursos:
○ Curso - Learn Apache Kafka For Beginners (EN):
https://www.linkedin.com/learning/learn-apache-kafka-for-beginners/intro-to-apache-
kafka
○ Documentação - Kafka Connector (EN): https://docs.mulesoft.com/kafka-connector/4.5/
○ Site oficial do Apache Kafka: https://kafka.apache.org/
Para onde ir depois daqui?

37. Obrigado