Redis Sentinel ou Cluster: qual escolher e o que muda

Quem procura como manter o Redis no ar quando um servidor cai encontra dois nomes: Sentinel e Cluster. Os dois promovem uma réplica quando o principal some, mas resolvem problemas diferentes, exigem clientes diferentes e mudam o jeito de escrever as chaves. Escolher errado custa caro: um Cluster montado só por alta disponibilidade obriga a reescrever comandos que funcionavam, e um Sentinel montado para dados que não cabem numa máquina só vai adiar o problema. Este guia compara os dois com testes feitos em um Redis 8.0 local e fecha com a questão de licença, que hoje também pesa na escolha.

A diferença em uma frase cada

Sentinel mantém um único conjunto de dados, em um principal com réplicas, e um grupo de processos Sentinel vigia esse principal. Se ele cair, a maioria dos Sentinels autoriza a promoção de uma réplica. Todos os dados continuam numa máquina só.

Cluster divide os dados entre vários principais, cada um com suas réplicas. O espaço de chaves é cortado em 16.384 hash slots, e cada principal é dono de uma faixa. Se um principal cair, os outros principais votam e a réplica dele assume aquela faixa.

Ou seja: Sentinel é alta disponibilidade. Cluster é alta disponibilidade mais divisão de carga e memória. A documentação do Sentinel e a especificação do Cluster descrevem os dois mecanismos em detalhe.

Comparação lado a lado

                         Sentinel                    Cluster
Dados                    1 conjunto, 1 principal     divididos em 16.384 slots
Mínimo para produção     1 principal + réplicas      3 principais + 3 réplicas
                         + 3 Sentinels em máquinas
                         diferentes
Escala de escrita        não (1 principal)           sim (vários principais)
Comandos multi-chave     funcionam                   só na mesma slot
Bancos (SELECT 1..15)    funcionam                   só o banco 0
Cliente                  pergunta ao Sentinel        segue MOVED/ASK
                         quem é o principal          (cliente cluster-aware)
Quem decide o failover   maioria dos Sentinels       maioria dos principais

A linha dos comandos multi-chave é a que mais surpreende quem migra. Vale testar antes.

Testando o Cluster em uma máquina

Para laboratório, seis processos na mesma máquina bastam. Cada nó precisa de uma porta e de modo cluster ligado:

for p in 7001 7002 7003 7004 7005 7006; do
  mkdir -p $p
  (cd $p && redis-server --port $p --cluster-enabled yes \
     --cluster-config-file nodes-$p.conf --daemonize yes)
done

redis-cli --cluster create 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 \
  127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006 --cluster-replicas 1

O --cluster-replicas 1 pede uma réplica para cada principal. Ao final, a ferramenta confirma [OK] All 16384 slots covered, e o CLUSTER INFO mostra o estado:

$ redis-cli -p 7001 cluster info
cluster_state:ok
cluster_slots_assigned:16384
cluster_known_nodes:6
cluster_size:3

Primeira surpresa: o redirecionamento

Sem o modo cluster no cliente, gravar uma chave que pertence a outro nó retorna um erro com o endereço certo:

$ redis-cli -p 7001 set pedido:1 pago
(error) MOVED 15101 127.0.0.1:7003

$ redis-cli -c -p 7001 set pedido:1 pago
OK

O -c faz o redis-cli seguir o redirecionamento. Na aplicação, isso significa usar o modo cluster da biblioteca (por exemplo, a classe de cluster do cliente da sua linguagem), não a conexão comum com um IP.

Segunda surpresa: comandos com várias chaves

$ redis-cli -c -p 7001 mset pedido:1 a pedido:2 b
(error) CROSSSLOT Keys in request don't hash to the same slot

As duas chaves caem em slots diferentes, possivelmente em nós diferentes, e o Redis não faz operação atômica entre nós. A saída são as hash tags: se a chave tem um trecho entre chaves, só esse trecho entra no cálculo da slot.

$ redis-cli -c -p 7001 mset '{pedido:9}:status' pago '{pedido:9}:total' 120
OK
$ redis-cli -p 7001 cluster keyslot '{pedido:9}:status'
(integer) 15349

Isso vale também para MULTI/EXEC, scripts Lua e operações como SUNION. Se o código atual usa muitas transações com chaves soltas, migrar para Cluster é um projeto, não uma troca de configuração.

Terceira surpresa: só existe o banco 0

$ redis-cli -p 7001 select 1
(error) ERR SELECT is not allowed in cluster mode

Quem separava cache e sessão em bancos diferentes precisa trocar por prefixos de chave ou por instâncias separadas.

Como cada um reage à queda

No Sentinel, cada processo marca o principal como fora do ar depois do tempo de down-after-milliseconds; quando o quorum concorda, um Sentinel autorizado pela maioria promove uma réplica e avisa os clientes. A montagem com principal, réplicas e três Sentinels, e o teste de derrubar o primário de propósito, estão no guia Redis Sentinel no Docker Compose.

No Cluster, os nós trocam sinais entre si o tempo todo. Se um principal fica sem responder além do cluster-node-timeout, os outros o marcam como falho, e a réplica dele pede votos aos principais restantes. Com a maioria, ela assume as slots. Se um principal cair sem réplica disponível, a configuração padrão (cluster-require-full-coverage yes) deixa o cluster inteiro recusando comandos, porque parte das slots ficou sem dono.

Nos dois casos a replicação é assíncrona: escritas confirmadas pelo principal pouco antes da queda podem não ter chegado à réplica. Para fila de pagamento ou qualquer dado que não pode sumir, o Redis não substitui um banco com confirmação durável, e operações repetidas precisam ser seguras, como explica o post sobre idempotência no pagamento.

Qual escolher

• Os dados cabem com folga na memória de uma máquina e a carga de escrita também: Sentinel. É mais simples, mantém todos os comandos e qualquer cliente com suporte a Sentinel funciona.
• Os dados ou as escritas já passam do que uma máquina aguenta: Cluster, com o código revisado para hash tags e sem SELECT. A página de escala com Redis Cluster mostra como adicionar nós e redistribuir slots.
• Cache que pode ser reconstruído e um minuto fora não derruba ninguém: talvez nenhum dos dois. Um Redis único, com reinício automático e a aplicação tolerando falha de cache, pode bastar.

Em qualquer caso, cada processo precisa estar em uma máquina ou zona diferente. Seis nós em uma VPS só testam o comportamento, não protegem contra a queda da VPS.

A questão da licença e o Valkey

Até a versão 7.2, o Redis era BSD. Em março de 2024, a versão 7.4 passou para as licenças RSALv2 e SSPLv1, que não são reconhecidas como open source. Na sequência, a Linux Foundation lançou o Valkey, um fork da 7.2.4 mantido pela comunidade e com apoio de grandes provedores de nuvem, como conta o anúncio oficial. A partir do Redis 8.0, a empresa acrescentou a AGPLv3 como terceira opção, que é uma licença open source aprovada pela OSI; os detalhes estão na página de licenças do Redis.

Na prática, para quem só roda o Redis como serviço interno da própria aplicação, qualquer opção costuma servir, mas a decisão é jurídica e vale passar pelo responsável da empresa. Sentinel e Cluster existem tanto no Redis quanto no Valkey, com os mesmos conceitos, então a escolha de topologia deste guia vale para os dois.