Entendendo o Redis Cluster: Arquitetura e Mecanismos

Redis Cluster (集群) é a solução oficial do Redis para alta disponibilidade distribuída, focada em superar gargalos de performance de nós únicos e gerenciar grandes volumes de dados. Ele combina particionamento (sharding), replicação mestre-escravo e failover automático para distribuir dados, balancear carga de leitura/escrita e garantir alta disponibilidade, sendo a escolha padrão para implantações em larga escala.

Diferente da arquitetura Mestre-Escravo com Sentinel, onde todos os dados residem em um único mestre, o Redis Cluster particiona os dados entre múltiplos mestres, eliminando gargalos de memória, CPU e I/O de um nó isolado e permitindo o armazenamento de terabytes de dados. Além disso, o Cluster integra nativamente a replicação e o failover, dispensando a necessidade de um processo Sentinel externo.

Este artigo explora o Redis Cluster em seis dimensões: posicionamento central, componentes da arquitetura, mecanismo de particionamento, fluxos de operação essenciais, guia prático de implantação e questões comuns, visando oferecer uma compreensão completa tanto teórica quanto prática, adequada para entrevistas e aplicações em produção.

Posicionamento Central e Valor do Redis Cluster

1.1. Posicionamento Central

O Redis Cluster é uma arquitetura distribuída que particiona os dados entre vários nós. Cada nó é responsável por um subconjunto dos dados. A replicação mestre-escravo assegura a alta disponibilidade de cada partição, com o próprio cluster gerenciando a detecção e o failover automático, sem a intervenção do Sentinel.

1.2. Valor Fundamental (Soluções para Dores)

Superação de Gargalos de Nó Único: O particionamento distribui os dados, aliviando as limitações de memória (ex: 16GB, 32GB), CPU e I/O de um único nó. Permite o armazenamento de dados em escala de terabytes.
Balanceamento de Carga: Requisições de leitura e escrita são distribuídas uniformemente entre os nós, prevenindo a sobrecarga de um nó e aumentando a capacidade de processamento geral (suportando dezenas ou centenas de milhares de QPS).
Alta Disponibilidade: Cada partição possui um mestre e um ou mais escravos. Em caso de falha do mestre, um escravo é promovido automaticamente a novo mestre, garantindo maior disponibilidade que a configuração Mestre-Escravo + Sentinel.
Escalabilidade Robusta: Suporta adição e remoção dinâmica de nós sem interrupção do serviço. Novos nós recebem dados automaticamente, e ao remover um nó, seus dados são migrados para outros.

1.3. Diferenças Cruciais em Relação a Mestre-Escravo + Sentinel

Dimensão de Comparação	Mestre-Escravo + Sentinel	Redis Cluster
Armazenamento de Dados	Todos os dados em um único Mestre; Escravos são apenas backups.	Dados particionados; Múltiplos Mestres armazenam diferentes conjuntos de dados.
Gargalo de Performance	Gargalo do nó único (limitações de memória/CPU).	Sem gargalo de nó único; performance escalável pela adição de nós.
Mecanismo de Alta Disponibilidade	Requer Sentinel para failover.	Mecanismo integrado de detecção e failover; dispensa Sentinel.
Escalabilidade	Baixa; Expansão dinâmica requer configuração manual.	Alta; Suporta expansão/redução dinâmica com migração automática de dados.
Cenários de Uso	Dados em pequena/média escala, alta disponibilidade necessária, carga de leitura predominante.	Dados em larga escala, alta concorrência, necessidade de escalabilidade.

Arquitetura Central do Redis Cluster

O Redis Cluster adota uma arquitetura de "particionamento mestre-escravo", composta por quatro elementos principais: Nós, Slots (Partições), Replicação Mestre-Escravo e o Barramento do Cluster.

2.1. Componentes Principais

(1) Nós (Nodes)

Cada instância do Redis no cluster é um nó. Existem dois tipos:

