Algoritmo de Consenso Raft. Agora eu quero detalhar com você um pouco mais de maneira visual sobre o algoritmo Raft. Vamos lá! Vou deixar esse link também para sua consulta posterior e aqui no vídeo desta aula nós vamos navegar juntos neste endereço aula nós vamos navegar juntos neste endereço, que vai nos trazer uma visualização bem interessante do que o algoritmo está realizando. Então, primeiramente, vamos começar aqui Ok, temos um sistema com um nó único Vamos pensar nesse nó como nosso banco de dados Então, nosso valor X vai ser guardado nesse banco de dados, que é composto por um único nó. A gente pode até entender isso aqui como uma instância única de um banco de dados relacional que a gente está muito acostumado a trabalhar. Então, geralmente, quando estamos trabalhando com Oracle, com SQL Server, com MySQL, com Post Oracle, com o SQL Server, com o MySQL, com o Postgres, estamos trabalhando em uma instância de banco de dados e essa instância é um nó único, um stand-alone. Nós também vamos ter um ou mais clientes conectando neste servidor, neste banco de dados e os nossos clientes vão mandar mensagens, vão mandar operações para o servidor. Então aqui, ter um consenso de valor entre um cliente e um servidor é fácil, é simples, resolve dentro da própria instância desse banco de dados. Então o consenso já está resolvido, porque é ele com ele mesmo. Agora, vamos ver o que acontece com múltiplos nós. Então, aqui nós temos três nós, e já estamos falando de bancos de dados distribuídos. E vamos pegar aqui como exemplo também, MongoDB Atlas, que vai nos prover clusters que tem três nós, um nó com papel primário e os outros dois nós com papel de secundário. Vamos ver aqui no algoritmo Raft como que é resolvido esse consenso. esse consenso. Então, como já falamos nas últimas aulas, esse é o problema de consenso distribuído. Nós temos o nosso cliente, que é o ponto verde aqui no nosso diagrama, e esse cliente vai mandar comandos, e esses comandos passarão por um líder. Nós vimos que os algoritmos de consenso passam sempre por um líder que é a maneira de implementar e garantir a consistência. Então vamos ver o que vai acontecer aqui no Raft. O nó pode ter um de três estados. Pode ser o estado seguidor ou follower, pode ser o estado candidato, candidato a líder, e o estado de líder, que está liderando aquele conjunto de réplicas. No começo, todos os nós se iniciam no estado de seguidor E se não ouvirem nenhuma mensagem de um líder, eles se tornam candidatos Lembra que eu comentei na aula anterior que existe um mecanismo de time-out? Então, este time-out faz com que os seguidores se tornem candidatos aqui vai existir até uma certa aleatoriedade do momento em que ele se torna candidato afinal todos começarem no mesmo tempo teríamos três candidatos aqui mas o algoritmo vai garantir que não é todo mundo junto ao mesmo tempo se candidatando. Então, este nós se candidatou a líder, vai solicitar votos dos outros seguidores, dos outros nós. Esses nós respondem votando e a partir desse ponto o candidato se torna líder desses nós, porque ele obteve a maioria dos nós. Então, aqui é importante relembrar até do conceito do quórum. Tivemos a maioria dos votos e o candidato se torna líder. E uma coisa interessante também de destacar é que o candidato vota em si mesmo. Então, como uma boa eleição, quem se candidata vota em si mesmo. Então, como uma boa eleição, quem se candidata vota em si mesmo e solicita votos dos outros. Então, este processo, eleição de líder. A partir de agora, todas as mensagens, todas as mudanças, inserções e atualizações acontecem a partir do líder. Então, o nosso cliente mandou uma mensagem de atualizar o valor para 5. Este 5, a partir de agora, faz parte do log de operação do nosso nó líder. parte do log de operação do nosso nó líder. Até esse momento, não existe o commit daquele log. Então, a transação está em aberto. Para comitar essa entrada, o nó primeiro replica isso para os demais seguidores. Então, aqui nós não tivemos nenhuma alteração de nenhum valor em nenhum dos nós. O que está acontecendo aqui é o log está sendo replicado do seu líder para os demais seguidores. Então, quando a maioria dos nós responderem que estão com esse registro pronto para ser escrito, a partir daqui nós temos o comit. E o líder agora está com o valor 5 comitado. E a partir disso, o líder notifica os seguidores e os seguidores também assumem o número 5 como comit commit conforme foi comandado pelo nosso cliente. E agora nós temos um consenso sobre o estado do nosso sistema distribuído. Este processo é a replicação do log de operações. Agora, detalhadamente aqui no Raft, nós vamos ver que tem um timeout de configurações aqui de timeout que vão controlar as eleições de vídeo. Então vocês estão vendo que tem um reloginho aqui em cada nó. Então o primeiro é o timeout de eleição. Então é o tempo que um seguidor aguarda antes de se tornar um candidato. E aí como eu comentei, existe uma randomização, uma aleatoriedade Para que não aconteça que todo mundo se candidate ao mesmo tempo Então aqui a gente observa o detalhe Entre 150 e 300 milissegundos aqui no algoritmo RASP Então a gente vê que os relógios evoluem de maneira diferente Então após o timeout, o seguidor se torna o candidato E inicia um novo termo de eleição, um novo turno Mas a palavra que nós vamos encontrar na literatura sempre é termo Então neste termo acontece o voto para si mesmo E existe a requisição de votos dos outros nós. Se quem recebeu a solicitação do voto não votou ainda, então, não votou naquele termo, o seguidor vai votar no candidato. E todos vão resetar o time-out de eleição. Assim que o candidato obtém a maioria dos votos, ele se torna um líder. E agora, o líder continua mandando mensagem para os seus seguidores, e aqui são entradas de append, é sempre adição, inserção no lock. Então, essas mensagens são enviadas em intervalos específicos, e aqui nós temos um segundo timeout que é o heartbeat timeout, o tempo que ele vai aguentar sem ter comunicação entre o líder e os seus seguidores. Então os seguidores respondem e a cada mensagem que é enviada, o relógio é resetado, é reiniciado. Então, este termo aqui de eleição continua até que um seguidor para de receber o Heartbeat e se torna um candidato. Então, enquanto isso aqui estiver acontecendo, o nó A sempre é o líder deste cluster. E aqui nós temos o termo 1 para todo mundo. Termo 1 ou turno, o momento em que isso está acontecendo. Agora vamos ver o que acontece se o líder tiver uma parada e uma nova eleição vai acontecer. Então, por alguma razão, o líder ficou indisponível. Então a gente viu que o nó C se candidatou, atualizou o termo, solicitou votos dos seus nós seguidores. Como ele votou em si mesmo e o nó B votou também nele, dois é a maioria de três, temos um novo líder. Que é o nó C e é o novo líder do termo 2. Então, ter a maioria dos votos significa que apenas um líder pode ser eleito por turno. Se dois nós se tornarem candidatos ao mesmo tempo, então o split vote, ou voto dividido, pode acontecer. Então, dois nós iniciaram a eleição para o mesmo termo. O nó D está no termo 4, o nó C está no termo 4. Eles votaram em si mesmos e iniciaram uma eleição. Cada um deles atingiu um seguidor antes do outro. Então, cada candidato tem dois votos e não tem mais como receber voto nesse termo. Então, os nós vamos aguardar novamente, por uma nova eleição, e tentar novamente. Aí, como é aleatório, agora o nó B assumiu o termo 5 e conseguiu ter a maioria dos votos. E, com isso, tivemos uma nova eleição e o problema foi resolvido. Vamos detalhar agora a replicação do lock. Então, temos o líder eleito, precisamos replicar todas as mudanças no nosso sistema para todos os nossos. nós. Então, o mesmo append entries que foi usado lá nos hard bits também serve aqui. Então, o cliente envia a mudança ao líder, então o comando está no seu log. Este log é enviado aos seguidores na próxima mensagem de Heartbeats. E lembrando que aqui nós temos o log, ainda não aconteceu o commit. Então, os seguidores receberam o comando, retornaram para o líder, o líder deu o OK, ou seja, deu o commit do valor recebido e retorna para o cliente. E também retorna isso para os seus seguidores ficarem no mesmo status. Então o cliente mandou mais um comando de adição 5 e este comando segue o mesmo princípio retorna para os nossos seguidores, os nossos seguidores retornam para o líder, o líder retorna para o cliente, que temos o valor 7. E o raft pode ficar, e precisa ficar consistente no particionamento de rede, esse é um dos objetivos, sobreviver ou ter tolerância a falha. Então, vamos colocar aqui uma partição de rede e ver o que acontece Então nós temos o nó A e B separado do C, D e E A gente percebe que entre os nós C, D e E O termo foi incrementado de 1 para 2 e o nó e assumiu o papel de líder, enquanto que no nó a e b permaneceram no termo 1 e o nó b permaneceu com o papel de líder. e o nó B permaneceu com o papel de líder. Agora vamos ter um segundo cliente interagindo aqui com o nosso sistema distribuído de banco de dados e vamos fazer uma tentativa de atualização. Vamos ver o que acontece. Então, um dos clientes manda o valor do nó B para 3. B para 3. O nó B não pode replicar, porque não existe maioria, ele só consegue enxergar o nó A, então nós estamos aqui em um cenário com 5 nós, a maioria de escrita não é alcançada, então o log fica sem commit. O outro cliente vai mandar o comando para botar o valor 8 para o nó E. E ali nós vamos alcançar a maioria. E agora vamos ver o que acontece restaurando a conectividade entre os cinco nós. Vamos só observar aqui. Nós C, D e E estão no termo 2. O nó A e B está no termo 1. O nó B vai perceber que existe um termo de eleição maior e vai deixar de ser líder. Então perceba que o nó A e B avançaram para o termo 2 e o líder é o nó E. E o nó A e B também vão dar rollback no comando que não estava comitado e vão buscar sincronizar com o log do líder e agora o log está consistente no nosso cluster espero que assim tenha ficado mais divertido e mais visual de compreender o que um algoritmo de consenso faz E aqui especificamente utilizando a didática do algoritmo Raft para isso