Replicação e evolutivo consistency

Replicação e evolutivo consistency

1) Para quê evolutivo consistency

• baixa demora de gravação (recepção local),
• melhor disponibilidade nas divisões de rede,
• escala horizontal.

A tarefa-chave é a coerência controlada não-durável: o usuário vê dados «suficientemente recentes», os invariantes de domínio são preservados, os conflitos são detectados e resolvidos de forma previsível.

2) Modelos de coerência - que prometemos ao cliente

Strong: a leitura vê imediatamente a última entrada.
Bounded stale/read-not-older-than (RNOT): leitura não mais velha que a marca (LSN/versão/hora).
Causal: Mantêm relações de causa e efeito (A a B).
Read-Your-Writes: O cliente vê seus registros recentes.
Monotonic Reads: cada leitura seguinte não é «revertida».
Sessão: conjunto de garantias em uma única sessão.
Eventual: Se não houver novos registros, todas as réplicas convergem.

Prática: combine Sessão + RNOT em caminhos críticos e Eventual em vitrines/cachês.

3) Replicação: mecânicos e anti-entropy

Sincronizado (quórum/RAFT): A gravação é considerada um sucesso após a confirmação dos nódulos N; RPO mínimo, acima de p99.
Asincrona: Líder da comitiva local, distribui a revista mais tarde; baixa latência, RPO> 0.
Física (WAL/binlog): rápida, homogênea.
Lógico/CDC: fluxo de alterações no nível de linha/evento, rotação flexível, filtros.
Anti-entropy: cruzamentos e consertos periódicos (árvores Merkle, comparação entre hashs, ré-sync de fundo).

4) Identificadores de versão e pedidos de causalidade

Versões monótonas: increment/LSN/epoch; É simples, mas não codifica o paralelismo.
Lamport timestamp: ordem parcial por relógio lógico.
Vector clock: captura ramos paralelos e permite a detecção de updates conflitantes.
Hybrid/TrueTime/Clock-SI: a lógica do «não antes do T» para a ordem global.

Recomendação: para CRDT/updates de conflito - vector clock; para «não mais velho» - LSN/GTID.

5) Conflitos: detecção e resolução

Situações típicas: gravação de duas regiões para o mesmo objeto.

1. Last-Write-Wins (LWW) é simples, mas pode «perder» updates.

• campos contadores são dobrados (G-Counter/PN-Counter),
• muitas se juntam com «add-wins/remove-wins»,
• somas/balanços - apenas através de revistas transaccionais, não através de LWW simples.
• 3. CRDT (tipos convergentes): G-Counter, OR-Set, LWW-Register, RGA para listas.
• 4. Transformações operacionais (raramente para BD, mais frequente para editores).
• 5. Manual resolution: conflito em «inbox», o usuário seleciona a versão correta.

Regra: Invariantes de domínio definem estratégia. Para dinheiro/sobras - evite a LWW; use transações/eventos com compensação.

6) Garantias de registros e Idempotação

Chaves idimpotentes em comandos (payment, withdraw, create) → repetição é segura.
Deduplicação em «logon» (inbox) e «saída» (outbox) pela chave de idempotação/número de série.
Exactly-once é inviável sem pré-requisitos fortes; pratica at-least-once + idempotidade.
Outbox/Inbox-pattern: gravação em BD e publicação de evento atômico (transação local), o destinatário processa por idempotency-key.

7) Leituras não mais antigas X (RNOT)

• LSN/GTID-gate: o cliente transmite uma versão mínima (a partir da resposta da gravação), o roteador/proxy direciona para a réplica que alcançou o LSN ≥ X, senão para o líder.
• Time-bound: «Não mais velho de 2 segundos» - SLA simples sem versões.
• Sessão pinning: Depois de gravar N segundos, lemos apenas o líder (Read-Your-Writes).

8) Fluxo de alterações e negociação de dinheiro

CDC → pneu de evento (Kafka/Pulsar) → consumidores (cachês, índices, vitrines).
Deficiência de capas: topicks 'invalidate: Se você não estiver satisfeito com o seu dinheiro, você pode usar o seu sistema. idempotent processamento.
Rebuild/Backfill: Reaproxime as projeções do diário de eventos.

9) Sagas e compensações (transações entre servidores)

• Orquestra: O coordenador evoca os passos e as compensações.
• Coreografia: os passos respondem aos eventos e publicam os seguintes.

Invariantes (por exemplo): «equilíbrio ≥ 0» - verificação de limites de passo + compensação de desvio.

10) Região multi e divisões de rede

