Introdução e construção do cluster sentinela Redis

Redis é um sistema de armazenamento de estrutura de dados na memória de código aberto que pode ser usado como banco de dados, cache e middleware de mensagens. No entanto, como um serviço de ponto único, o Redis pode causar indisponibilidade do serviço ao enfrentar falhas de hardware ou problemas de rede. Para resolver esse problema, o Redis fornece o modo sentinela, uma solução de alta disponibilidade.

Neste blog, nos aprofundaremos no padrão Sentinel do Redis. Apresentaremos primeiro os conceitos básicos do modo sentinela, incluindo nó mestre, nó escravo e nó sentinela. Em seguida, analisaremos detalhadamente os principais processos do modo Sentinela, incluindo offline subjetivo, offline objetivo, eleição de líder e failover.

Quer você seja um novato no Redis ou um desenvolvedor experiente, acredito que este blog pode ajudá-lo a entender e usar melhor o modo sentinela do Redis. vamos começar!

---

---

1. Introdução ao modo Redis Sentinel

1.1. Visão geral do modo Redis Sentinel

O modo sentinela do Redis é uma solução de alta disponibilidade fornecida pelo Redis. Ele monitora o status de execução do servidor mestre Redis e dos servidores escravos usando nós sentinela.Quando o servidor mestre falha, o sentinela pode promover automaticamente um servidor escravo para o novo servidor mestre para obter failover.

A seguir estão os principais recursos do modo Redis Sentinel:

1. Monitoramento: O Sentinel verificará regularmente se o servidor mestre e os servidores escravos estão funcionando normalmente, incluindo a verificação se eles podem responder normalmente às solicitações do cliente e se a replicação de dados entre os servidores mestre e escravos está normal.
2. Notificação: quando o Sentinel descobre que o servidor mestre falhou, ele pode enviar notificações ao administrador por meio da API.
3. Failover automático: quando o servidor mestre falhar, o Sentinel elegerá automaticamente um novo servidor mestre entre os servidores escravos e permitirá que outros servidores escravos comecem a replicar o novo servidor mestre.
4. Provedor de configuração: os clientes podem perguntar ao Sentinel qual servidor é o mestre atual. Dessa forma, mesmo que ocorra um failover, o cliente poderá encontrar o servidor primário correto.

1.2. Replicação mestre-escravo Redis e modo sentinela

O modo de replicação mestre-escravo é uma forma comum de melhorar a redundância de dados e o desempenho de leitura no Redis, mas também apresenta algumas deficiências:

1. Problema de ponto único de falha: No modo de replicação mestre-escravo, todas as operações de gravação são executadas no servidor mestre. Se o servidor mestre falhar, todo o serviço Redis não será capaz de processar solicitações de gravação.
2. Recuperação manual de falhas: quando o servidor mestre falha, você precisa promover manualmente um servidor escravo para o novo servidor mestre e modificar a configuração do aplicativo para apontar para o novo servidor mestre. Este processo pode demorar algum tempo e causar interrupção do serviço.
3. Problema de consistência de dados: Durante o processo de replicação de dados do servidor mestre para o servidor escravo, se ocorrer um problema de rede ou o servidor escravo falhar, os dados no servidor mestre e no servidor escravo podem ser inconsistentes.

O modo sentinela do Redis foi projetado para resolver estes problemas:

1. Failover automático: o modo Sentinel pode detectar automaticamente o status do servidor mestre. Quando o servidor mestre falhar, o sentinela elegerá automaticamente um novo servidor mestre a partir dos servidores escravos e permitirá que outros servidores escravos comecem a replicar o novo servidor mestre. Este processo é automático e não requer intervenção manual, o que pode reduzir o tempo de interrupção do serviço causado por falha do servidor principal;
2. Evite pontos únicos de falha: o modo Sentinel evita pontos únicos de falha por meio de failover automático. Mesmo se o servidor primário falhar, o serviço Redis ainda poderá continuar a processar solicitações de gravação;
3. Notificação: o Sentinel pode enviar os resultados do failover ao cliente;
4. Fornece função de descoberta de serviço: O Sentinel também fornece uma função de descoberta de serviço. O cliente pode perguntar ao Sentinel qual é o servidor mestre atual, para que mesmo se ocorrer um failover, o cliente possa encontrar o servidor mestre correto.

