Redis Cluster: cache distribuído com alta disponibilidade

O que é Redis Cluster e por que ele existe

Escalando o Redis além de um único servidor

O Redis é, por padrão, uma instância única limitada à memória de uma máquina. Quando o volume de dados ou o throughput ultrapassa essa fronteira, entra o Redis Cluster: um modo nativo de distribuição que particiona automaticamente os dados entre múltiplos nós. Ele foi introduzido na versão 3.0 e resolve tanto o problema de capacidade quanto o de disponibilidade. Com o cluster ativo, falha de um nó não derruba o sistema — o cluster elege um substituto e continua operando sem intervenção manual.

Slots e sharding — como dados são distribuídos

O espaço de 16.384 hash slots

O Redis Cluster divide o keyspace em exatamente 16.384 hash slots. Cada chave é atribuída a um slot usando CRC16(key) mod 16384, e cada nó master é responsável por um subconjunto contíguo desses slots. Se você tem três masters, cada um cuida de aproximadamente 5.461 slots. Quando um cliente escreve uma chave, o cluster calcula o slot e redireciona a requisição ao nó correto com um comando MOVED. Essa arquitetura torna o sharding determinístico, sem tabela de roteamento centralizada vulnerável a falhas.

Nós master e replica no cluster

Replicação integrada para alta disponibilidade

Cada nó master pode ter uma ou mais réplicas que recebem replicação assíncrona em tempo real. As réplicas não servem leituras por padrão (embora isso seja configurável com READONLY), mas ficam prontas para promover caso o master falhe. O número recomendado é de pelo menos um replica por master, formando um cluster mínimo de seis nós — três masters e três réplicas. Essa topologia garante que a perda de qualquer nó único não resulte em perda de slots ou indisponibilidade.

Failover automático — eleição de novo master

Como o cluster sobrevive à falha de um nó

Quando um master fica inacessível, as réplicas desse master detectam a falha via gossip protocol após o timeout configurado em cluster-node-timeout. A réplica mais atualizada (com menor replication offset lag) inicia uma eleição, solicita votos dos demais masters e, ao obter maioria, promove a si mesma. Todo o processo leva tipicamente alguns segundos, durante os quais os slots daquele master ficam indisponíveis. Após a promoção, o cluster atualiza sua tabela de configuração e os clientes recebem redirecionamentos MOVED para o novo master.

Rebalanceamento de slots ao adicionar nós

Crescimento horizontal sem downtime

Adicionar um novo nó ao cluster não redistribui os dados automaticamente — é necessário executar redis-cli --cluster reshard para mover slots do nós existentes para o novo. Durante a migração, o cluster usa os comandos CLUSTER SETSLOT e MIGRATE para transferir chaves individualmente, mantendo o serviço disponível. Os clientes continuam operando normalmente: slots em migração respondem com ASK redirect, que o cliente segue transparentemente. Esse mecanismo permite crescimento incremental sem janelas de manutenção.

Limitações do Redis Cluster — multi-key e transactions

O que muda quando há múltiplos nós

O Redis Cluster impõe uma restrição importante: operações multi-key (MGET, MSET, SUNION, EVAL com múltiplas chaves) só funcionam se todas as chaves residirem no mesmo slot. Para contornar isso, usa-se hash tags: envolver parte da chave entre chaves ({user:1}:profile e {user:1}:cart ficam no mesmo slot). Transações com MULTI/EXEC também ficam restritas a um único slot. Lua scripts que acessam chaves em slots diferentes causam CROSSSLOT error. Entender essas limitações antes de modelar os dados é fundamental para evitar refatorações custosas em produção.

Redis Sentinel vs Redis Cluster

Dois caminhos para alta disponibilidade

O Redis Sentinel monitora uma instância standalone e promove replica automaticamente em caso de falha, mas não distribui dados — toda a memória ainda está em uma única máquina. O Redis Cluster combina alta disponibilidade com sharding horizontal, sendo a escolha correta quando os dados não cabem em um servidor ou quando o throughput exige paralelismo. Sentinel é mais simples de operar e adequado para datasets menores com requisito de HA. Cluster exige mais nós, mais complexidade operacional e cuidado com a modelagem de chaves. A decisão depende principalmente do tamanho do dataset e do padrão de acesso.

Monitoramento e operações no cluster

Visibilidade em um sistema distribuído

O comando CLUSTER INFO retorna métricas essenciais: estado do cluster, número de slots atribuídos, tamanho do epoch de configuração. CLUSTER NODES lista todos os nós com seus IDs, flags e slots. Para monitoramento contínuo, ferramentas como RedisInsight, Prometheus com redis_exporter e Grafana oferecem dashboards com latência por nó, hit rate, memória usada e keyspace events. Alertas críticos incluem cluster_state != ok, número de slots com falha e memória acima de 80% em qualquer nó. Operações de resharding devem ser feitas fora do horário de pico e monitoradas em tempo real.

Casos de uso e anti-padrões

Quando usar Redis Cluster e quando evitar

Redis Cluster é ideal para cache de sessões em alta escala, filas distribuídas com Redis Streams, rate limiting global e leaderboards com grandes volumes. Anti-padrões incluem usar cluster com dados que têm muitas dependências cross-slot, armazenar objetos grandes (acima de 512MB por chave) e usar KEYS * em produção — esse comando bloqueia o servidor e escaneia todos os slots. Outro erro comum é não configurar maxmemory-policy adequadamente; sem ela, o Redis pode rejeitar escritas ou consumir toda a RAM do servidor quando o limite é atingido.

Conclusão

Redis Cluster como pilar de cache distribuído

Continue em: Fundamentos obrigatórios antes de produção.