Conceitos
Log replicado / replicação de máquina de estados
Intuição
Pense em um livro-caixa compartilhado de que vários contadores mantêm, cada um, a sua própria cópia. Para garantir que a cópia de todos continue idêntica, apenas um contador por vez tem permissão de escrever novos lançamentos, e ele dita cada nova linha aos outros exatamente na mesma ordem. Enquanto todos copiarem as mesmas linhas na mesma ordem, qualquer um pode somar o livro-caixa de forma independente e chegar à mesma resposta — ninguém precisa comparar anotações linha por linha para confiar no resultado.
Como funciona
No Raft, o líder é o único servidor que acrescenta novos comandos ao seu próprio log; em seguida, ele envia RPCs AppendEntries em paralelo para replicar cada entrada nos seus seguidores, em ordem. Uma entrada se torna "confirmada" (committed) quando o líder verifica que ela foi replicada em uma maioria dos servidores do cluster — a partir desse ponto é seguro aplicá-la à máquina de estados, e todas as entradas anteriores do log também estão confirmadas. A consistência entre as réplicas se apoia na Log Matching Property: se dois logs contêm uma entrada com o mesmo índice e o mesmo termo, os logs são idênticos em todas as entradas até esse índice. O Raft impõe isso porque toda chamada AppendEntries inclui o índice e o termo da entrada imediatamente anterior, e um seguidor rejeita a RPC se isso não casar com o seu próprio log; quando uma divergência é encontrada, o líder força o log do seguidor a convergir para o seu, sobrescrevendo as entradas conflitantes. Há uma sutileza na regra de commit que protege a correção através de trocas de líder: um líder não pode marcar como confirmada uma entrada de um termo anterior apenas contando réplicas dela — só pode fazê-lo depois que uma entrada do seu próprio termo atual tenha sido replicada em uma maioria. Junto com a restrição de eleição (candidatos com logs defasados não podem vencer, de modo que qualquer líder eleito já possui todas as entradas previamente confirmadas — a Leader Completeness Property), isso entrega a State Machine Safety: nenhum par de servidores jamais aplica comandos diferentes no mesmo índice do log.
Na prática
Esse é o mecanismo central de replicação por trás de sistemas como o etcd, o Consul e o CockroachDB, que usam um log replicado pelo Raft para manter consistentes, em todos os nós, dados de configuração, estado de service discovery ou metadados de transações. Você recorreria a um log replicado como esse sempre que vários servidores precisassem concordar, em ordem, sobre uma única sequência de operações que alteram estado e continuar funcionando corretamente mesmo que o líder atual caia no meio do caminho.
Use em um desenho
Pratique na escola de System Design os casos que dependem deste conceito.