Oi pessoal, eu me chamo Ronaldo Lanharas e hoje eu vou falar sobre estratégias de produção de mensagens no Kafka. Então, quando a gente vai fazer uma produção de mensagens no Kafka, a gente tem três tipos de estratégias. Isso funciona para qualquer tipo de produtor. Então, independente se você está usando Golang, Java, Python, Node, .NET, não importa. Nesse caso, você pode aplicar qualquer uma dessas três estratégias aqui para garantir ou não a entrega da sua mensagem. Então, a gente tem o Atmos Once, At least Once e Exactly Once. A gente vai passar em cada uma dessas aqui e entender como é que funciona. O at most once é também muito conhecido como fire and forget, que é simplesmente, eu não quero aguardar nenhum retorno, eu vou mandar minha mensagem e não me importa se ela foi gravada ou não. Esse caso, ele é muito utilizado, por exemplo, quando você tem log. Então, quando a gente está fazendo uma gravação de log, é muito comum que você não precise se preocupar se aquele log foi gravado ou não. Então, é uma operação que não exige 100% de durabilidade, vamos dizer assim. E para fazer isso, lá no seu produto você tem que colocar o ACK 0, que é como se fosse o ACK 9. Então, dependendo da linguagem, essa configuração muda um pouco. Mas o ACK, ele nada mais é do que a quantidade de vezes que você quer receber o acknowledge do broker. Então, ACK é o acrônimo para acknowledge. Então, eu estou dizendo assim, acknowledge zero significa que eu não quero receber nenhum tipo de retorno do broker. Então, eu mando a mensagem, eventualmente ela vai ser gravada ou não, e não me importa se o broker gravou ou não. Então, por isso que esse método é fire and Forget. Aí você pode perguntar, mas por que usaria um Fire and Forget? Como eu falei, primeiro porque você não se importa se aquela mensagem foi gravada ou não. Segundo, você quer extrema performance no seu producer. Então quando você tem essas duas características, você não se importa se a mensagem foi efetivamente gravada no broker ou não, e você quer ser extremamente performático, você vai com o Atmos 1. Porque esse tempo que você espera a resposta do broker, você vai adicionar alguns milissegundos de latência. Então, dependendo da situação, você não quer esses milissegundos de latência, você quer o mais performático possível, você vai de Atmos 1 ou Fire and Forget. Bom, mas o at least once não é muito uma realidade em 95% dos casos de uso. Quando a gente fala de cápita, 95% dos casos de uso, você geralmente vai ver o at least once, que é ao menos uma mensagem tem que ser gravada. Então, não importa o que aconteça, pelo menos uma mensagem tem que ser gravada no broker. Só que, para a gente entender como funciona o whitelist once, é importante você entender o que é o min-sync-replica. Quando você cria um tópico no broker, existe uma propriedade chamada min-sync-replica. Essa propriedade diz qual é o número mínimo de brokers que aquela sua mensagem tem que ser replicada antes de retornar o acknowledge, que é o ACK. Então, a combinação do min-sync-replica e o ACK do seu producer é o que vai dizer quanto de durabilidade você quer, quanto de consistência da sua mensagem você quer. Então assim, vamos só voltar aqui no Atmos 1. Mesmo que você coloque o MinSyncRéplica, imagina que você tem 3 brokers, 1, 2 e 3. E você configurou o MinSyncRé como 3, que é o máximo que você pode nesse caso. Você quer replicar para todo mundo. E no ACK você configura o 0, o produtor vai simplesmente ignorar. Então assim, não interessa o que você configure no MinSync, se você colocar o ACK... Deixa eu até colocar um laser pointer aqui. Se você colocar o ACK como zero significa que não importa o que o broker está fazendo, eu não quero esperar. Por outro lado, se você colocar o ACK ALL ou menos um, de novo depende de qual linguagem de programação você está usando, você está dizendo, eu quero anulhar o anulet de todos os brokers do MinSyncRéplica. Então, se o MinSyncRéplica estiver configurado para 2, como é esse caso aqui, o seu ACK All vai esperar o retorno do broker 1 e do broker 2. Significa que a sua mensagem foi gravada no mínimo, por isso que é o BinSync, no mínimo em dois brokers. E o 3 ele está eventualmente consistente aqui. Então assim, a sua mensagem pode ou não ter chego lá. Então pode ser, por exemplo, acontecer uma queda de rede, o broker 3 caiu, enfim. N problemas, essa mensagem não foi replicada para o broker 3. Mas ela está com certeza no Windows 2. Então, essa propriedade do MinSync é muito importante porque existe uma certa confusão de que quando você configura o ACK All, você está esperando todo mundo, o que não é verdade. Essa propriedade funciona em conjunto com o minSyncRéplica do topic. Então se você colocar o minSyncRéplica como 1, não interessa se você colocar all, vai ser sempre 1. Então o all significa todos do minSyncRéplica, só para deixar claro aqui. significa todos do MinSyncRéplica, tá? Só para deixar claro aqui. E a gente vai para a última situação, que é o ExactlyOnce, tá? O ExactlyOnce, ele é idêntico ao AtListOnce. Então, você tem lá o MinSync, tem o Producer, etc. Só tem um detalhe. Se a gente voltar no atListOnce, tem uma seguinte situação que pode ocorrer, um edge case. Quando você manda uma mensagem para o broker 1, e para o broker 2 nesse caso, você quer a garantia de que ela foi escrita. Então, no momento que você mandou, pode acontecer, acontecer de novo um milhão de coisas a rede não é confiável a gente sempre parte desse princípio e imagina que demorou demais, o broker não respondeu você recebeu um timeout mas a mensagem não foi gravada o broker só não conseguiu responder pra você o que vai acontecer? o seu producer vai tentar mandar de novo, porque internamente ele tem um retry. Então, como ele tem um retry, ele vai mandar N vezes até ele conseguir. Então, aquela mensagem vai ser duplicada. Como é que a gente evita isso? Existe uma propriedade chamada enableIdepotenceTrue que você coloca do lado do produtor. Então, nesse caso, se a mensagem for gravada e não retorna ao ARC, por exemplo, que é o ACK, quando ele for produzir de novo, o broker vai dar uma propriedade nova, que é o ID. Então, agora, internamente, no broker, ele tem um ID, como se fosse uma marcação na mensagem, e ele checa se aquela mensagem já foi gravada ou não. Então, se ela não foi gravada, ele vai e grava. Se ela já foi gravada, ele vai simplesmente ignorar que a mensagem não vai gravar, evitando uma duplicidade. Óbvio, né? Quando a genteidade. Óbvio, quando a gente fala de depotência, a gente tem que ter sempre em mente o seguinte, quanto mais travas a gente coloca, menor é a performance. Então fique em mente aqui, quando você adiciona um depotência true, você adiciona também uma certa latência aí na sua produção. Não que isso seja um problema para 97% dos casos, você não vai precisar de uma extrema performance assim, mas a gente sabe que tem cases no mercado em que você precisa ganhar até no milissegundo. Então, é só importante salientar aqui que você tem uma penalidade bem pequena de performance. É isso pessoal, espero que vocês tenham gostado e até a próxima.