9.2. Pausas, maioria, leases e fencing
Um nó pode pausar sem saber; a verdade é decidida pela maioria, e tokens de fencing barram o líder zumbi.
Resumo
- Pausas de processo: GC, VM suspensa, swap. O nó congela segundos e volta achando que nada aconteceu.
- Um nó não confia só em si: a verdade é definida pela maioria (quórum). Nó declarado morto deve aceitar isso.
- Lease (lock com prazo) não basta: após uma pausa, o dono pode agir com lease vencido. Use fencing token crescente.
- Falha bizantina: nós mentem ou corrompem. Rara em datacenter próprio; relevante em blockchain e hardware aberto a ataques.
- Modelos de sistema (síncrono, parcialmente síncrono, crash-recovery) e testes: formal methods, fuzzing, simulação determinística.
Perguntas-chave
responda de cabeça, depois abraComo funciona o fencing token?
Cada lease concedido vem com um número maior que o anterior; o recurso rejeita escritas com número menor que o último visto.
Por que um nó não pode decidir sozinho que ainda é líder?
Ele pode ter pausado e a maioria pode já ter eleito outro; só o quórum define o estado aceito.
O que é simulação determinística?
Executar o sistema com rede, relógios e falhas simulados e controlados por semente, para reproduzir bugs raros de concorrência.
Exercícios de fixação
0/5 respondidas1.
Um cliente pega um lease de 10 s, sofre GC de 15 s e então grava no armazenamento. O que evita a corrupção?
2.
Qual destas causa pausas longas e inesperadas num processo?
3.
Um nó isolado da rede acha que é líder, mas a maioria elegeu outro. Quem está certo?
4.
Em qual cenário vale a pena tolerar falhas bizantinas?
5.
Um bug de concorrência aparece uma vez por mês em produção. Qual técnica ajuda a reproduzi-lo?