1.3. Principais funções do modo sentinela do Redis

No modo sentinela do Redis, existem três funções principais:

1. Mestre: O nó mestre é o principal provedor de serviços Redis. Ele lida com todas as operações de gravação e copia dados para nós escravos. Em circunstâncias normais, todas as operações de leitura e gravação são realizadas pelo nó mestre;
2. Escravo: O nó escravo é o backup do nó mestre. Ele copia os dados do nó mestre e pode lidar com operações de leitura. Quando o nó mestre falha, o nó escravo pode ser promovido ao novo nó mestre;
3. Nó sentinela (Sentinel): O nó sentinela é a chave para a alta disponibilidade do Redis. Ele monitora o status de execução do nó mestre e dos nós escravos. Quando o nó mestre falha, o nó sentinela fará failover, elegerá um novo nó mestre e reconfigurará o nó escravo.

No modo sentinela, pode haver vários nós mestres, nós escravos e nós sentinela para formar um serviço Redis distribuído e altamente disponível.

---

2. Princípio do modo sentinela Redis

O modo Sentinel usa nós sentinela para concluir o monitoramento, off-line e failover de nós de dados.

2.1. Monitoramento de tempo do modo sentinela do Redis

O nó sentinela verificará regularmente o status de execução do servidor mestre e de todos os servidores escravos, incluindo se estão online, se podem responder às solicitações normalmente, se a replicação de dados mestre-escravo está normal, etc.

A seguir estão as principais etapas para monitoramento programado em modo sentinela:

1. A cada 1 segundo (padrão), cada nó Sentinel envia um comando PING para o nó mestre, nós escravos e nós Sentinel restantes para verificar se estão online. Se o servidor responder ao comando PING normalmente, o nó sentinela considera o servidor online. Se o servidor não responder ou retornar um erro, o nó sentinela pensa que o servidor pode ter falhado;
2. A cada (padrão) 2 segundos, cada nó Sentinel enviará uma mensagem para __sentinel__:helloo canal do nó de dados Redis.Esta mensagem contém o julgamento do nó Sentinel sobre o nó mestre e as informações do nó Sentinel atual;
3. A cada (padrão) 10 segundos, cada nó Sentinel enviará periodicamente (o padrão é a cada 10 segundos) comandos INFO para o nó mestre e todos os nós escravos para obter a topologia mais recente e outras informações. O comando INFO pode retornar várias informações e estatísticas do servidor Redis, incluindo informações gerais do servidor (como versão do Redis, tempo de inicialização, sistema operacional, etc.), informações de conexão do cliente, uso de memória, status de persistência de dados, mestre-escravo Informações copiadas, etc.

2.2. Modo Redis Sentinel - download subjetivo e objetivo

No modo sentinela do Redis, "offline subjetivo" e "offline objetivo" são dois conceitos importantes e são a base para o nó Sentinel determinar se o servidor principal falhou.

Desativação subjetiva: cada nó do Sentinel enviará periodicamente (o padrão é a cada 1 segundo) comandos PING para o nó mestre, nós escravos e outros nós do Sentinel para detecção de pulsação. Caso um nó down-after-millisecondsnão responda efetivamente dentro do tempo definido pelos parâmetros, o nó Sentinel determinará a falha do nó. Este comportamento é chamado de offline subjetivo.

O off-line subjetivo é baseado no julgamento da própria perspectiva do nó Sentinel, significa apenas que o nó Sentinel não pode se comunicar normalmente com o nó detectado, o que pode ser devido a problemas de rede ou a uma falha real do nó detectado.