Nó Mestre (Master Node): Responsável pelo armazenamento de dados e processamento de requisições de leitura/escrita. Cada mestre gerencia uma partição (slot) e armazena um subconjunto dos dados.
Nó Escravo (Slave Node): Backup do nó mestre correspondente. Sincroniza dados do mestre e é promovido a mestre em caso de falha.
Requisito Mínimo de Nós: Pelo menos 3 nós mestres, cada um com pelo menos 1 nó escravo. Uma arquitetura recomendada é 3 mestres e 3 escravos (total de 6 nós) para garantir equilíbrio e alta disponibilidade.

(2) Slots (Partições)

O Redis Cluster divide o espaço total de chaves em 16384 slots (numerados de 0 a 16383). Cada slot representa uma fração dos dados.

Cada nó mestre é responsável por um conjunto de slots. Por exemplo, com 3 mestres, cada um gerencia aproximadamente 5461 slots.
Ao armazenar um dado, o Redis calcula o slot correspondente com base no hash da chave (CRC16(key) % 16384) e direciona o dado para o nó mestre que gerencia esse slot.
A associação entre slots e mestres é conhecida por todos os nós do cluster, garantindo que cada nó saiba qual mestre é responsável por qual slot.
A realocação de slots é a base para as operações de adição/remoção de nós (escalabilidade).

(3) Replicação Mestre-Escravo

Similar à replicação tradicional, mas integrada ao cluster:

Backup de Dados: Escravos mantêm cópias dos dados dos seus mestres, prevenindo perda de dados.
Failover: Em caso de falha do mestre, um de seus escravos é eleito para substituí-lo, assumindo seus slots e requisições.
Balanceamento de Leitura: Requisições de leitura podem ser direcionadas aos escravos (configurando-os como somente leitura), aliviando a carga dos mestres.

(4) Barramento do Cluster (Cluster Bus)

Todos os nós se comunicam através de conexões TCP em uma porta específica (porta do nó + 10000, ex: 6379 -> 16379). Funções:

Sincronização de Estado: Nós trocam informações sobre seu status (online/offline), atribuição de slots e relacionamentos mestre-escravo.
Detecção de Falhas: Um mecanismo de heartbeat (ping a cada 1 segundo, por padrão) permite que nós detectem a indisponibilidade de outros.
Propagação de Informações de Slots: A associação entre slots e mestres é atualizada e distribuída a todos os nós.
Coordenação de Failover: Facilita a eleição de um novo mestre quando um mestre atual falha.

2.2. Exemplo de Arquitetura Padrão (3 Mestres, 3 Escravos)

Uma configuração comum em produção (6 nós):

Nó Mestre	Porta	Slots Gerenciados	Nó Escravo Correspondente	Porta do Escravo
Master1	6379	0-5460	Slave1	6380
Master2	6381	5461-10922	Slave2	6382
Master3	6383	10923-16383	Slave3	6384

Observação: A distribuição de slots é aproximadamente igual (16384 / 3 ≈ 5461) para garantir o balanceamento de carga. Cada mestre tem um escravo para alta disponibilidade.

Mecanismos Essenciais do Redis Cluster

3.1. Alocação de Slots e Armazenamento de Dados

O particionamento é a chave para a distribuição de dados. O processo envolve duas etapas: alocação de slots e localização de dados.

(1) Alocação de Slots (Inicialização/Escalonamento)

Ao criar o cluster, os 16384 slots precisam ser distribuídos entre os nós mestres. Isso pode ser feito manualmente ou com ferramentas.

Cada mestre registra os slots que gerencia.
Essa informação é disseminada via barramento do cluster para todos os nós, criando um mapa completo de "slot -> mestre".
Exemplo de comando para alocar slots a um mestre (executado no próprio mestre):

redis-cli -p 6379 cluster addslots {0..5460}

(2) Localização de Dados (Requisições do Cliante)

Quando um cliente envia uma requisição (ex: SET minhaChave valor):

