Olá pessoal, eu me chamo Ronaldo Lanellas e nesse vídeo a gente vai falar sobre o que são Consumer Clients e Consumer Groups no Apache Cap. Bom, pra gente começar, é interessante a gente entender que o consumidor, o papel dele é ler aquelas mensagens que chegaram no tópico através do produtor. E aqui, deixa eu colocar o ponteiro. E aqui, quando a gente fala de consumidores, se divide em dois grandes, vamos dizer assim, nomenclaturas. Primeiro a gente fala do consumer group. Então assim, o grupo de consumidores em português, que em geral é mais adotado como um grupamento lógico. Grupamento lógico de que? De consumidores. Então o que acontece aqui é que você vai ter um consumer group, que pode ter um ou mais consumidores dentro. E aí esses consumidores entendem que é a sua aplicação de fato. Os consumidores estão dentro do consumir grupo como eu falei. Então olhando aqui para o desenho, o que a gente tem? A gente tem um grupo de consumidores chamado A e um grupo de consumidores chamado B. E dentro do grupo A a gente tem o consumer 1 e o consumer 2, que são, podem ser a mesma aplicação, quando eu digo a mesma aplicação, mesmo código, mesmo repositório no GitHub, mas quando a gente falar de aplicação rodando, seja no Kubernetes ou qualquer outro lugar, vão ser duas instâncias diferentes. diferente, tá? Então eu tenho a aplicação 1 e a 2. Pode ser inclusive a mesma instância só que threads separadas. Você já vai entender por quê, mas nesse caso a gente vai ter fisicamente duas aplicações apartadas ou a mesma aplicação, mas threads separadas dentro da mesma aplicação. Então, quando a gente fala de Golang, por exemplo, a gente está falando que pode ser uma aplicação Go com duas Go Routines. Java, mesma coisa, é uma aplicação Java com duas threads ou duas aplicações Java separadas. Então, cada aplicação dessa que está dentro do Consumer Group faz o consumo do tópico. Lembra que o Consumer Group é só uma divisão lógica. Quem faz realmente o consumo do tópico é essa aplicação que está dentro do Consumer Group. Mas é muito importante você saber que existe o conceito de Consumer Group, porque na hora que você vai configurar sua aplicação existe uma propriedade que o nome é group.id. Esse group.id é exatamente o nome desse consumer group. E aí a gente vai falar um pouco sobre o que são as características de um consumer group. Por que ele é tão importante? Primeiro, como eu já falei, ele pode possuir um ou mais consumers, que são as suas aplicações dentro desse grupo lógico. Cada mensagem recebida é enviada para apenas o único consumer. Isso é muito importante. Cada mensagem recebida é enviada para apenas o único consumer dentro do grupo. Vou voltar aqui no desenho só para explicar para vocês. Então, imagina a seguinte situação. Nesse tópico, chegou uma mensagem Olá. Essa mensagem vai ser entregue ou do Consumer 2, do Consumer Group A. Então é um end aqui, e vai ser entregue também no Consumer Group 1 ou no 2. Então é assim, ela não vai ser entregue no 1 e no 2 do A, nem no 1 e no 2 do B. Ela vai ser sempre entregue em uma aplicação do A e outra aplicação do B, tá? Porque existe uma garantia de unicidade, ou seja, de não duplicação da mensagem por Consumer Group, tá? Então, dentro do mesmo Consumer Group, você só vai receber a mensagem, aquela mensagem, em apenas uma única aplicação sua, tá? Consumer Groups distintos podem receber a mesma mensagem como acabei de falar. Os offsets de commit são compartilhados entre todos os consumers. Então, quando a gente fala aqui desse consumer grupo A, dentro dele, como eu falei, a gente pode ter vários consumers e os offsets são compartilhados. Como assim? Se o consumer 1 disse que ele está lendo a mensagem do offset 1000, o consumer 2 também. Se acontece algum rebalance, que a gente vai falar um pouco mais para frente o que é rebalance, o consumer 2 vai continuar do 1000. Ou 1001, enfim. De qualquer que seja o offset que foi comitado pelo um. E vice-versa. Então, essa informação de offset ela é compartilhada. Quando um consumidor entra e sai do grupo, ocorre o evento de rebalos. Foi o que eu falei. A gente vai falar nas outras aulas o que é rebalos em detalhes, mas assim entenda que dado o consumer grupeirar, quando um ou dois eles saem ou entram do grupo então você tem um grupo um pode sair por algum motivo pode, a aplicação pode morrer, enfim ou pode entrar um outro consumer um 3, por exemplo quando isso acontece, o KT entende que aquele consumer group precisa de um rebalance. Por quê? Ele precisa rebalancear todas as partições entre os consumidores. E aí, lembra que eu falei ainda há pouco que o offset é compartilhado? Ele é compartilhado porque para cada consumer group existe uma mensagem lá num tópico chamado commit offset, tá? É um tópico interno do Kafka. E aí esse commit offset, ele grava o offset do consumer group e não do consumer dentro do consumer group. Sendo assim, não importa se você tem 10 ou 20, conforme você for colocando novos consumidores ou removendo consumidores, eles vão ler esse commit offset para saber qual é o próximo offset que eles têm que comitar. E aí, quando a gente fala de consumer, que é essa aplicação dentro do Consumer Group, como eu falei, cada thread ela só pode se escrever em apenas uma única partição. Então, pensa assim, vamos colocar de um jeito mais simples, você tem uma aplicação em Go, que tem duas Go routines, então você tem duas threads. Cada uma dessas threads ela só pode ler de uma partição do top. Cada uma dessas threads só pode ler de uma partição do tópico. Então, se o seu tópico tem duas partições, você vai ter uma goroutine plugada em uma thread, em um tópico, desculpa, em uma partição do tópico, e outra goroutine plugada em outra partição desse mesmo tópico. Você nunca vai ter a situação onde a mesma thread vai estar plugada em duas partições. Cada thread pode estar em apenas um único consumer group. Eu coloquei thread porque é um nível mais baixo de granularidade. Geralmente a gente não usa thread, geralmente a gente usa instância da aplicação. Imagina que você está rodando um kubernetes e a sua aplicação. Então, você vai ter lá, imagina que você está rodando um Kubernetes, a sua aplicação vai rodar em 5 pods, alguma coisa assim. E cada pod, cada instância vai ler de uma partição. Então, se você não tem, não quer escalar usando pods ou qualquer outro tipo de serviço, aí você pode usar um nível de thread, enfim, um nível um pouco mais contido dentro da sua aplicação. E quem realiza o commit é o consumer. Então, como eu falei, o consumer group é só uma divisão lógica, mas quem realiza o consumo, o commit das mensagens, é todo o seu consumer da sua aplicação. Certo? Espero que vocês tenham gostado e até a próxima.