Conceitos
Eleição de líder e consenso
Intuição
Imagine um trabalho em grupo em que todos podem propor alterações a um documento compartilhado ao mesmo tempo — o caos, já que duas pessoas podem editar a mesma linha de formas diferentes ao mesmo tempo. A solução é combinar uma pessoa como editora: todos enviam suas alterações propostas a ela, que as aplica em ordem, e, se essa pessoa some, o grupo concorda rápida e claramente sobre quem a substitui antes de o trabalho continuar. Os sistemas distribuídos enfrentam o mesmo problema com dados no lugar de um documento, e precisam do mesmo tipo de acordo sobre exatamente um líder por vez.
Como funciona
O Raft elege um único líder por cluster, que é o único responsável por aceitar comandos dos clientes e replicá-los para os seguidores. O tempo é dividido em termos (terms) — inteiros crescentes que funcionam como um relógio lógico — em que cada termo tem no máximo um líder, e comparar os números de termo permite aos servidores detectar informação obsoleta, como um líder antigo que ainda não sabe que foi substituído. A eleição é disparada por um timeout aleatório: se um seguidor não ouve nada de um líder dentro dessa janela, ele se torna candidato, incrementa seu termo e pede votos a todos os outros servidores por meio da RPC RequestVote; o primeiro candidato que reunir votos da maioria do cluster se torna líder daquele termo e começa a enviar heartbeats (RPCs AppendEntries vazias) para suprimir novas eleições. A aleatorização do timeout (o Raft sugere 150-300ms) existe justamente para tornar raros e autocorretivos os votos divididos (split votes) — em que vários candidatos iniciam eleições ao mesmo tempo no mesmo termo e ninguém obtém maioria: se um voto dividido de fato ocorre, o timeout de cada candidato vai expirar de novo em um momento aleatório diferente, e a eleição de um novo termo roda até que um candidato garanta a maioria. Só um líder pode ser eleito por termo porque um servidor dá no máximo um voto por termo, o que faz de "o primeiro a chegar à maioria" uma regra segura e sem ambiguidade.
Na prática
Esse é o mecanismo que permite ao etcd, ao Consul, ao CockroachDB e ao TiKV concordarem sobre um único escritor para o estado replicado deles, sem envolver uma pessoa ou um coordenador externo. Você escolheria um consenso baseado em líder como esse sempre que precisar que um cluster continue funcionando corretamente apesar de quedas de servidor e instabilidades de rede, garantindo ao mesmo tempo que todas as réplicas sobreviventes concordem sobre a mesma sequência de operações — o custo é uma breve janela de indisponibilidade durante uma eleição, em troca de consistência forte no restante do tempo.
Use em um desenho
Pratique na escola de System Design os casos que dependem deste conceito.