Local-write, async-replicate: gravação na região local + entrega para outras (EC).
Geo-fencing: dados «colados» na região (baixa latência, menos conflitos).
BB de quórum (Raft) para dados de CP; cachês/vitrines - AP/EC.
Plano Split-brain: Quando você perde o vínculo, as regiões continuam a funcionar dentro dos limites de domínio (write fencing, quotas) e, em seguida, recôncil.

11) Observabilidade e SLO

• Replica lag: tempo/distância LSN/offset (p50/p95/p99).
• Staleness: proporção de respostas acima do limite (por exemplo,> 2s ou LSN
• Confidt rate: frequência de conflitos e merge de sucesso.
• Convertence time: Tempo de duração das réplicas após o pico.
• Recôncile backlog: volume/tempo de partidas atrasadas.
• RPO/RTO por categoria de dados (COP/AP).

• Liga> alvo, aumento de conflitos, «longas» janelas de intransigência.

12) Desenho de esquema de dados sob EC

Versão/vetor explícita em cada gravação (colunas «version», «vc»).
Revistas Append-only para invariantes críticos (balanços, cobranças).
Identificadores de evento (snowflake/ULID) para ordem e dedução.
Campos com natureza comutativa (contadores, muitos) → candidatos a CRDT.
Design API: PUT com if-match/etag, PATCH com precificação.

13) Pattern de armazenamento e leitura

Read model/CQRS: entrada em «origem», leitura a partir de projeções (podem ficar para trás → exibe «atualização»...).
Itinerários Stale-OK (catálogo/fita) vs Strict (carteira/limite).
Sticky/Bounded-stale bandeiras na consulta (título «x-read-consistency»).

14) Folha de cheque de implementação (0-45 dias)

0-10 dias

Categorizar dados: CP críticos (dinheiro, encomendas) vs UE/stale-OK (diretórios, índices de busca).
Definir o SLO de bifurcação (por exemplo, «não mais velho que 2s»), as lajes de destino.
Incluir a versionização de objetos e idempotency-keys na API.

11-25 dias

Implantar CDC e outbox/inbox, rotas de deficiência de cachê.
Adicionar RNOT (gate LSN) e sessão pinning em caminhos críticos de gravação.
Implementar pelo menos uma estratégia merge (LWW/CRDT/domínio) e um registro de conflito.

26-45 dias

Automatizar anti-entropy e relatórios de bife.
Fazer game-day: separação de rede, conflito, recuperação.
Visualizar em dashboards, staleness, conflict rate, convergence.

15) Anti-pattern

LWW cego para invariantes críticos (perda de dinheiro/pontos).
A falta de idempotency → as duplicações de operações de retrações.
O modelo «forte» em todas as caudas p99 excessivas e fragilidade em casos de falhas.
Não há RNOT/Sessão de garantia → UX «piscando», os usuários «não veem» suas alterações.
Descolonização oculta do cachê e da origem (sem CDC/deficiência).
A falta de uma ferramenta de recôncil/anti-entropy - os dados de «séculos» variam.

16) Métricas de maturidade

Replica lag p95 ≤ alvo (por exemplo, ≤ 500 ms dentro da região, ≤ 2 s interregiões).
O Staleness SLO é executado ≥ 99% das solicitações em rotas «rigorosas».
Conflict resolution success ≥ 99. 9%, tempo médio de resolução ≤ 1 min.
Convertence time após picos - minutos, não relógio.
100% das transações «em dinheiro» são cobertas com chaves idempotency e outbox/inbox.

17) Receitas (snippets)

If-Match/ETag (HTTP)

PUT /profile/42
If-Match: "v17"
Body: { "email": "new@example.com" }

Se a versão mudar - '412 Precisition Failed' → o cliente resolve o conflito.

Pedido «não mais velho LSN» (pseudo)

x-min-lsn: 16/B373F8D8

O roteador seleciona uma réplica com 'replay _ lsn ≥ x-min-lsn', senão é o líder.

CRDT G-Counter (ideia)

Cada região guarda o seu contador; O resultado é a soma de todos os componentes; replicação - operação é comutável.

18) Conclusão

O Eventual consistency não é um compromisso de qualidade, mas um contrato consciente: em algum lugar pagamos com frescor pela velocidade e disponibilidade, mas protegemos os invariantes críticos com estratégias e ferramentas de domínio. Digite versões, idempotency, RNOT/Sessão de garantia, CDC e anti-entropy, mede lag/staleness/conflicts - e seu sistema distribuído será rápido, sustentável e previsivelmente convergente, mesmo sob falhas e cargas de pico.