Pular para o conteúdo
thiagoetipadrões

Contatos

apps/scalability/leader-election

142 · Escalabilidade & Infraestrutura · ≈ 6 min de estudo

Leader Election

Entre várias réplicas de um serviço, uma só executa o trabalho que não pode rodar em paralelo. O líder é quem detém um lease com prazo no Redis e o renova por heartbeat; se ele some, o lease expira e outro nó assume. Cada mandato recebe um fencing token crescente, e o destino das escritas recusa token antigo — assim um líder que volta de uma pausa longa não sobrescreve o trabalho do sucessor. Use em jobs únicos de cluster: conciliação, liquidação em lote, cron distribuído.

passos
6
arquivos
3
testes
0
tecnologias
4
Infraestrutura realTypeScriptBunRedisDocker
CenárioRelaçõesComparar
Baixar cartão

Cenário

Três réplicas do serviço de conciliação bancária rodam o tempo todo, mas a conciliação diária só pode ser executada por uma. O líder congela (crash, pausa longa de GC): o lease expira e outra réplica assume com token maior. Quando o antigo líder acorda, ainda se achando líder, tenta gravar o resultado da conciliação — e é recusado pelo token.

Planta

Estados
7/7
heartbeat renova(Lua confere o dono)CANDIDATELEADERFOLLOWERSET NX PX ok,INCR fencinglease de outro nolease expirouou foi liberadorenovacao falhoushutdown libera o lease
7

7 passos — reproduza para seguir o fluxo

  • chamada
  • resposta ou assíncrono
  • falha
  • passo
  • toque num nó para focar
  • repouso ou sucesso
  • transição
  • falha ou recusa
  • Outras plantas de estados

Como funciona

6 passos

Um nó eleito coordena o cluster.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

GET+2
INCR+1
DEL+1
  1. 01

    Cada candidatura usa um dono novo (nodeId:uuid) e tenta SET leader:reconciliation <dono> NX PX <ttl>; quem consegue faz INCR e recebe o fencing token do mandato

  2. 02

    O líder renova a cada heartbeat com um script Lua que só faz PEXPIRE se o valor ainda for o seu dono; a liberação no shutdown é o mesmo GET+DEL atômico

  3. 03

    Renovação falhou → o nó vira FOLLOWER na hora; o job em execução confere a liderança antes de cada etapa e aborta

  4. 04

    timingValidate exige heartbeat × 3 < TTL: TTL curto demais troca de líder à toa, longo demais atrasa o failover

  5. 05

    O destino grava o resultado por Lua guardando o maior token aceito e recusando qualquer token menor — o líder zumbi é barrado ali, não por confiar nele

  6. 06

    CrashOutro nó assume depois do TTL; shutdown gracioso libera o lease e a troca acontece no próximo tick

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Execução única sem coordenador próprio

  • Failover automático em até um TTL

  • Fencing token barra o líder zumbi

  • Job longo para ao perder o lease

Custos

  • Redis vira ponto único de coordenação: precisa de alta disponibilidade

  • Entre a queda e a expiração, ninguém executa

  • Todo destino das escritas precisa conferir o token

  • O job precisa ser dividido em etapas retomáveis

apps/scalability/leader-election

3 arquivos

src/

  • lease_leader.tsLease: aquisição com fencing token, renovação e liberação conferindo o dono
  • node_leader.tsNó: estados, heartbeat, validação dos tempos e job que aborta ao perder a liderança
  • ledger_fenced.tsDestino das escritas que recusa fencing token antigo

Executar · com Docker

  1. ./docker.sh up# sobe Redis
  2. cp .env.example .env# variáveis de ambiente
  3. bun install# dependências
  4. bun run demo# roda o cenário
  5. bun run test# integração contra o serviço real
Requisitos
BunDocker
Sobe junto
Redis

Relações

Onde ele se encaixa

Mapa
  1. Leader Election
  • Combina com3

Por que se relacionam

Combina com

Teste rápido

Qual destes combina com Leader Election?

Próximo projeto · Escalabilidade & InfraestruturaQueue-Based Load Leveling
Esc

↑ ↓ navegarEnter abrir191 resultados