Sistemas Distribuídos¶

Um sistema distribuído coordena componentes que se comunicam por uma rede. Mensagens podem sofrer atraso, duplicação, reordenação ou perda; componentes podem falhar independentemente; e não existe um relógio global perfeitamente sincronizado.

Primeiro, o modelo de falhas¶

A garantia de um algoritmo depende das falhas presumidas: parada por falha, falha com recuperação, omissão, temporização ou comportamento bizantino. “Trata falhas” é uma afirmação vaga demais sem esse modelo.

Entrega e processamento¶

Rótulos como no máximo uma vez e pelo menos uma vez descrevem tentativas de entrega, não efeitos de negócio automáticos de ponta a ponta. Efeitos exatamente uma vez exigem estado coordenado ou processamento idempotente/deduplicado sob um limite definido.

Uma chave de idempotência deve identificar uma operação lógica, possuir um ciclo de vida e vincular-se aos parâmetros e ao resultado da operação. Repetir com uma nova chave impede a deduplicação.

Consistência¶

A linearizabilidade faz cada operação parecer atômica entre a invocação e a resposta. Garantias sequenciais, causais, eventuais e de sessão são modelos distintos. A consistência eventual, por si só, afirma que haverá convergência depois que as atualizações cessarem; não define a resolução de conflitos nem um limite de tempo útil.

O resultado CAP trata da consistência e da disponibilidade durante uma partição de rede. Ele não é uma instrução geral para escolher apenas duas propriedades durante a operação normal.

Tempo e ordenação¶

Use tempo monotônico para durações locais. Relógios de parede podem saltar e divergir entre máquinas. Relógios lógicos capturam propriedades de ordenação causal ou total sem fingir fornecer tempo físico perfeitamente sincronizado.

Fluxos confiáveis¶

atribua identificadores estáveis a operações e mensagens;
torne os consumidores idempotentes ou faça deduplicação durável;
use novas tentativas limitadas com backoff, jitter e deadlines;
use uma outbox transacional quando um commit local e a publicação durável de um evento precisarem concordar;
defina o tratamento de mensagens problemáticas e dead letters;
monitore atraso, saturação, novas tentativas e reconciliação com logs, métricas e traces de cardinalidade limitada;
teste falhas parciais, não apenas indisponibilidades completas.

Exercícios¶

Explique por que um timeout no cliente não prova que o servidor falhou no commit.
Projete um consumidor de mensagens idempotente.
Compare a garantia de leitura das próprias escritas com a linearizabilidade.