Nutshell Apache Kafka
Com a grande quantidade de dados sendo produzidos a cada segundo de várias maneiras como redes sociais, blogs, e-commerce, etc, dados estes que são armazenados em diferentes plataformas de diferentes maneiras e base de dados, demonstra a necessidade de se ter um sistema de mensageria que poderia trabalhar de forma assíncrona e com um baixíssimo acoplamento.
O Kafka, uma plataforma open-source de streaming distribuído construída pelo Linkedin e mais tarde comprada pela Apache escrita em Scala, tem revolucionado o processamento de eventos distribuídos em programação. Antes dele a indústria implementou suas próprias filas e sistema de Produtor/Consumidor, que demonstram limitações de escalabilidade e performance.
Com o Kafka, conseguimos agrupar o melhor dos mundos, com uma entrega escalável, com alta disponibilidade em um sistema distribuído de log.
Segue o que discutiremos nesse artigo:
1. Eventos
2. Tópicos
3. Broker
4. Produtor(Publisher)
5. Partições
6. Replicação
7. Grupos de Consumo
8. Controlador
9. Zookeeper
10. Message Queue
11. Publishers-SubscribersConceitos Básicos
É comum ouvirmos que o kafka atua como uma fila de mensagens, contudo, a semântica de fila de mensagens é diferente do que o kafka realiza. Em essência o Kafka é um Log de commits distribuído, pensado para ser tolerante a falhas, escalável e altamente disponível, conseguindo assim, atuar tanto como um broker de mensagem como sistema de Produtor/Consumidor.
Eventos
Um evento é qualquer coisa que acontece no mundo. Softwares geram eventos o tempo todo. Um usuário navegando por uma Rede Social, envia todas as suas informações para um back-end. Esses sistemas podem reunir estatísticas dos dados de eventos e extrair padrões, por exemplo o netflix pode recomendar novos filmes a partir do que o usuário assistiu antes.
Tópicos
Um tópico é uma agregação lógica de eventos. Um grupo de eventos que têm alguma característica em comum torna-se um tópico. Um site de notícias pode categorizar todos os eventos ocorridos dentro de tópicos como Política, Esportes, Entretenimento, tecnologia etc.
Componentes do Kafka
Broker
O broker é uma aplicação que realiza a persistência de eventos ou mensagens. Publishers(Produtores) podem utilizar APIs para publicarem mensagens em um broker. O Broker armazena as mensagens em uma ordem sequencial. Muito parecido com a idéia de WAL(Write-Ahead Log). Um arquivo de log é armazenado no disco. Quando uma nova mensagem é publicada, o broker adiciona uma nova entrada no fim deste arquivo.
As mensagens são persistidas com uma regra de retenção, ou seja, conseguimos configurar para as mesmas serem deletadas depois de um certo período ou serem persistidas indefinidamente. Cada mensagem escrita em um tópico tem um índice chamado Offset. Este índice é incrementado cada vez que uma nova mensagem é escrita.
Produtor(Publisher)
Um Produtor é um sistema que se publica eventos dentro de um broker. uma vez que a mensagem é publicada, o Publisher não se preocupa mais com o que acontece depois, desta maneira, Produtores e Consumidores são desacoplados entre si.
Um Produtor pode ser um servidor de upstream que é um produtor de logs ou um cliente enviando eventos da atividade de usuários em um website.
Partições
Um simples sistema de broker não é escalável pois é um único ponto de falha. Entretanto, um alto throughput de carga de mensagens não pode ser exposto em um simples broker. Para escalar o sistema de mensagens o Kafka utiliza o conceito de partições.
O conceito de partições do Kafka é similar ao que alguns Banco de Dados realizam. A ideia central é distribuir os dados em múltiplos brokers ao invés de utilizar apenas um simples broker. Um tópico dividido em partições, cada partição é gerenciada por um broker diferente, no caso de um simples broker falhar, as mensagens de uma partição tornam-se indisponíveis, contudo, mensagens de outras partições continuam aptas de leitura.
Cada evento pode ser imaginado como um par de chave-valor. Produtores podem usar várias estratégias para distribuir chaves entre partições. O padrão e abordagem eficiente é um hash de Consistência, embora outras estratégias como Hashing e partições baseadas em Ranges possam ser usadas também.
Na imagem acima, o tópico News é particionado baseado no seu tipo. Portanto, notícias relacionadas agora estão agrupadas dentro de uma única partição. Por exemplo, todas as notícias de Esportes vão ser adicionadas na partição 1, enquanto que notícias de políticas vão ser adicionadas na partição 2.
É importante notar que o Kafka não garante a ordem das mensagens entre partições. Contudo, todas as mensagens escritas dentro de uma simples partição é ordenada de acordo com sua data de criação(timestamp). Por exemplo, no diagrama acima, é garantido que o evento “Politics — UK Election” vem depois do “Politics — US Election”, mas nós não podemos dizer que “Technology — Self-driving cars” vem antes de “Politics — US Election” por que os dois eventos estão em partições separadas.
Replicação
Nesta última sessão, vamos falar de como o particionamento supera o simples ponto de falha, que é responder a pergunta, “o que fazemos se um broker que gerencia uma única partição parar de responder? Como vamos ler as mensagens escritas nessa partição?”
Replicação ou redundância de dados nos ajuda com isso. Cada partição tem uma réplica armazenada em um diferente broker. Mensagens são sincronizadas ou copiadas para essas réplica, então se a partição primária falhar, as mensagens vão ser lidas da réplica. Broker que gerenciam uma partição primária são conhecidos como líder(Leader) de uma partição, os broker que servem como réplicas são chamados de seguidores(followers).
Um broker pode ser líder de uma partição e funcionar como um seguidor de outra partição. Na figura abaixo o Broker 1 é líder da partição 0, mas é um seguidor da partição 1.
Produtores sempre escrevem os dados no Líder, uma vez que o líder comita os dados, os seguidores realizam pesquisas no líder para colocar suas réplicas em sincronia. Com o mecanismo de replicação o Kafka obtém tolerância a falhas.
Grupos de Consumo
Um grupo de consumo pode se inscrever para um ou mais tópicos. Cada grupo tem que ter pelo menos um consumidor e cada consumidor lê os dados de uma partição de um tópico utilizando um offset. As mensagens em uma partição não são deletadas quando o consumidor lê esses dados, portanto, essas mensagens ainda vão estar disponíveis para o consumo de outros grupos de consumidores.
Vamos assumir que temos um simples consumidor em um grupo e este consumidor lê de um tópico com duas partições. Neste caso, o consumidor vai ter que ler em ambas as partições. Para aumentarmos a velocidade de saída das mensagens(throughput), nós podemos adicionar outros consumidores para esse grupo. Adicionar um novo consumidor vai resultar em 1–1 mapeamento entre as partições e os consumidores.
Se tivermos mais consumidores do que o número de partições, esses consumidores vão ficar parados. Então, o número de consumidores em um grupo deve ser menor ou igual a quantidade de partições.
Controlador
Um dos Broker em um cluster é selecionado como um controlador. Quando um processo de um broker é iniciado, ele se registra no Zookeeper. o primeiro broker que for registrado no Zookeeper torna-se o Controlador.
A principal função de um controlador é checar os status de outros brokers. Além disso, quando um novo líder de uma partição é eleito, é o Controlador que comunica o mesmo e os outros brokers.
O Controlador periodicamente verifica se os outros brokers estão saudáveis no sistema. No caso de não receber a resposta de um broker em particular, ele executa um failover para outro broker e comunica o resultado da eleição do líder para os outros brokers do sistema.
Zookeeper
Atualmente, um cluster de kafka não funciona sem uma instância de Zookeeper. Para subir um cluster de kafka é necessário um gerenciamento de tópicos, partições, controladores e brokers. O Zookeeper gerencia as configurações do cluster de Kafka.
Nós vimos na seção anterior como um dos brokers é selecionado como um controlador pelo Zookeeper, o mesmo seleciona um novo controlador se um dos existentes parar de responder.
Zookeeper mantém uma lista de todos os brokers rodando em um cluster. Esta lista é atualizada quando um novo cluster se junta ou sai do sistema. Ele rastreia os tópicos, o número de partições atribuídas a esses tópicos e a localização das réplicas. Ele também gerencia a lista de controle de acesso para diferentes tópicos no cluster.
Como o Kafka é um message queu e um publisher-subscriber?
Message Queue
A Message Queue funciona como a fila da estrutura de dados. Produtores adicionam mensagens para o fim da fila e Consumidores leem as mensagens do começo da fila(FIFO).
Quando os Consumidores leem a mensagem, ele removê- la da fila, isto é uma das desvantagens do Message Queue. Múltiplos consumidores não podem ler a mesma mensagem da fila.
Publisher-Subscriber
Na arquitetura conhecida como Publisher-Subscriber(PubSub), tópicos são definidos. Publishers publicaram mensagens em diferentes tópicos. Subscribers se inscrevem para tópicos e leem os eventos publicados nesses tópicos.
Subscribers podem se inscrever em vários tópicos e múltiplas partições de um tópico.
Se o consumo de mensagens em um tópico aumentar, isso resultará em problemas de escalabilidade. Uma vez que existem limitações para melhorar o desempenho do Subscriber não poderemos aproveitar o paralelismo aqui para melhorar o rendimento geral.
Apache kafka
O Kafka aproveita as capacidades da fila de mensagens e da arquitetura do padrão de PubSub. O conceito de Grupo de Consumidor permite o Kafka utilizar o melhor dos dois grupos.
Similar ao PubSub, os Grupos de Consumos do Kafka podem se se escrever em vários tópicos. Dentro de um Grupo de Consumidor, o Kafka distribui a partição entre diferentes consumidores. Isto rebalanceia a carga de distribuição com a adição ou remoção de consumidores.
Quando o numero de partição é igual a quantidade de consumidores, o Kafka trabalha como uma Message Queue, cada consumidor vai ler uma mensagem apenas uma vez por partição do tópico. Adicionamente, ele também fornece persistência de mensagem dentro de uma partição de tópico.
Conclusão
Nós vimos nesse artigo o básico de construção de blocos do kafka.
- Eventos são imutáveis e são publicados por Produtores ou publishers.
- Kafka trabalha como log e commit distribuído. Brokers de mensagens são responsáveis por processar e persistir as mensagens.
- Um tópico no kafka é uma agregação lógica de eventos. O tópico é dividido em partições.
- Cada Partição é replicada para tolerância a falhas e redundância.
- Zookeeper funciona como um serviço centralizador de configurações.
- Kafka pode funcionar tanto como uma fila de mensagens quanto como um sistema de PubSub.
