8.3. Transações distribuídas e exactly-once
Two-phase commit dá atomicidade entre nós, ao custo de bloquear se o coordenador sumir.
Resumo
- 2PC: coordenador pede prepare; todos votam sim → commit; algum não → abort. Votar sim é promessa irrevogável.
- Se o coordenador cai após o prepare, participantes ficam in doubt, segurando locks até ele voltar.
- XA liga sistemas heterogêneos (banco + fila), mas o coordenador vira ponto único de falha e gargalo.
- Transações internas do banco distribuído (Spanner, CockroachDB) funcionam melhor: um só protocolo, com consenso.
- Exactly-once na prática: processar e gravar o efeito atomicamente, ou idempotência com IDs de mensagem.
Perguntas-chave
responda de cabeça, depois abraPor que um participante não pode desistir depois de votar sim?
O coordenador pode já ter decidido commit e avisado outros; desistir quebraria a atomicidade.
Por que XA tem má fama?
Coordenador frequentemente roda no servidor de aplicação sem replicação, transações in doubt seguram locks, e o menor denominador comum limita os recursos.
Como obter exactly-once sem 2PC?
Tornar o consumidor idempotente, gravando o ID da mensagem junto com o resultado para ignorar repetições.
Exercícios de fixação
0/5 respondidas1.
Todos os participantes votaram sim e o coordenador cai antes de enviar a decisão. Qual o estado dos participantes?
2.
Qual a diferença essencial entre 2PC e consenso?
3.
Um consumidor lê um evento de pagamento, grava no banco e cai antes de confirmar a leitura na fila. O evento será entregue de novo. Como evitar cobrança dupla?
4.
Por que transações internas de bancos como Spanner funcionam melhor que XA entre sistemas diferentes?
5.
No 2PC, o ponto sem volta para o coordenador é quando: