Redis Sentinel no Node.js

O Redis Sentinel no Node.js oferece descoberta do master atual, monitoramento e failover automático para uma implantação Redis sem sharding. Quando o master falha, múltiplos Sentinels precisam concordar, uma réplica é promovida e clientes compatíveis descobrem o novo endereço.

Sentinel melhora disponibilidade, mas não cria consistência forte. A replicação continua assíncrona e uma escrita confirmada pode ser perdida se o master falhar antes de propagá-la. A aplicação precisa usar Redis para dados compatíveis com esse modelo e testar failover regularmente.

Neste guia, você aprenderá a configurar Sentinels, conectar com ioredis, escolher quorum, tratar reconexões, proteger credenciais, limitar perda de writes e monitorar o processo de promoção.

O que é Redis Sentinel?

A documentação oficial de alta disponibilidade com Redis Sentinel descreve quatro capacidades:

• Monitoring: verifica master e réplicas.
• Notification: emite eventos sobre falhas e mudanças.
• Automatic failover: promove uma réplica.
• Configuration provider: informa aos clientes quem é o master.

Sentinel ou Redis Cluster?

Sentinel mantém um único master responsável por todo o dataset. Redis Cluster distribui slots entre vários masters. Use Sentinel quando o dataset cabe em uma instância e a principal necessidade é failover. Use Cluster quando precisa de sharding e throughput horizontal.

Consulte Redis Cluster no Node.js.

Topologia mínima

Uma implantação robusta usa:

• um master;
• duas ou mais réplicas;
• três Sentinels em falhas independentes;
• clientes compatíveis com Sentinel.

Dois Sentinels não formam uma arquitetura segura para partições. Distribua três instâncias entre hosts ou zonas.

Configuração do Sentinel

port 26379
sentinel monitor mymaster redis-master.internal 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

O nome mymaster identifica o conjunto. O quorum dois significa que dois Sentinels precisam considerar o master indisponível para marcar objective down.

Quorum e maioria

Quorum detecta a falha. Para executar failover, um Sentinel também precisa ser eleito e obter votos da maioria dos Sentinels conhecidos. Com três instâncias, duas precisam se comunicar.

down-after-milliseconds

Um valor muito baixo gera failovers por pausas de rede ou carga. Um valor alto prolonga indisponibilidade. Meça latência, GC, rede e comportamento real antes de escolher.

parallel-syncs

Define quantas réplicas podem sincronizar com o novo master ao mesmo tempo. Um valor menor preserva mais réplicas disponíveis, mas prolonga a convergência.

Instalando ioredis

npm install ioredis

O ioredis consulta Sentinels para encontrar o master e acompanha mudanças. Consulte o repositório do ioredis para opções da versão usada.

Conexão com o master

import Redis from 'ioredis';

const redis = new Redis({
  sentinels: [
    { host: 'sentinel-1.internal', port: 26379 },
    { host: 'sentinel-2.internal', port: 26379 },
    { host: 'sentinel-3.internal', port: 26379 }
  ],
  name: 'mymaster',
  role: 'master',
  username: process.env.REDIS_USERNAME,
  password: process.env.REDIS_PASSWORD,
  sentinelUsername: process.env.SENTINEL_USERNAME,
  sentinelPassword: process.env.SENTINEL_PASSWORD,
  connectTimeout: 3000,
  commandTimeout: 1000,
  maxRetriesPerRequest: 1
});

O cliente tenta Sentinels até descobrir o master atual. Não configure apenas o endereço antigo do master.

Conexão de leitura

const replica = new Redis({
  sentinels,
  name: 'mymaster',
  role: 'slave',
  preferredSlaves: [{ ip: '10.0.2.15', port: 6379, prio: 1 }]
});

Reads em réplicas podem retornar dados atrasados. Use somente para cargas tolerantes a eventual consistency.

Eventos

redis.on('ready', () => logger.info('Redis pronto'));
redis.on('reconnecting', delay => {
  logger.warn({ delay }, 'Redis reconectando');
});
redis.on('error', error => {
  logger.error({ error }, 'Erro Redis');
});

Durante failover, comandos podem falhar. Métricas devem diferenciar erro transitório de indisponibilidade prolongada.

Retry strategy

retryStrategy(times) {
  return Math.min(times * 100, 2000);
}

Não deixe requisições presas por minutos. Defina timeout da operação e fallback. Para cache, a API pode consultar a fonte original. Para lock ou sessão, a política precisa ser mais conservadora.

Consistência e perda de writes

O master responde antes de todas as réplicas confirmarem. Se ele falhar nesse intervalo, a réplica promovida pode não conter a escrita.

await redis.set('payment:42', 'authorized');
const acknowledgements = await redis.wait(1, 1000);