Objetivo inativo: quando um número suficiente de nós Sentinel acredita que o servidor principal está off-line, o servidor principal é considerado objetivamente off-line. Este é o consenso da maioria dos nós Sentinela e é mais confiável.

No modo sentinela do Redis, quando um nó Sentinel determina subjetivamente que o nó mestre está offline, ele solicitará sentinel is-master-down-by-addra outros nós Sentinel seu julgamento sobre o nó mestre por meio de comandos. Se a resposta recebida indicar que o número de nós Sentinel que acham que o nó mestre está offline atinge quorumo valor definido pelo parâmetro, então o nó Sentinel pensará que realmente há um problema com o nó mestre e tomará uma decisão objetiva de ficar offline .

No modo Sentinel, o processo de failover será acionado somente quando o servidor primário for considerado objetivamente offline. Isso evita falsos positivos devido a problemas de rede ou erros de julgamento de nós Sentinel individuais. Somente quando a maioria dos nós do Sentinel acreditarem que o servidor principal está offline, isso será considerado uma falha real e o failover será necessário.

2.4. Eleição do nó do modo Redis Sentinel

No modo sentinela do Redis, quando o nó mestre é considerado objetivamente offline, o nó sentinela conduzirá uma eleição de líder e selecionará um nó sentinela líder para ser responsável pelo processo de failover. A seguir estão as etapas detalhadas para a eleição do nó Sentinela líder:

1. Iniciar eleição: quando um nó Sentinela determina que o nó mestre está objetivamente offline, ele iniciará um novo processo de eleição de líder. Primeiro, ele incrementa sua época de configuração (um número incremental global) e depois envia uma mensagem solicitando uma votação para outros nós Sentinel;
2. Votação: Quando um nó Sentinel recebe uma mensagem solicitando votação, se a época de configuração na solicitação for maior que sua própria época de configuração, ele atualizará sua própria época de configuração e enviará uma mensagem de votação ao nó Sentinel solicitando votação. Cada nó Sentinel só pode votar uma vez em um período de configuração;
3. Votação estatística: O nó Sentinela que solicita votação contará as mensagens de votação recebidas. Se receber votos da maioria dos nós Sentinela dentro do tempo especificado (o padrão é 2 segundos), será eleito líder;
4. Iniciar failover: O nó Sentinel líder iniciará o processo de failover, incluindo a eleição de um novo nó mestre, reconfiguração de nós escravos, etc.

Através deste processo, o sistema Sentinel pode eleger rapidamente um líder para failover após a falha do nó mestre, garantindo a alta disponibilidade do serviço Redis.

2.5. Failover do modo Redis Sentinel

No modo sentinela do Redis, quando o nó mestre é considerado objetivamente offline, o nó sentinela fará failover, elegerá um novo nó mestre e reconfigurará o nó escravo. Aqui estão as etapas detalhadas para failover:

1. Eleger um novo nó mestre: Primeiro, o nó Sentinela líder elegerá um novo nó mestre dentre todos os nós escravos. O princípio da eleição é dar prioridade ao nó escravo com os dados mais recentes (o maior deslocamento de replicação) e a prioridade mais alta.
2. Envie o comando SLAVEOF NO ONE: O nó Sentinela líder enviará o comando ao nó mestre recém-eleito SLAVEOF NO ONEpara torná-lo o novo nó mestre.
3. SLAVEOFReconfigure o nó escravo: O nó Sentinela líder enviará comandos aos outros nós escravos para torná-los nós escravos do novo nó mestre.
4. Atualizar metadados: Finalmente, todos os nós Sentinel atualizarão seus próprios metadados, incluindo o endereço do nó mestre, relacionamento mestre-escravo, etc.
5. Notificar clientes: todos os nós do Sentinel enviarão +switch-mastermensagens aos clientes que assinaram o evento, notificando-os de que o nó primário foi trocado.