O cliente envia a requisição para qualquer nó do cluster.
O nó calcula o slot para minhaChave: slot = CRC16(minhaChave) % 16384.
O nó consulta seu mapa de "slot -> mestre" para identificar qual mestre gerencia este slot.
Se o nó atual for o mestre responsável pelo slot, ele processa a requisição.
Caso contrário, o nó responde com um erro MOVED, informando o endereço (IP:porta) do mestre correto.
O cliente, ao receber o MOVED, reenvia a requisição para o mestre correto. Clientes com suporte a modo cluster (como redis-cli -c) lidam com essa redireção automaticamente.

3.2. Detecção de Falhas e Failover Automático

O cluster detecta e reage a falhas sem necessidade de Sentinel.

(1) Detecção de Falhas (Identificação de Nó Offline)

Nós enviam pings via barramento do cluster a cada segundo.
Se um nó (ex: Master1) não responde por cluster-node-timeout (padrão: 15000ms), o nó remetente o marca como "suspeito de offline" (PFAIL).
Essa informação é propagada. Se mais da metade dos mestres marcarem um nó como PFAIL, ele é declarado "definitivamente offline" (FAIL) e a informação é disseminada.

(2) Failover Automático (Após Falha de Mestre)

Quando um mestre é marcado como FAIL:

Todos os escravos desse mestre competem para se tornar o novo mestre.
Cada escravo solicita votos aos outros mestres do cluster.
Os mestres votam com base na "perspectiva de sincronização" (offset de dados). Escravos mais atualizados têm prioridade.
O escravo que obtiver votos da maioria dos mestres é promovido a novo mestre.
O novo mestre assume os slots do mestre anterior e atualiza o mapa de "slot -> mestre" em todo o cluster via barramento.
Outros escravos (do mestre original) sincronizam com o novo mestre.
Se o mestre original retornar, ele se torna escravo do novo mestre.

O tempo de failover geralmente é de 15-30 segundos. Durante esse período, requisições para os slots afetados podem falhar temporariamente. Clientes devem implementar retentativas.

3.3. Escalabilidade (Adição e Remoção de Nós)

A escalabilidade é realizada através da migração de slots, sem interrupção do serviço.

(1) Processo de Adição (Expansão)

Inicie um novo nó Redis configurado para modo cluster (cluster-enabled yes).
Adicione o novo nó ao cluster usando cluster meet <ip-do-novo-nó>:<porta-do-novo-nó>.
(Opcional, se o novo nó não for Mestre por padrão) Configure-o como mestre.
Migre slots: Use cluster reshard para mover slots de mestres existentes para o novo nó mestre.
Todos os nós atualizam seus mapas de slots.
(Opcional) Adicione escravos ao novo nó mestre para alta disponibilidade.

(2) Processo de Remoção (Redução)

Migre todos os slots do nó mestre a ser removido para outros mestres usando cluster reshard.
Após a migração, o nó não gerencia mais nenhum slot.
Reconfigure os escravos do nó a ser removido para que repliquem de outros mestres.
Remova o nó do cluster usando cluster forget <node-id-do-nó-a-remover>.
Pare o serviço Redis do nó removido.

A migração de slots ocorre gradualmente, garantindo a continuidade das operações.

3.4. Garantia de Consistência

O Redis Cluster oferece consistência eventual, não consistência forte.

Escritas são assíncronas para os escravos. Se um mestre falhar antes de replicar uma escrita, essa escrita pode ser perdida.
A consistência pode ser reforçada com as configurações min-replicas-to-write e min-replicas-max-lag, que exigem um número mínimo de réplicas sincronizadas para permitir escritas.

Configurações Essenciais do redis.conf

# Ativa o modo cluster (essencial)
cluster-enabled yes

# Arquivo de configuração do cluster (gerado automaticamente, armazena estado)
cluster-config-file nodes-6379.conf

# Tempo limite para detecção de falha de nó (ms), padrão 15000ms (15s)
cluster-node-timeout 15000

# Mínimo de réplicas ativas para permitir escrita no mestre (melhora consistência)
# Recomendado: 1
min-replicas-to-write 1

# Atraso máximo de replicação em ms. Se excedido, o escravo é considerado dessincronizado.
min-replicas-max-lag 10