WAIT reduz a janela, mas não transforma o sistema em um banco fortemente consistente. Mantenha pagamentos e pedidos em PostgreSQL. Veja Transações PostgreSQL no Node.js.

Limitando writes em partições

min-replicas-to-write 1
min-replicas-max-lag 10

O master para de aceitar writes quando não possui uma réplica suficientemente atualizada. Isso reduz o tempo em que um master isolado aceita dados que serão descartados, mas diminui disponibilidade quando réplicas falham.

Split brain

Em uma partição, clientes próximos ao master antigo podem continuar conectados enquanto outra réplica é promovida. Configure limites de réplica, rede e clientes para reduzir o risco. O sistema ainda exige reconciliação de impactos.

Service discovery

O cliente consulta:

SENTINEL GET-MASTER-ADDR-BY-NAME mymaster

Depois de um failover, o resultado muda. Aplicações não devem armazenar o endereço permanentemente fora do cliente Sentinel-aware.

Verificando o quorum

redis-cli -p 26379 SENTINEL CKQUORUM mymaster

Inclua esse comando em checks operacionais. Um master saudável com quorum quebrado não terá failover quando precisar.

Inspecionando o estado

redis-cli -p 26379 SENTINEL MASTER mymaster
redis-cli -p 26379 SENTINEL REPLICAS mymaster
redis-cli -p 26379 SENTINEL SENTINELS mymaster

Failover manual

redis-cli -p 26379 SENTINEL FAILOVER mymaster

Use para testes e manutenção controlada. Acompanhe eventos, reconexões e consistência da aplicação.

Teste de falha

1. gere carga de leitura e escrita;
2. registre valores esperados;
3. interrompa o master;
4. meça tempo até promoção;
5. confirme novo endereço;
6. verifique erros e writes perdidos;
7. reintegre o nó antigo como réplica.

Não espere o primeiro incidente de produção para testar.

Docker e NAT

Sentinel descobre endereços e portas anunciados. Port mapping e NAT podem fazer os nós anunciarem valores inalcançáveis. Use mapeamento 1:1, host networking ou diretivas announce-ip e announce-port cuidadosamente.

DNS e TLS

Versões modernas oferecem suporte opcional a hostnames. Use resolução confiável e nomes compatíveis com certificados. Misturar IPs e hostnames pode quebrar clientes ou validação TLS.

Kubernetes

StatefulSets fornecem identidade estável, mas Sentinel ainda precisa de configuração, persistência e descoberta coerente. Prefira operador ou chart maduro, anti-affinity e PodDisruptionBudget.

ACL e autenticação

Proteja Redis e Sentinels com usuários separados. O cliente precisa de credenciais para consultar Sentinel e acessar o master. Aplique privilégio mínimo e rotação. Consulte Gestão de Segredos no Node.js.

Persistência

Sentinel não substitui AOF, RDB e backups. Configure durabilidade conforme o caso e teste restore. Failover mantém disponibilidade; backup protege contra exclusão, corrupção e erro humano.

Cache versus estado crítico

Para cache, a perda de uma escrita pode ser aceitável. Para sessões, rate limit, locks e filas, analise comportamento de failover. Para dados financeiros, use banco transacional.

Locks

Um lock em master antigo pode desaparecer após promoção. Use token, TTL e fencing no sistema protegido. Veja Locks Distribuídos com Redis.

Shutdown

async function shutdown() {
  await redis.quit();
}

process.on('SIGTERM', shutdown);

Consulte Graceful Shutdown no Node.js.

Observabilidade

Monitore:

• master atual e mudanças de role;
• quorum disponível;
• Sentinels descobertos;
• réplicas e replication lag;
• eventos sdown, odown e failover;
• tempo de promoção;
• erros e reconexões do cliente;
• writes bloqueados por falta de réplica.

Erros comuns

• Dois Sentinels: não existe maioria segura durante falha de uma máquina.
• Cliente sem Sentinel: continua apontando ao master antigo.
• Quorum não monitorado: failover falha silenciosamente.
• NAT incorreto: endereços anunciados são inalcançáveis.
• Reads críticos em réplica: dados atrasados são aceitos.
• Redis como fonte de verdade: writes podem ser perdidos.
• Sem teste de failover: credenciais ou DNS quebram durante incidente.
• Retry ilimitado: APIs acumulam requisições.

Conclusão

O Redis Sentinel no Node.js oferece descoberta do master e failover automático para uma topologia sem sharding. Três Sentinels independentes, réplicas e um cliente compatível formam a base da disponibilidade.

Escolha quorum e timeouts com dados reais, proteja rede e credenciais e monitore a capacidade de failover. Entenda a replicação assíncrona, limite writes em partições e mantenha dados críticos em banco transacional. Assim, Sentinel reduz downtime sem prometer garantias que Redis não oferece.