Por meio desse processo, o sistema Sentinel pode concluir rapidamente o failover após a falha do nó mestre, garantindo a alta disponibilidade do serviço Redis.

---

3. Implementação de replicação mestre-escravo Redis

3.1. Extraia a imagem Redis

Extraia a imagem do Redis:

docker pull redis

3.3. Crie as pastas necessárias

Crie as pastas necessárias para mapear os caminhos de arquivo correspondentes do contêiner:

mkdir -p ~/data/redis/master/data                                  
touch ~/data/redis/master/redis.confmkdir                       
touch ~/data/redis/master/redis.conf 
mkdir -p ~/data/redis/slave-1/data       
touch ~/data/redis/slave-1/redis.confmkdir
touch ~/data/redis/slave-1/redis.conf
mkdir -p ~/data/redis/slave-2/data       
touch ~/data/redis/slave-2/redis.confmkdir
touch ~/data/redis/slave-2/redis.conf 
mkdir -p ~/data/redis/slave-3/data       
touch ~/data/redis/slave-3/redis.confmkdir
touch ~/data/redis/slave-3/redis.conf 
# sentinel.conf 文件一个就够
touch ~/data/redis/master/sentinel.conf   			

3.3. Modifique redis.conf

Modifique o arquivo redis.conf do nó mestre

bind 0.0.0.0
# 开启保护模式，限制为本地访问，默认yes
protected-mode no 
# 默认no，改为yes意为以守护进程方式启动，可后台运行，除非kill进程，改为yes会使配置文件方式启动redis失败
daemonize no
# redis持久化（可选）
appendonly yes 

Modifique o arquivo redis.conf do nó escravo

bind 0.0.0.0
# 开启保护模式，限制为本地访问，默认yes
protected-mode no 
# 默认no，改为yes意为以守护进程方式启动，可后台运行，除非kill进程，改为yes会使配置文件方式启动redis失败
daemonize no
# redis持久化（可选）
appendonly yes 
# 指向master节点
replicaof 172.17.0.2 6379

3.4. Modifique sentinel.conf

Modifique o arquivo sentinel.conf

daemonize yes
sentinel monitor mymaster 172.17.0.2 6379 2
port 26379

4.5. Execute o contêiner

Execute o contêiner e especifique o caminho de montagem:

docker run -p 16379:6379 -p 16389:26379 --name redis-master -v ~/data/redis/master/data/:/data -v ~/data/redis/master/sentinel.conf:/etc/redis/sentinel.conf -v ~/data/redis/master/redis.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf --appendonly yes
---
docker run -p 26379:6379  -p 16390:26379 --name redis-slave-1 -v ~/data/redis/slave-1/data/:/data -v ~/data/redis/slave-1/sentinel.conf:/etc/redis/sentinel.conf -v ~/data/redis/slave-1/redis.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf --appendonly yes
---
docker run  -p 36379:6379  -p 16391:26379 --name redis-slave-2 -v ~/data/redis/slave-2/data/:/data -v ~/data/redis/slave-2/sentinel.conf:/etc/redis/sentinel.conf  -v ~/data/redis/slave-2/redis.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf --appendonly yes
---
docker run  -p 46379:6379  -p 16392:26379 --name redis-slave-3 -v ~/data/redis/slave-3/data/:/data -v ~/data/redis/slave-3/sentinel.conf:/etc/redis/sentinel.conf  -v ~/data/redis/slave-3/redis.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf --appendonly yes

Visualizar via Docker Desktop:

4.6. Visualizar informações do nó mestre-escravo

Visualize informações do nó mestre-escravo:

# 进入从节点服务
docker exec -it [CONTAINER ID] redis-cli
# 查看角色信息
127.0.0.1:6379> role
# 查看主从复制信息
127.0.0.1:6379> info replication

Nó mestre:

Do nó: