Sistemas Distribuídos

Por que isso é difícil?

• Falha parcial — cada nó pode falhar sozinho enquanto o resto continua rodando.
• Rede não confiável — mensagens podem ser atrasadas, perdidas ou duplicadas.
• Sem relógio compartilhado — não existe uma noção global de "agora".

Nossa loja é um sistema distribuído

Um clique em Finalizar pedido:

Navegador → Gateway → Auth → Order → Product → Redis · Order → PostgreSQL · Order → Kafka

• Cada seta é uma mensagem pela rede; cada caixa pode falhar sozinha.
• Heterogênea (Java, Python, Postgres, Redis, Kafka), fracamente acoplada (HTTP, eventos), cliente-servidor.

Lento ou morto?

Order → Product: reservar 1 unidade do produto 42 … silêncio.

• Requisição perdida? Product caiu? Resposta perdida? Product só está lento? Tudo parece igual.
• A única ferramenta: um timeout — mas ele não diz se a operação foi executada.
• Um retry pode aplicá-la duas vezes → operações repetidas precisam ser idempotentes (ex.: um id único de requisição).

Sem relógio global: tempo lógico

Relógios derivam — nunca ordene eventos de máquinas diferentes por currentTimeMillis().

Relógio de Lamport — um contador por processo:

1. incremente antes de cada evento;
2. anexe o contador a toda mensagem enviada;
3. no recebimento: max(local, received) + 1.

• Garantia: se a aconteceu antes de b, então L(a) < L(b) — a recíproca não vale.
• Relógios vetoriais (um contador por processo) também detectam eventos concorrentes.

O Kafka ordena pelo offset da partição; o Raft, pelo term — autoridades únicas, não relógios de parede.

Teorema CAP

Um sistema que replica dados não garante as três ao mesmo tempo (Brewer 2000; Gilbert e Lynch 2002):

• C — Consistência: toda leitura retorna a escrita mais recente, ou um erro (linearizabilidade — não o C do ACID).
• A — Disponibilidade: toda requisição a um nó vivo recebe uma resposta sem erro, talvez não a última escrita.
• P — Tolerância a partições: continua funcionando quando a rede divide os nós em grupos.

CP ou AP?

CA só existe em um único nó. CP/AP descrevem uma configuração, não um produto — escolha por domínio de dados.

PACELC: e quando não há partição?

Se Partição → A ou C · Senão → Latência ou Consistência

Consenso — e por que é difícil

Consenso: os nós concordam sobre um valor (ou uma ordem de log) apesar de mensagens perdidas e nós que falham — eleição de líder, locks, máquinas de estado replicadas.

• Safety: ninguém decide diferente. Liveness: todos acabam decidindo.

FLP (1985): totalmente assíncrono + um nó pode cair → nenhum algoritmo determinístico sempre termina.

• Paxos e Raft nunca violam a safety; progridem quando a rede se comporta (sincronia parcial).
• Na prática: timeouts — um nó lento parece igual a um que caiu.

Modelos de falha

• Algoritmos de datacenter assumem crash-stop ou crash-recovery.
• Tolerância a falhas bizantinas: blockchains e sistemas críticos de segurança.

Maiorias: por que 3 ou 5 nós

Duas maiorias quaisquer se sobrepõem → duas decisões conflitantes nunca vencem juntas (sem split brain).

Raft

Projetado para ser compreensível (Ongaro e Ousterhout, 2014).

• Eleição: Follower → timeout de eleição aleatório → Candidate → voto da maioria → Leader. Um term maior faz qualquer nó recuar.
• Replicação: o cliente escreve x=5 no líder → AppendEntries → commit após a maioria confirmar → resposta.
• Safety: o log do candidato precisa estar tão atualizado quanto o dos eleitores; entradas confirmadas sobrevivem à falha de qualquer minoria.

Raft: etcd (Kubernetes), Consul, CockroachDB, Kafka KRaft. Paxos (Lamport) é o ancestral mais antigo e mais difícil; o ZooKeeper usa ZAB.

Quóruns

Para N réplicas, uma escrita precisa de W confirmações e uma leitura precisa de R respostas.

N = 3 (Cassandra)	W + R	Efeito
ONE / ONE	2	o mais rápido, leituras podem vir desatualizadas
QUORUM / QUORUM	4	última escrita; tolera 1 nó fora do ar
ALL / ONE	4	um nó fora do ar bloqueia todas as escritas

Consistência eventual e CRDTs

Sistemas AP prometem: sem novas atualizações, as réplicas acabam convergindo — mas não dizem quando.

• Last-Write-Wins — o maior timestamp vence; perde escritas concorrentes, confia em relógios que derivam.
• Relógios vetoriais — detectam escritas concorrentes para resolução explícita.
• CRDTs — um merge comutativo e idempotente: ordem e repetição não importam.

void increment() { counts[me]++; }               // G-Counter: own slot only
void merge(GCounter o) {                          // element-wise max
    for (int i = 0; i < counts.length; i++) counts[i] = Math.max(counts[i], o.counts[i]);
}

Pontos-chave

1. Distribuído: nós independentes, só mensagens, sem relógio compartilhado — nossa loja é um.
2. As 8 falácias são falsas; quem chama não distingue lento de morto: timeouts + retries idempotentes.
3. Ordene eventos com uma autoridade única ou com relógios lógicos, não com relógios de parede.
4. CAP: durante uma partição, escolha C ou A; o PACELC acrescenta latência vs. consistência. Escolha por domínio de dados.
5. FLP: o consenso mantém a safety e depende de timeouts para progredir.
6. Maiorias se sobrepõem — use 3 ou 5 nós; o Raft elege um líder e confirma com a maioria.
7. Quóruns exigem W + R > N; sistemas AP convergem com LWW, relógios vetoriais ou CRDTs.