O consenso distribuído viabiliza a replicação determinística de máquinas de estado em redes assíncronas e sujeitas a falhas. Ele garante que nós independentes concordem sobre uma sequência imutável de transações sem divergir ou corromper dados.
O que é Replicação de Máquinas de Estado e por que o consenso é necessário?
A Replicação de Máquinas de Estado converte serviços centralizados em sistemas distribuídos tolerantes a falhas. Cada réplica executa um autômato determinístico idêntico alimentado por um log sequencial e ordenado de comandos.
Se todas as réplicas aplicarem as mesmas entradas na mesma ordem a partir do mesmo estado inicial, elas produzirão estados idênticos e saídas equivalentes. O desafio central reside em garantir que falhas de nós, perdas de pacotes e partições de rede não alterem essa ordem sequencial.1
+-------------------------------------------------------------------+
| CLIENT REQUEST |
+-------------------------------------------------------------------+
│
▼
┌─────────────────────────────────────┐
│ CONSENSO DISTRIBUÍDO │
│ (Eleição, Quórum e Termo) │
└──────────────────┬──────────────────┘
│
▼
┌─────────────────────────────────────┐
│ REPLICATED LOG │
│ [Entry 1] -> [Entry 2] -> [Entry 3]│
└──────────────────┬──────────────────┘
│
▼
┌─────────────────────────────────────┐
│ STATE MACHINE (ENGINE) │
│ (B-Tree, LSM-Tree, In-Memory) │
└─────────────────────────────────────┘
Em um modelo assíncrono, o célebre Teorema FLP (Fischer, Lynch e Paterson, 1985) provou que o consenso determinístico perfeito é impossível na presença de uma única falha não anunciada.2
Motores práticos contornam essa barreira adotando sincronia parcial: elegem líderes temporários e usam temporizadores probabilísticos para assegurar progresso (Liveness) sem jamais comprometer a segurança (Safety).
Como o Raft decompõe o problema do consenso frente ao Paxos clássico?
O Raft divide o consenso em três fases ortogonais: eleição de líder forte, replicação de log e invariantes de segurança. Ele elimina a complexidade estrutural e as lacunas no log típicas do Multi-Paxos tradicional.
No Paxos clássico de Leslie Lamport (2001), o protocolo foca no consenso para um único valor (Single-Decree). A extensão para fluxos contínuos de transações (Multi-Paxos) introduz complexidades operacionais severas, incluindo lacunas (holes) no log que exigem recuperação complexa.3
Em contrapartida, o Raft, introduzido por Diego Ongaro e John Ousterhout na USENIX ATC (2014), impõe um fluxo de dados unidirecional estrito: os dados trafegam exclusivamente do líder para os seguidores.4
| Dimensão Arquitetural | Paxos Clássico / Multi-Paxos | Protocolo Raft |
|---|---|---|
| Papel do Líder | Fraco / Opcional (qualquer nó pode propor) | Forte (apenas o líder aceita propostas) |
| Continuidade do Log | Admite lacunas e resolução desordenada | Estritamente contíguo e sequencial |
| Compreensibilidade | Abstrata e matematicamente densa | Modular, determinística e auditável |
| Recuperação de Réplica | Negociação de instâncias individuais | Sobrescrita direta a partir do log do líder |
| Adoção Moderna | Google Chubby, Google Spanner | etcd, TiKV, CockroachDB, Redpanda, Kafka |
Pesquisas da Universidade de Cambridge demonstraram que, embora Paxos e Raft alcancem garantias teóricas equivalentes de quórum, a rigidez do Raft simplifica a validação formal de sistemas em produção.5
Como funciona a eleição de líder, termos e detecção de split-brain?
A eleição no Raft utiliza termos lógicos monotônicos e temporizadores aleatórios para evitar empates. Ela garante que apenas um líder legítimo governe o cluster em qualquer instante de tempo.
O tempo é segmentado em termos arbitrários numerados sequencialmente (Term 1, Term 2, ...). Cada nó opera em um de três estados: Leader, Follower ou Candidate.
Quando um seguidor deixa de receber heartbeats dentro de sua janela de Election Timeout (geralmente entre 150 ms e 300 ms, sorteada aleatoriamente), ele incrementa seu termo local e transiciona para candidato.
type RequestVoteArgs struct {
Term uint64 // Termo lógico do candidato
CandidateID uint64 // Identificador único do candidato
LastLogIndex uint64 // Índice da última entrada no log do candidato
LastLogTerm uint64 // Termo da última entrada no log do candidato
}
type RequestVoteReply struct {
Term uint64 // Termo atual do votante para atualização
VoteGranted bool // Verdadeiro se o voto foi concedido
}
Para vencer a eleição e assumir a liderança, o candidato precisa reunir a maioria estrita dos votos do cluster:
Quorum = ⌊N / 2⌋ + 1
FaultTolerance = ⌊(N - 1) / 2⌋
Um cluster de 5 nós tolera a queda de até 2 nós mantendo um quórum de 3 votos.
O mecanismo de Pre-Vote (introduzido por Ongaro) impede que nós isolados por partição de rede incrementem termos desenfreadamente, evitando perturbações no cluster ao reconectarem.6
Quais são as garantias e invariantes de segurança do Raft?
O Raft apoia sua integridade matemática em cinco invariantes formais invioláveis. Essas regras asseguram que entradas de log confirmadas por quórum jamais sejam apagadas ou modificadas.
As cinco propriedades formais provadas por Ongaro governam todo o ciclo de vida dos dados:4
-
Election Safety: No máximo um líder pode ser eleito por termo lógico.
-
Leader Append-Only: O líder jamais trunca ou sobrescreve suas próprias entradas de log, apenas acrescenta novos registros.
-
Log Matching: Se dois logs contêm uma entrada com mesmo índice e termo, eles são idênticos em todas as entradas desde o início até aquele índice.
-
Leader Completeness: Se uma entrada de log foi confirmada em um determinado termo, ela estará presente nos logs dos líderes de todos os termos superiores.
-
State Machine Safety: Se um servidor aplicou uma entrada de determinado índice à sua máquina de estados, nenhum outro servidor aplicará uma entrada diferente naquele índice.
Um candidato só recebe votos se seu log for pelo menos tão atualizado quanto o do votante. O critério compara primeiro o termo da última entrada; em caso de empate, vence o maior índice acumulado.
O que são Linearizable Reads e como funcionam ReadIndex e LeaseRead?
Leituras linearizáveis garantem que uma consulta retorne o estado mais recente sem ler dados defasados. Elas protegem o cliente contra líderes isolados em partições de rede (stale reads).
Uma abordagem ingênua exige que o líder grave cada leitura como uma nova entrada no log de consenso. Esse método degrada o rendimento ao disparar operações síncronas de I/O em disco (fsync no WAL) para simples consultas.
Dois métodos modernos eliminam esse gargalo sem quebrar a consistência estrita:
1. ReadIndex (etcd)
O líder captura seu índice de commit atual (ReadIndex). Em seguida, envia um heartbeat leve para o quórum para confirmar que ainda detém a liderança legítima, sem gravar no disco.
Ao receber confirmações da maioria, ele aguarda sua máquina de estados alcançar esse índice e responde à leitura em memória com 0 escritas em disco e 1 round-trip de rede.7
2. LeaseRead (TiKV e CockroachDB)
O líder obtém uma concessão temporal vinculada (Leader Lease) renovada pelo quórum. Enquanto o relógio monotônico local estiver dentro do período do lease, nenhum outro líder pode ser eleito.
Isso ocorre porque o Election Timeout é estritamente maior que o lease, permitindo servir consultas com 0 escritas em disco e 0 round-trips de rede.8
+─────────────────────────────────────────────────────────────────────────+
| LINEARIZABLE READ PROTOCOLS (COMPARATIVO) |
+─────────────────────────────────────────────────────────────────────────+
| Mecanismo | Disco (WAL fsync) | Rede (Round-Trips) | Dependência |
+──────────────+───────────────────+────────────────────+─────────────────+
| Log Append | 1 escrita síncrona| 1 RTT (Quórum) | Nenhuma |
| ReadIndex | 0 escritas | 1 RTT (Heartbeat) | Rede estável |
| LeaseRead | 0 escritas | 0 RTT (Local CPU) | Clock monotônico|
+─────────────────────────────────────────────────────────────────────────+
Por que a arquitetura Multi-Raft é necessária em motores de alta escala?
O Multi-Raft particiona o espaço contínuo de chaves em milhares de grupos de consenso autônomos. Ele distribui a liderança e a carga de I/O por todos os núcleos de CPU e discos NVMe do cluster.
No Raft tradicional de grupo único (como no etcd), todo o throughput de escrita é afunilado em um único nó líder. O volume total do banco fica restrito à memória e capacidade de I/O de uma única máquina física.
Para superar essa barreira, motores como TiKV e CockroachDB dividem o conjunto de chaves em intervalos contíguos chamados Regions ou Ranges (geralmente entre 64 MB e 144 MB). Cada partição opera como um grupo Raft independente com 3 ou 5 réplicas espalhadas pelos nós.89
Cluster Multi-Raft (Topologia de Nós e Partições)
--------------------------------------------------
Nó Físico 1: [Region 1: Líder ] [Region 2: Follower] [Region 3: Follower]
Nó Físico 2: [Region 1: Follower] [Region 2: Líder ] [Region 3: Follower]
Nó Físico 3: [Region 1: Follower] [Region 2: Follower] [Region 3: Líder ]
Quando uma região ultrapassa o limite de tamanho configurado, o motor executa uma operação de Split atômica registrada via comando de consenso, dividindo o intervalo em dois novos grupos de forma transparente.
Como etcd, TiKV e CockroachDB implementam consenso na prática?
Cada motor industrial adapta o consenso à sua camada de armazenamento e requisitos de escala. O etcd foca em coordenação leve, enquanto TiKV e CockroachDB sustentam bancos distribuídos massivos.
As escolhas arquiteturais refletem os objetivos fundamentais de cada tecnologia:
| Característica | etcd (v3.5 / v3.6) | TiKV (v7.x / v8.x) | CockroachDB (v23.x / v24.x) |
|---|---|---|---|
| Linguagem | Go | Rust | Go |
| Topologia Raft | Raft Monolítico | Multi-Raft Escalável | Multi-Raft Escalável |
| Biblioteca | go.etcd.io/raft | raft-rs | Implementação interna Go |
| Storage Engine | bbolt (B+Tree CoW) | RocksDB + Raft Engine | Pebble (LSM-Tree) |
| Leitura Linearizável | ReadIndex | LeaseRead / ReadIndex | Range Leaseholder |
| Escala Típica | 3 a 5 nós (< 32 GB) | Centenas de nós (Petabytes) | Centenas de nós (Petabytes) |
| Caso Principal | Kubernetes Control Plane | Motor Transacional TiDB | SQL Distribuído ACID Global |
-
etcd (CNCF): Sustenta o plano de controle do Kubernetes utilizando o motor
bboltcom mapeamento de memória (mmap). As leituras utilizam ReadIndex para consistência rigorosa sem fsync.7 -
TiKV (CNCF): Desenvolvido em Rust com a biblioteca
raft-rs. Isola o log de consenso no motor dedicado Raft Engine e os dados de aplicação no RocksDB, utilizando o Placement Driver (PD) para rebalanceamento.8 -
CockroachDB: Combina Multi-Raft com o motor LSM-Tree Pebble escrito em Go. Ele desacopla o Líder do Raft do Range Leaseholder, permitindo que o titular do lease processe transações seriais sem round-trips globais.9
Como o consenso viabiliza orquestração resiliente de agentes de código?
Plataformas de execução autônoma utilizam consenso para persistir logs determinísticos de agentes e transações. Elas evitam execuções duplicadas e perdas de estado durante reinicializações de infraestrutura.
Em ambientes como a plataforma MaxVision Code, múltiplos agentes especializados compilam, testam e orquestram pipelines de software concorrentemente. Manter locks distribuídos, concessões de lease temporais e máquinas de estado de execução durável sobre grupos de consenso garante que partições de rede nunca gerem ações contraditórias sobre o código-fonte.10
Se um worker que executa uma tarefa falha, o protocolo redistribui o lease com segurança matemática, permitindo que outro agente assuma a execução a partir do último checkpoint confirmado no log.
Como auditar e diagnosticar clusters de consenso em produção?
O diagnóstico de clusters distribuídos exige monitorar métricas de heartbeat, atraso de replicação e latência de fsync. Esses três pilares revelam instabilidades antes que o quórum seja ameaçado.
Para operar clusters de consenso com alta confiabilidade, equipes de engenharia devem rastrear indicadores essenciais:
-
Raft Proposals Failure Rate: Mede a proporção de propostas rejeitadas por perda de liderança ou estouro de buffer de mensagens pendentes.
-
WAL Fsync Latency: O tempo de persistência em disco do log de consenso. Latências acima de 10 ms indicam saturação do subsistema NVMe.
-
Leader Changes e Term Increments: Picos frequentes no número do termo sinalizam perda de conectividade de rede ou travamentos por garbage collection.
-
Follower Log Lag: O atraso entre o índice de commit do líder e o índice replicado pelos seguidores no cluster.
Compreender a mecânica do consenso distribuído permite projetar arquiteturas resilientes, dimensionar quóruns com rigor matemático e construir sistemas de armazenamento capazes de operar continuamente sob falhas severas de infraestrutura.
Footnotes
-
Fred B. Schneider. Implementing fault-tolerant services using the state machine approach: A tutorial. ACM Computing Surveys (CSUR), 22(4):299-319, 1990. ↩
-
Michael J. Fischer, Nancy A. Lynch, and Michael S. Paterson. Impossibility of distributed consensus with one faulty process. Journal of the ACM (JACM), 32(2):374-382, 1985. ↩
-
Leslie Lamport. Paxos made simple. ACM SIGACT News (Distributed Computing Column), 32(4):18-25, 2001. ↩
-
Diego Ongaro and John Ousterhout. In search of an understandable consensus algorithm. In 2014 USENIX Annual Technical Conference (USENIX ATC 14), pages 305-319, 2014. ↩ ↩2
-
Heidi Howard and Richard Mortier. Paxos vs Raft: Have we reached consensus on distributed consensus?. ACM SIGOPS Operating Systems Review, 54(1):44-52, 2020. ↩
-
Diego Ongaro. Consensus: Bridging theory and practice. PhD thesis, Stanford University, 2014. ↩
-
CNCF / etcd Project. etcd Raft Subsystem, Architecture and Linearizable Reads Specification. Documentation etcd.io, 2026. ↩ ↩2
-
PingCAP / TiKV Authors. TiKV Architecture Guide: Multi-Raft, Coprocessors and Raft Engine. TiKV Documentation, 2026. ↩ ↩2 ↩3
-
Cockroach Labs. CockroachDB Consensus Layer, Range Leases and Pebble Engine. CockroachDB Architecture Manual, 2026. ↩ ↩2
-
Leslie Lamport. Time, clocks, and the ordering of events in a distributed system. Communications of the ACM, 21(7):558-565, 1978. ↩