# Escravos operam em modo somente leitura (padrão: yes)
slave-read-only yes

# Porta do barramento do cluster (geralmente porta_redis + 10000)
# cluster-port 16379 (auto-configurado)

# Permite redirecionamento de nós para mestres (gerenciamento de MOVED)
cluster-redirect-to-slave yes

Implantação Prática (3 Mestres, 3 Escravos - Linux)

Exemplo para Redis 6.2 em um único servidor Linux (pode ser adaptado para múltiplos servidores).

Preparação do Ambiente:

Servidor Linux (mínimo 4GB RAM recomendado).
Redis 6.2+ (suporta cluster).
Portas: 6379, 6380, 6381, 6382, 6383, 6384.

Passos de Implantação:

Crie diretórios para cada nó: mkdir -p /usr/local/redis/cluster/{6379..6384}
Copie redis.conf e ajuste as configurações para cada nó. Exemplos para 6379:

daemonize yes
port 6379
dir /usr/local/redis/cluster/6379
logfile /usr/local/redis/cluster/6379/redis.log
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 15000
# min-replicas-to-write 1
requirepass 123456  # Senha (opcional, mas recomendado)
masterauth 123456   # Senha para autenticação mestre-escravo

Ajuste port, dir, logfile, cluster-config-file para os outros nós.

Inicie os 6 nós Redis com seus respectivos arquivos de configuração.
Crie o cluster: Use redis-cli --cluster create (Redis 5.0+). Para 3 mestres e 1 escravo por mestre:

redis-cli -a 123456 --cluster create 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 --cluster-replicas 1

Verifique o status: Conecte-se a um nó (redis-cli -c -p 6379) e use cluster info e cluster nodes. O cluster_state deve ser ok.

Pontos de Atenção e Solução de Problemas

6.1. Pontos Críticos (Evitando Armadilhas)

Número Mínimo de Nós: Pelo menos 3 mestres e 1 escravo por mestre são necessários para o cluster operar corretamente.
Portas: Além das portas do Redis, as portas do barramento do cluster (porta + 10000) devem estar acessíveis entre os nós.
Senhas: requirepass e masterauth devem ser consistentes em todos os nós.
Slots Completos: Todos os 16384 slots devem ser atribuídos a algum mestre para o cluster funcionar.
Evitar "Brain Split": Configure cluster-node-timeout de forma razoável (15-30s) para evitar que partições de rede causem falhas falsas.
Escalonamento: Migre slots gradualmente e valide a distribuição e consistência após operações de adição/remoção.

6.2. Diagnóstico de Problemas Comuns

Cluster Status: FAIL: Verifique a alocação completa de slots, número de mestres e conectividade entre nós (portas do barramento).
Falha na Replicação: Cheque senhas (masterauth), status do mestre e configurações do escravo.
Cliente Não Conecta: Verifique portas do Redis e do barramento, modo de conexão do cliente (-c), senhas.
Falha no Failover: Confira se os escravos do mestre falho estão ativos, número suficiente de mestres e configuração do cluster-node-timeout.

Conclusão

O Redis Cluster é a solução robusta para escalabilidade e alta disponibilidade em larga escala. Sua arquitetura baseada em particionamento, replicação e failover automático o torna dispensável para cenários de alto volume e concorrência.

Pontos chave:

Os 16384 slots são a base do particionamento.
A replicação mestre-escravo integrada garante alta disponibilidade via failover automático.
O barramento do cluster é vital para comunicação, detecção de falhas e sincronização.
Escalonamento dinâmico é possível através da migração de slots.
Consistência eventual é o padrão, mas pode ser ajustada.

A escolha entre Redis Cluster e Mestre-Escravo + Sentinel depende da escala. Para dados massivos e necessidade de expansão, o Cluster é a escolha ideal. Para cenários menores com foco em alta disponibilidade, Mestre-Escravo + Sentinel pode ser suficiente.

Tags: Redis cluster Sharding Alta Disponibilidade replicação

Publicado em 10-3 01:34

Doido Dev