Pular para o conteúdo principal

Conceitoavançado

Eleição de Líder

Visão Geral

Eleição de líder é o processo pelo qual um grupo de nós escolhe um para coordenar — aceitar escritas, distribuir trabalho, tomar decisões que precisam ser únicas.

Escolher é fácil. O difícil é garantir que não haja dois, e essa dificuldade é a razão pela qual eleição de líder exige consenso.

Problema

Ter um líder simplifica enormemente: com um único nó decidindo, não há conflito de escrita nem ordenação a resolver. É por isso que replicação com líder único é o arranjo mais comum.

O problema aparece quando o líder falha.

Os outros nós precisam detectar a falha e eleger um substituto. Mas detectar falha é heurística: "não responde" pode significar caído, lento, ou do outro lado de uma partição.

Se os nós elegem um novo líder e o antigo não caiu — só estava incomunicável — existem dois líderes, ambos aceitando escritas, ambos convencidos de serem o único.

Isso é cérebro dividido, e é o modo de falha que a eleição precisa impedir.

Conceitos Centrais

Maioria é o que impede dois líderes

O mecanismo fundamental: um nó só se torna líder com o voto da maioria.

Como não pode haver duas maiorias disjuntas num mesmo grupo, não pode haver dois líderes eleitos simultaneamente.

5 nós, partição em 3 e 2
→ o grupo de 3 tem maioria: elege líder
→ o grupo de 2 não tem: fica sem líder, indisponível para escrita

O lado minoritário precisa parar de aceitar escritas. Se ele continua, o mecanismo não vale nada.

Isso é o que torna a eleição uma escolha CP: sob partição, o lado minoritário fica indisponível. Ver CAP.

O líder antigo precisa saber que perdeu

Aqui está a parte sutil. O nó isolado pode não perceber que perdeu a liderança — ele não recebe notícia, porque está partido.

Duas defesas:

Concessão com prazo. A liderança vale por um tempo limitado e precisa ser renovada com a maioria. Sem renovar, o líder se demite sozinho. Isso limita a janela de dois líderes ao tempo da concessão.

Fencing. Cada liderança recebe um número crescente. Os recursos protegidos — banco, armazenamento — rejeitam operações com número menor que o último visto.

líder 1 (época 5) é isolado
líder 2 (época 6) é eleito e escreve
líder 1 volta e tenta escrever com época 5
→ recurso rejeita: já viu época 6

Fencing é a defesa que funciona mesmo quando a detecção falha, porque ela não depende de o líder antigo perceber nada. É o mecanismo mais confiável, e o mais frequentemente omitido.

Detecção e estabilidade

O tempo de detecção define um compromisso:

Curto. Failover rápido, e risco de eleição desnecessária por lentidão momentânea — o que causa instabilidade, com liderança trocando repetidamente.

Longo. Estável, e mais tempo de indisponibilidade quando o líder de fato cai.

Sistemas maduros costumam usar detecção da ordem de segundos, com concessão de prazo semelhante.

Nem tudo precisa de líder

Antes de eleger, vale perguntar se a coordenação é necessária.

Operações comutativas — que podem acontecer em qualquer ordem sem alterar o resultado — não precisam de líder. Ver resolução de conflitos e estruturas que convergem sem coordenação.

Líder é a solução mais simples de raciocinar e a mais cara em disponibilidade.

Não implemente do zero

Eleição correta é notoriamente difícil de implementar. As implementações disponíveis — baseadas em Raft, Paxos ou serviços de coordenação — foram testadas contra cenários de partição que uma implementação própria não terá.

Ver consenso.

Modelo Mental

Eleição não é escolher um líder; é garantir que não existam dois. Todo o mecanismo serve a essa segunda parte.

Quando Usar

  • Uma operação precisa acontecer em exatamente um lugar — agendamento, migração, compactação.
  • Replicação com líder único precisa de failover automático.
  • Há um recurso que não admite acesso concorrente entre nós.

Quando Não Usar

Quando a operação é comutativa. Não precisa de coordenação.

Quando pode ser idempotente e executada por todos. Ver idempotência: se executar N vezes é inofensivo, a eleição é desnecessária.

