Olá pessoal, eu me chamo Ronaldo Lanellas e nessa aula a gente vai entender como funciona o rebalance na pasta gráfica. Primeiro, o que é rebalance? A gente ouve muito falar de Putz, aconteceu o rebalance, duplicou mensagem, perdeu mensagem, enfim. O rebalance acontece por N motivos, tá? Na maioria dos casos, ele acontece quando um consumidor, deixa eu abrir o laser point aqui, ele acontece quando um consumidor, ele entra ou sai de um consumer group. Então, você tem um consumer grupo A, o consumidor 1 ele está além do tópico X da partição P0, e o consumer 2 está além do tópico X da partição P1. E aí o consumer 1, ele ficou down. Então, ele morreu, enfim. Nesse momento o rebalance começa. Então, o Kafka começa a fazer re rebalance porque ele viu que as partições estão mal distribuídas. Porque nesse momento aqui o que está acontecendo? O Consumer 2 estava na P1, mas a partição P0 não tem ninguém, porque o Consumer 1 morreu. Então o Kafka vai rebalancear, colocando as duas partições para o consumer2 que é onde restou. E aí o rebalance terminou. Isso é um rebalance. A tentativa do Kafka de redistribuir as partições para que nenhuma delas fique por exemplo com menos ou mais consumidores. Nesse caso o P0 não ficar sem nenhum consumidor. Existem outros triggers, outros gatilhos para o rebalance. Um deles é se o seu consumidor ficar muito tempo ansioso. O consumidor tem um método, você chama lá para consumir. Então você faz um pull, faz um pull no Kafka dizendo, ó, me dá a mensagem aqui do offset tal. Se você ficar muito tempo sem fazer esse consumo, o Kafka entende que você está morto, vamos dizer assim, você está com algum problema. E aí ele te remove automaticamente daquele consumer group. Então, é como se você estivesse down. Mesmo que você não tivesse down, para o Kafka você vai estar down porque você demorou muito para consumir a mensagem. E aí nesse caso, isso vai trigar um rebalance. Outra forma é adicionar partição nova no tópico. Isso é muito importante. Então assim, quando você vai começar a subir uma infra de Kafka, planejar o seu topo, quantas partições, o meu conselho é sempre colocar a quantidade máxima de partições que você vai precisar, no pico, né? Então, ah, no dia normal eu uso três partições, mas na Black Friday eu preciso de dez. Então, você já coloca dez partições, não três. Porque quando você adiciona mais partição, você também vai sofrer rebalance. Por que você vai sofrer rebalance? Porque o Kafka precisa fazer o cálculo de hash. Então cada chave, cada key, ela está linkada em uma partição, porque o Kafka fez um cálculo de hash para isso. Quando você adiciona mais uma partição, Kafka precisa recalcular o hash e aí você vai ter um rebalance nesse caso. Por que a gente tem que evitar o rebalance? Por que esse problema de redistribuição é um problema? Prime é por conta da latência. Quando acontece o rebalance, como você viu, voltando lá no desenho rapidamente, por um período, espaço de tempo, os consumidores ficaram sem nenhum top. Então tudo que está chegando, tudo que está chegando na partição não está sendo unido. Então a gente tem aqui uma parada, um stop the word durante alguns segundos dependendo da quantidade de mensagens, podem ser até minutos. E obviamente dependendo da quantidade de mensagens de consumidores dentro do seu consumer group. Opa, passou demais aqui. Esse é o motivo. Outro motivo é a vazão. Então, já que você está fazendo Stop the Work, você está parando tudo, a sua vazão vai diminuir. Então, o seu TPS, que antes era mil, vai com certeza cair bastante nesse período de rebalance. Aumenta o uso de recursos. Então, você vai também perceber um aumento no uso de CPU, de memória, de network, porque você está rodando um processo de redistribuição de partição. Potencial duplicação e ou perda de dados. Então, assim, duplicação você vai, eventualmente, é pouco, mas você pode ver que uma mensagem foi recebida duas vezes, tá? Perda de dados, porque se você estiver usando uma estratégia de commit, por exemplo, como auto-commit, e aí acontecer um rebalance, o que vai acontecer é que, naquele momento, a mensagem pode ser comitada e nem processada, enfim. Então, assim, você pode estar perdendo informação aí, pode estar perdendo dado. Então assim, a estratégia de commit tem que ser muito bem registrada para que no rebalance você não perca mensagens. E aí eu já falei em outras aulas sobre estratégia de commit, manual, autocomit, etc. Como é que a gente evita o rebalance? Primeiro, você precisa evitar o outscaling, que é uma coisa muito comum. Você está rodando larga escala e você precisa escalar, então você precisa escalar fazer o scale in e o scale out escalar horizontalmente e quando você faz isso você está causando rebalance, por quê? quando você faz scale in e scale out você está adicionando ou removendo consumas do seu consumer group então você está causando rebalance. Então se isso for realmente necessário, se você não tem como fugir do scaling, é legal que você consiga fazer isso em momentos de pouco uso da sua aplicação. Como assim? Eu sei que amanhã vai começar Black Friday. Então nesse caso, o legal seria eu conseguir escalar antes do dia da Black Friday e de madrugada, quando tem pouca demanda. Para que mesmo acontecendo rebalance eu não tenha tanto impacto assim. Evite adicionar partições. Como eu já falei, quando você adiciona a partição você causa rebalance. Então evitar de adição na partição durante o dia, etc, é muito importante. Evite processamentos muito demorados. Então, assim, se você recebe uma mensagem e essa mensagem leva, sei lá, 10 minutos para processar, 7 minutos, 5 minutos, até você pegar a próxima, isso é um problema. Porque, por padrão, o tempo que o Kafka entende que você pode ficar ocioso são cinco minutos. Claro, você pode aumentar esse tempo, etc., mas o padrão é cinco minutos. Se você demora mais de cinco minutos para ler, processar e ler a próxima, o Kafka vai te derrubar automaticamente desse consumer group e vai iniciar um rebalance. Use estratégias de rebalance e posicionamento correto. A gente vai já falar nos próximos slides, existem estratégias de posicionamento para que mesmo você, colocando novos consumidores ou removendo, você sofra minimamente com o rebalance. Então, o rebalance é inevitável. Ele vai ocorrer. Você adicionando ou removendo vai acontecer o rebalance. Só que a gente consegue reduzir esse impacto. E como é que a gente faz isso? O particionamento ocorre quando uma partição precisa assinar um consumidor. Então assim, você tem lá dentro do consumer group dois consumidores e uma partição com dois partiçõesico com duas partições. Então, quando você tem dois consumidores num consumer group e duas partições num tópico, você tem um para um. Então, um consumidor vai se inscrever numa partição e outro consumidor vai se inscrever em outra partição. Ele vai ser assinado a essa partição. Quando esse consumidor entra ou sai, como eu falei, acontece a redistribuição Stop the Words. E aí existem algumas estratégias para você evitar isso. São elas, Browsing Robin, Stick e o Range. Vamos entender como funciona cada uma. A padrão é a range. Então quando você não coloca nada, essa aqui é a padrão. Primeiro, o que acontece? Vamos pensar que a gente tem dois tópicos aqui. O tópico A tem duas partições, AP0 e AP1. E o tópico B tem duas partições também, AP0 e AP1. E a gente tem três consumidores, tá? C1, C2 e C3. Como é que a free range funciona? Primeiro, acontece uma ordem lexográfica dos consumidores. Como assim? Ordem alfabética. Então, o C1 vai ficar no seu primeiro, C2 vai ser o segundo e o C3 vai ser o terceiro. Então eles vão ficar em ordem e depois as partições são ordenadas de forma numérica. Como assim? A P0 vai ser a primeira então assim A0 vai ser a primeira B0 vai ser a segunda A1 vai ser a segunda terceira, desculpa e A B1 vai ser a segunda, A1 vai ser a terceira e AB1 vai ser a quarta. Então é nessa ordem que eu escrevi aqui. A0, B0, A1 e B1. Então internamente o CAP vai fazer essa ordenação de partições. de partições. Ok. Terceiro passo, para cada partição dessa, ele vai assinar para um consumidor, para o grupo de partições. Então, o consumidor 1, ele vai ficar com A0 e B0. Tá? O consumidor 2, ele vai ficar com A1 e B1. E o consumidor 3 vai ficar sem ninguém. O que você está percebendo nesse range? Esse range ele distribui as partições de uma forma que possivelmente um dos seus consumidores vai ficar sem nenhuma partição, ou seja, ocioso, o que é ruim. Mas existem casos de uso em que usar o range é legal. Por exemplo, colocation. Imagina uma situação onde a partição 0 e o consumidor 1 estão na mesma região e AZ, data center, fisicamente. Nesse caso, eles se comunicarem através da mesma partição é legal, porque o consumidor 1 e a P0, que é nesse caso o A0, eles vão estar fisicamente pertos, porque eles vão estar no mesmo data center. Enquanto que se eu colocasse o C3 para consumir da P0, que é nesse caso o A0, eles podem estar em regiões diferentes, etc. Enfim, se você tem um caso de collocation, onde você precisa que o C1 esteja próximo das partições 0, e o C2 esteja próximo da partição 1, e o C3 esteja próximo da partição 2, enfim, nesse caso usar o range é legal. Se esse não é o seu caso, a gente tem a Rounding Robin. A Rounding Robin tenta distribuir muito melhor as partições. Então se você já olhar direto aqui no Before, você vai perceber que todos os consumidores têm pelo menos uma partição. Então ninguém está parado, todo mundo está trabalhando. E como é que funciona? Essa aqui é bem simples. Então para cada partição ela vai fazer do round robin. Cada partição vai escrever num consumer group, a outra vai para o outro, a outra vai para o outro. Vou mostrar para vocês como funciona. Então a A0, essa partição A0, ela vai para o primeiro consumidor. A1, ela vai para o segundo consumidor. Então A0 vai para o primeiro, A1 vai para o segundo, a B0 vai para o terceiro, e a B1 volta para o primeiro. Então é meio que uma roleta, sabe? Assinando cada partição para o consumidor e vai para o próximo, para o próximo até voltar para o primeiro. Então se você olhar aqui nesse before, você vai ver que bate exatamente com o que eu falei. O primeiro consumidor fica com duas partições, que é a A0 e a última, porque voltou, esse aqui fez o ciclo completo e voltou para o primeiro, o C2 vai ficar com a A1, porque é a segunda aqui, e o C3 vai ficar com a B0, que é a primeira partição do segundo tópico. E aí o que acontece? O C2 morre. Nesse caso ele morreu, aconteceu algum problema com ele. As partições são redistribuídas. E aí a gente aplica o rounding robin de novo. Então aqui vai ficar A0 vai ficar com C1. A1 vai ficar com C3. Aí terminou com o consumidor e volta para o primeiro. B0 vai para o Cu e B1 vai para o C3. Então toda vez que termina os consumidores ele volta para o primeiro. Então a gente vai fazendo esse ciclo até terminar todas as partições e redistribuir de novo. Então o after ficou assim. de novo. Então o after ficou assim. Esse routing robin, como eu falei, é muito bom para que você tenha uma distribuição boa de partição. Então todo mundo vai estar trabalhando. Mas se você perceber aqui, quando um consumidor morre, ele simplesmente para tudo e redistribui todo mundo. Então ele está fazendo o stop the word e a gente vai ter aquele aumento de latência, etc. Então essa não é uma estratégia muito boa se você quer evitar ao máximo o rebalance. Você redistribui muito bem, mas você ainda tem muito rebalance. E a gente tem uma outra estratégia chamada stick.. Essa STICK aplica a mesma regra do RODINRODIN. Então, eu nem vou passar de novo aqui, mas ela aplica o RODINRODIN. Então, A0 com o consumidor 1 e assim vai. Qual que é a diferença? A grande diferença aqui é que quando o consumidor 2N morre, ele não para tudo. Ele vai simplesmente reassinar as partições que mudaram. Então, por exemplo, se você olhar aqui, esse aqui é o before. Antes de morrer, a partição A1 estava com C2. Então, apenas essa partição estava com C2. E, apenas essa partição estava com C2. E aí, o C2 morreu. Quando o C2 morreu, aplicando o algoritmo de Roggen-Robin, eu sei que a A1 vai para quem? Ela vai para o C3. Então, o único cara que eu preciso parar, vamos dizer assim, é o C3. Então, eu não preciso parar o C1, porque o C1, as partições continuam iguais. Não vou mudar nada no C1. O C1 continua funcionando. O único que vai sofrer algum tipo de redistribuição é o C3. Então, nesse caso, eu ainda tenho rebalance, mas eu diminuo muito menos, porque só o C3 eu vou mexer. Aqui, eu só tenho 3 consum consumidores mas imagina um caso que eu tenho 50 consumidores se um deles morrer eu consigo minimizar bastante a quantidade de rebalanço que vai acontecer dentro do meu consumer group com isso a gente definiu estratégias de particionamento e aí quando novamente, só voltando um pouco aqui, quando eu for falar do código, quando eu for mostrar o rendizão para vocês, eu vou colocar uma dessas estratégias lá para a gente ver como aplica etc. Eu ainda posso melhorar ainda mais, diminuir na verdade o meu rebalance usando um cara chamado Static Groupers Membership. O que é isso? Se a gente pudesse, toda vez, pensando no Consumer Group, no Consumer Group eu posso ter, por exemplo, 3 consumidores. E aí o consumidor 1, vamos olhar aqui nesse GIF, o consumidor 1 está escrito em três partições, T1, T2 e T3. O consumidor 2 está na T4, T5 e T6. E esse consumidor aqui, o 3, está na T7 e na T8. Então Então cada consumidor já tem assinado o número de partições. Se um dos consumidores morrerem aqui olhando no gif, vamos esperar ele morrer vamos lá, esse consumidor morreu por algum motivo, quem entrar de novo seria legal se ele pegasse a mesma partição, você não concorda? Então o próximo que entrar, a próxima instância, aplicação que entrar, ele não precisa mexer no T4, T5, T6, nem no T7, no T8. Ele só vai se reescrever na T1, T2 e T3. Ele só vai se reescrever na T1, T2 e T3. Certo? E como é que a gente faz isso? Existe uma propriedade chamada Group Instance ID. Onde você assina especificamente que aquele consumer já tem essas partições aqui. Então quando o outro substituir esse consumer. Ele vai se inscrever nas mesmas partições sempre. E aí você evita praticamente 100% do rebalance, porque claro, você não vai evitar o rebalance daquelas partições, mas todas as outras do seu cluster não vão sofrer rebalance, porque apenas aquele consumidor sempre vai se inscrever no mesmo grupo de partições. Mas ainda assim fica claro que você não vai evitar o rebalance. Ele ainda pode ocorrer. Pensa na situação em que esse consumidor aqui fica muito tempo fora. Então se ele cai e ele fica muito tempo fora, o carro precisa rebalancear, senão aquelas partições vão ficar sem nenhum consumo por muito tempo fora, o Kafka precisa rebalancear, senão aquelas partições vão ficar sem nenhum consumer por muito tempo. Então existe o Session Timeout que dicta qual é o tempo máximo que aquele consumidor pode ficar fora para que o Kafka consiga triggar um rebalance de novo, mesmo que você esteja usando status do Group Membership. mesmo que você esteja usando status do grupo membership. É isso pessoal, espero que tenham gostado e até a próxima.