O que um cluster Raft garante: maiorias, um único líder e leituras linearizáveis

O que é

A página do projeto Raft (fonte citada) descreve consenso como o acordo de vários servidores sobre valores; depois de uma decisão tomada, ela é definitiva. Os algoritmos de consenso típicos avançam enquanto qualquer maioria dos servidores estiver disponível (um cluster de cinco continua funcionando com dois servidores falhos); com mais falhas, deixam de avançar, mas nunca retornam um resultado incorreto. O Raft aplica esse princípio a uma máquina de estados replicada: cada servidor mantém um log de comandos, e o algoritmo garante que, se algum servidor aplica um comando como n-ésima entrada, nenhum outro servidor jamais aplica uma n-ésima entrada diferente. O Raft é baseado em líder; a página do projeto o descreve como decomposto em subproblemas relativamente independentes, que o artigo do Raft chama de eleição de líder, replicação de log e segurança (safety).

A documentação do etcd (fonte citada) afirma o que o cliente recebe: linearizabilidade, isto é, a ilusão de que cada operação tem efeito em um único instante entre a sua invocação e a sua resposta, de modo que uma leitura retorna o valor mais atual. Requisições linearizáveis passam pelo processo de consenso do Raft; uma requisição pode, em vez disso, ser marcada como serializável para ser atendida localmente com menor latência, com o risco de retornar dados desatualizados.

Por que importa

Poucas equipes implementam consenso, mas muitas dependem dele de forma indireta: o estado do Kubernetes no etcd, descoberta de serviços, locks distribuídos, configuração. Conhecer as garantias ajuda a saber o que esperar durante um incidente: um cluster que perdeu a maioria recusa escritas e leituras linearizáveis em vez de divergir, e um cluster de dois membros não tolera nenhuma falha.

Como aplicar

• Use um número ímpar de membros, três ou cinco; um número par não acrescenta tolerância a falhas, porque o limite da maioria sobe junto.
• Distribua os membros em domínios de falha separados, para que a perda de um domínio ainda deixe uma maioria.
• Escolha o modo de leitura a cada chamada: linearizável quando uma resposta desatualizada leva a decisões erradas (leases, locks, contadores), serializável para leituras de alto volume que toleram dados desatualizados.
• Mantenha as entradas pequenas e o conjunto de dados modesto; toda escrita é replicada para uma maioria e tornada durável antes de ser confirmada, de modo que a latência de sincronização do disco limita a vazão.
• Use escritas condicionais (compare a revisão atual e depois atualize) em vez de ler e depois escrever a partir do cliente; o consenso ordena o log, mas não torna duas chamadas do cliente atômicas.

Armadilhas

Uma escrita que expirou por timeout ainda pode ter sido confirmada (committed); só repita a operação se ela for idempotente. Um servidor que era líder pode ainda não saber que foi substituído, e por isso leituras baseadas em líder exigem uma verificação explícita e quem detém um lease ainda precisa de fencing. Perder o quórum é uma indisponibilidade de escrita, não uma perda de dados.

Dois sites não bastam

Para sobreviver à falha de um domínio mantendo a maioria, são necessários pelo menos três domínios de falha. Com dois sites, três membros divididos em dois e um perdem o quórum quando o site maior falha, e quatro divididos igualmente o perdem quando qualquer um dos sites falha; nenhuma distribuição resolve. Com apenas dois sites, é preciso escolher deliberadamente: colocar a maioria onde a carga de trabalho é executada e aceitar que perder esse site interrompe as escritas; adicionar um pequeno terceiro membro em um local separado como desempate, aceitando que a latência de ida e volta até ele passa a limitar os commits; ou manter o cluster em um único site e usar o segundo como destino de backup, e não como participante do consenso.