Redis: O padrão da indústria

Replicação, Sentinel e Cluster

Descubra como garantir alta disponibilidade e escalabilidade com replicação, Sentinel e Cluster.

Avançado 50 min 35 pontos Leitura 0%

Nesta aula você vai

  • Configurar replicação master-replica e entender replicação assíncrona
  • Implementar alta disponibilidade com Redis Sentinel e failover automático
  • Dimensionar Redis Cluster para sharding horizontal e tolerância a falhas

Replicação, Sentinel e Cluster

Objetivos

Nesta aula você vai:

  • Dominar o modelo master-replica do Redis e suas limitações de consistência
  • Configurar Sentinel para detecção de falha e promoção automática de réplica
  • Compreender sharding e hash slots no Redis Cluster

Introdução

Uma instância única de Redis é ponto único de falha (SPOF). Em produção, equipes exigem disponibilidade, capacidade além de uma máquina e plano de recuperação sem intervenção manual às 3h da manhã. O Redis evoluiu três respostas complementares: replicação (cópia de dados), Sentinel (HA para topologia master-replica) e Cluster (sharding + HA integrados).

Esta aula é densa — trate-a como referência arquitetural, não apenas tutorial de comandos.

Conteúdo

Replicação assíncrona master → replica

O master aceita writes; réplicas recebem stream de comandos e servem reads opcionais.

# Na réplica
REPLICAOF 192.168.1.10 6379
INFO replication

Saída típica:

Campo Significado
role:master / role:slave Papel do nó
connected_slaves Réplicas ligadas ao master
master_link_status:up Stream de replicação saudável
slave_repl_offset Offset de sincronização

Consistência: replicação é assíncrona por padrão. Cliente pode receber OK no master e a réplica ainda não ter o dado — janela de perda se master cair segundos depois. WAIT numreplicas timeout força confirmação de N réplicas antes de retornar (mais latência, menos perda).

Reads em réplica reduzem carga no master, mas podem ser stale — aceitável para dashboards; perigoso para "read-your-writes" sem roteamento cuidadoso.

Redis Sentinel — HA sem sharding

Sentinel é processo separado (idealmente 3+ instâncias em hosts distintos) que:

  1. Monitora master e réplicas (health check)
  2. Detecta falha subjetiva/objetiva (quorum)
  3. Promove réplica elegível a novo master
  4. Notifica clientes e atualiza configuração (SENTINEL get-master-addr-by-name)

Topologia mínima recomendada:

        [Sentinel 1] [Sentinel 2] [Sentinel 3]
              \         |         /
               \        |        /
            [Master] ←→ [Replica 1]
                    ↘   [Replica 2]

Clientes modernos (Lettuce, redis-py com Sentinel support) resolvem o master atual após failover — evite IP hardcoded.

Configuração conceitual em sentinel.conf:

sentinel monitor mymaster 192.168.1.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000

Quorum 2 em monitor com 3 sentinels: dois devem concordar que master está down.

Redis Cluster — sharding em 16 384 slots

Quando um nó não cabe em RAM ou CPU, Cluster particiona chaves em hash slots (0–16383):

slot = CRC16(key) mod 16384

Cada master governa subset de slots; réplicas por shard para HA.

redis-cli --cluster create node1:6379 node2:6379 node3:6379 \
  node4:6379 node5:6379 node6:6379 --cluster-replicas 1

Cliente Cluster-aware segue redirecionamentos MOVED e ASK:

redis-cli -c -h node1 -p 6379
SET usuario:1000 "dados"

Multi-key: comandos que tocam múltiplas chaves exigem mesma tag hash — {user:1000}:profile e {user:1000}:sessions colidem no mesmo slot via hash tag {...}.

Quando usar cada modo

Cenário Solução
HA, dataset cabe em um master Master + réplicas + Sentinel
Dataset > RAM de um servidor Cluster
Reads escaláveis, stale OK Réplicas + roteamento read
Consistência forte cross-shard Evite Cluster para transação complexa; repense modelo

Armadilhas de produção

  • Split-brain sem quorum Sentinel adequado
  • Promoção de réplica desatualizada — monitorar master_repl_offset
  • Cliente não-Sentinel/Cluster após failover — conexões presas a IP morto
  • KEYS e scans globais em Cluster — custo multiplica por nós

Exemplos práticos

Verificar topologia de replicação:

redis-cli INFO replication
redis-cli ROLE

Simular read na réplica (config replica-read-only yes):

# Na réplica
GET chave-teste

Consultar master via Sentinel (quando Sentinel rodando):

redis-cli -p 26379 SENTINEL masters
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster

Inspecionar cluster:

redis-cli -c CLUSTER NODES
redis-cli -c CLUSTER SLOTS
redis-cli --cluster check node1:6379

Resumo

  • Replicação copia dados de master para réplicas de forma assíncrona; WAIT aumenta durabilidade com custo de latência.
  • Sentinel automatiza failover em topologia master-replica — use 3+ sentinels e clientes compatíveis.
  • Cluster sharda em 16 384 slots com réplicas por shard; exige clientes cluster-aware e hash tags para multi-key.
  • Escolha Sentinel para HA simples; Cluster para escala horizontal de dados.
  • Teste failover em staging: medir RTO real e dados perdidos na janela de replicação.