Sem fencing, para proteger recurso externo. A eleição garante um líder no grupo; ela não impede que um ex-líder escreva num recurso que não participa do consenso.

Implementando do zero.

Quando a indisponibilidade do lado minoritário for inaceitável. Aí a resposta é uma arquitetura sem líder, com as complicações correspondentes.

Alternativas

  • Sem líder, com quórum — replicação sem coordenação central.
  • Operações comutativas — evita a necessidade.
  • Bloqueio distribuído com prazo — para coordenação pontual, não contínua. Ver locks distribuídos.
  • Particionamento — em vez de um líder para tudo, um por partição, o que distribui a carga e o risco.

Trade-offs

Com líderSem líder
Sem conflito de escritaConflitos a resolver
Ordenação naturalOrdenação a estabelecer
Raciocínio simplesComplexo
Gargalo de escritaDistribuído
Indisponível durante eleiçãoSempre disponível
Ponto de falha, mitigado por failoverSem ponto único

Modos de Falha

Cérebro dividido. Dois líderes escrevendo.

Instabilidade de liderança. Trocas repetidas por detecção agressiva.

Ex-líder escrevendo em recurso externo. Sem fencing.

Eleição que não conclui. Sem maioria disponível, o grupo fica sem líder.

Falso positivo de detecção. Líder saudável e lento é substituído desnecessariamente.

Erros Comuns

Não usar fencing ao proteger recurso externo.

Implementar eleição própria.

Detecção agressiva demais.

Permitir que o lado minoritário aceite escritas. Anula toda a proteção.

Assumir que o líder antigo percebe que perdeu.

Exemplo Real

Um sistema de processamento em lote usava eleição de líder para garantir que apenas uma instância executasse a rotina noturna de fechamento.

A implementação era caseira: um registro numa tabela com marca de tempo. Quem conseguisse atualizar primeiro era o líder por 5 minutos.

Funcionou por dois anos. Depois, uma pausa longa de coleta de lixo numa instância produziu o cenário clássico.

A instância A obteve a liderança e começou o fechamento. No meio, sofreu uma pausa de 7 minutos. A concessão expirou. A instância B assumiu e começou o fechamento do zero.

A instância A voltou da pausa sem saber que havia perdido a liderança — do ponto de vista dela, nada aconteceu — e continuou escrevendo de onde parou.

Duas instâncias escreveram lançamentos contábeis do mesmo fechamento. A conciliação levou três dias.

A correção teve duas partes.

Fencing. Cada liderança passou a receber um número crescente, gravado junto com cada lançamento. A tabela de lançamentos rejeita escrita com número menor que o último aceito. A instância A, ao voltar, foi rejeitada na primeira escrita.

Serviço de coordenação testado em vez da implementação caseira, com concessão renovada por batimento e verificação explícita de liderança antes de cada bloco de escrita.

O que torna esse caso instrutivo é que o problema não foi a eleição — ela funcionou, e B foi corretamente eleito. O problema foi A não saber que perdeu, e nenhum mecanismo impedir que ele escrevesse.

Fencing é a única defesa que funciona nesse cenário, porque ela não depende do ex-líder perceber nada.

Conceitos Relacionados

Exercício Prático

Se seu sistema tem alguma operação que "só uma instância pode executar", descubra como isso é garantido.

Depois faça a pergunta do caso acima: se a instância eleita sofrer uma pausa longa e voltar, o que impede que ela continue escrevendo?

Perguntas de Entrevista

  • Por que eleição de líder exige maioria?
  • O que é fencing e por que ele é necessário mesmo com concessão de prazo?
  • Por que o lado minoritário de uma partição precisa parar de aceitar escritas?

Para Aprofundar

  • Kleppmann, Martin. How to do distributed locking, 2016 — o argumento sobre fencing.
  • Ongaro, Diego; Ousterhout, John. In Search of an Understandable Consensus Algorithm (Raft), 2014.
  • Burrows, Mike. The Chubby Lock Service. OSDI, 2006.
Terminou de ler este documento?Seu progresso fica salvo apenas neste navegador.