Estudos gratuitos da ER Soluções WebVer outros conteúdos grátis
ER Soluções WebEstudos · Designing Data-Intensive Applications

Prova 2 · Dados distribuídos

Parte II (cap. 6–10): replicação, sharding, transações, falhas em sistemas distribuídos, linearizabilidade e consenso

Objetivas

0/20 respondidas
1.
Um banco usa replicação assíncrona e failover automático. Após uma queda do líder, alguns pedidos confirmados sumiram. Explicação:
2.
Depois de um failover, o antigo líder volta e continua aceitando escritas. Esse cenário é chamado:
3.
Após publicar um comentário, o usuário é redirecionado e não o vê. As leituras vão para seguidores. Correção adequada:
4.
Num Cassandra com n = 3, a equipe usa w = 1 e r = 1 para ganhar velocidade. Qual a consequência?
5.
Uma ferramenta colaborativa offline deve mesclar edições simultâneas sem perder texto. Qual técnica?
6.
Um sistema de eventos usa a chave data (AAAA-MM-DD) para sharding por faixa. O que ocorre?
7.
Uma consulta por índice secundário local precisa ir a todos os 50 shards. Qual efeito na latência?
8.
Qual estratégia de rebalanceamento move menos dados ao adicionar um nó?
9.
Num app de reservas de mesas, duas transações em snapshot isolation verificam "há mesa livre?" e ambas reservam a última. Que anomalia é e como evitar?
10.
Qual implementação de serializabilidade é otimista?
11.
Por que bancos como VoltDB conseguem executar transações literalmente uma de cada vez?
12.
Um sistema usa XA para atualizar banco e fila. O coordenador roda no servidor de aplicação, que cai. O que acontece?
13.
Um serviço de lock distribuído concede leases de 30 s. Um cliente pausa 40 s por GC e escreve no storage. Qual proteção é correta?
14.
Qual afirmação sobre relógios está correta?
15.
Uma requisição sem resposta após o timeout pode significar:
16.
Cadastro de usuários exige e-mail único entre regiões. Qual garantia é necessária no ponto de decisão?
17.
Segundo o CAP, numa partição de rede um sistema precisa escolher entre:
18.
Por que IDs gerados com timestamp em vários nós (estilo Snowflake) não dão ordem causal exata?
19.
Num cluster etcd de 3 nós, um nó cai. O que acontece?
20.
Consenso é equivalente a qual destas operações?

Dissertativas

autoavaliação · não entram na nota
D1.
Compare replicação com líder único, multi-líder e sem líder quanto a consistência, disponibilidade e tratamento de conflitos. Indique um caso de uso para cada.
Ver resposta modelo
Líder único: escritas num ponto, sem conflitos, pode ser linearizável; failover é o ponto frágil (perda de escritas assíncronas, split brain). Uso: banco transacional típico. Multi-líder: escrita local em cada região ou dispositivo, tolera offline e partições, mas gera conflitos que exigem LWW (perde dados), mescla manual ou CRDTs. Uso: apps local-first, multi-região. Sem líder: cliente escreve em várias réplicas com quóruns w + r > n, alta disponibilidade, read repair e anti-entropia, versão por vetores; não é linearizável em geral. Uso: carga alta de escrita com tolerância a consistência eventual.
D2.
Explique write skew com um exemplo, por que snapshot isolation não o impede e quais as alternativas para evitá-lo.
Ver resposta modelo
Exemplo: regra de ao menos um médico de plantão; dois médicos leem que há dois de plantão e cada um se retira, alterando linhas diferentes. Em snapshot isolation cada transação lê seu retrato e as escritas não conflitam na mesma linha, então ambas confirmam. Alternativas: isolamento serializável (execução serial, 2PL ou SSI), travar explicitamente as linhas que a decisão leu (SELECT FOR UPDATE), materializar o conflito criando linhas travaveis, ou restrições do banco quando possíveis.
D3.
Por que um nó não pode confiar no próprio julgamento num sistema distribuído? Explique pausas de processo, leases e fencing tokens.
Ver resposta modelo
Um nó pode pausar (GC, VM suspensa, swap) sem perceber e, enquanto isso, a maioria pode declará-lo morto e eleger outro. Ao voltar, ele acha que ainda tem o lease e escreve, corrompendo dados. Leases têm prazo, mas checar o relógio antes de agir não basta, pois a pausa pode vir logo depois. Fencing token: o serviço de lock entrega um número crescente a cada concessão e o recurso rejeita escritas com número menor que o último visto. A verdade é decidida pelo quórum, não pelo nó isolado.
Seu progresso fica salvo neste navegador.