Diretório do artigo
Sumário
Existem dois tipos principais de clusters Redis nesse estágio: um é um cluster altamente disponível, o Redis Sentinel, uma arquitetura mestre-escravo, e cada instância contém dados completos. O outro é um cluster distribuído, Redis Cluster, arquitetura multimestre, os dados são distribuídos entre várias instâncias, cada instância é responsável pela leitura e gravação de dados. Hoje vamos dar uma olhada no processo de construção do Redis Sentinel.
Sentinela
Função
O sistema Redis 'Sentinel é usado para gerenciar vários servidores Redis. O sistema executa as três tarefas a seguir:
- Monitoramento (monitoramento ): O Sentinel verifica constantemente se o servidor mestre e o servidor escravo estão funcionando corretamente.
- Notificação : quando há um problema com um servidor Redis monitorado, o Sentinel pode enviar uma notificação ao administrador ou a outros aplicativos por meio da API.
- Failover automático (failover automático) : quando um servidor mestre não estiver funcionando corretamente, o Sentinel iniciará uma operação de failover automático, que atualizará um dos servidores mestre com falha do servidor escravo para o novo servidor mestre e permitirá que o servidor mestre com falha Outros servidores escravos são alterados para copiar o novo servidor mestre; quando o cliente tenta se conectar ao servidor mestre com falha, o cluster também retornará o endereço do novo servidor mestre ao cliente, para que o cluster possa usar o novo servidor mestre para substituir o servidor com falha.
Natureza
O Sentinel é um sistema distribuído, que foi projetado para ser executado em uma configuração em que vários processos do Sentinel trabalham juntos. As vantagens são as seguintes:
- Vários votos do Sentinel para determinar o failover automático do Mestre, reduzindo a taxa de falsos positivos;
- Se o sistema de failover for um ponto único, o sistema inteiro não poderá obter alta disponibilidade.
Conhecimento básico que você precisa conhecer antes da implantação
O arquivo de configuração deve ser usado ao executar o Sentinel ; caso contrário, o Sentinel se recusará a iniciar.
O Sentinels escutará as conexões na porta TCP 26379 por padrão . Portanto, para que o Sentinels funcione corretamente, a porta 26379 do servidor deve estar aberta para receber conexões dos endereços IP de outras instâncias do Sentinel. !!! Isso é muito importante !!!
-
Um sistema robusto requer pelo menos três instâncias do Sentinel.
-
Três instâncias do Sentinel devem ser colocadas em computadores ou máquinas virtuais separadas.
-
Como o Redis usa replicação assíncrona, a solução de alta disponibilidade do Sentinel + Redis. Para o conteúdo da replicação assíncrona, consulte a seção " Análise do processo de replicação do Redis ".
-
O cliente deve oferecer suporte ao Sentinel.
Meio ambiente
- CentOS 7
- Redis4.0.14
- Máquina virtual
Diagrama da arquitetura de implantação
O processo de implantação
O processo geral de implantação é primeiro implantar o cluster mestre-escravo na parte inferior da figura acima e depois implantar o cluster sentinela.
Implantar cluster mestre-escravo
Faça o download de redis no Master, Slave1 e Slave2 e armazene o caminho / usr / redis /
[root@localhost ~]wget -P /usr/redis/ http://download.redis.io/releases/redis-4.0.14.tar.gz
Descompacte os arquivos baixados separadamente e instale
[root@localhost ~]cd /usr/redis/
[root@localhost redis]gunzip redis-4.0.14.tar.gz
[root@localhost redis]tar -xvf redis-4.0.14.tar
[root@localhost redis]cd redis-4.0.14
[root@localhost redis-4.0.14]make install
Configure o arquivo redis.conf do Slave1 e Slave2, para que o Slave1 e o Slave2 possam copiar dados do Master. O princípio da replicação pode se referir à análise do processo de replicação do Redis . A seguir, é apresentada a configuração mínima necessária para o cluster mestre-escravo:
# slaveof <masterip> <masterport>
slaveof 192.168.33.160 6379
# masterauth <master-password>
masterauth 123456
#默认，推荐设置，slave设置只读
slave-read-only yes
#bind 127.0.0.1 允许其他机器访问
bind 0.0.0.0
#daemonize no 后台运行
daemonize yes
Start Master, Slave1, Slave2 respectivamente
[root@localhost redis-4.0.14]cd /src
[root@localhost src]./redis-server ../redis.conf
Conecte-se ao mestre e defina alguns valores para ver a sincronização
[root@localhost src]./redis-cli
127.0.0.1:6379>set key1 value1
"ok"
127.0.0.1:6379>quit
Conecte-se ao Slave1 e Slave2 e tente obter o valor da chave1
[root@localhost src]./redis-cli
127.0.0.1:6379>get key1
"value1"
127.0.0.1:6379>quit
Neste ponto, a sincronização mestre-escravo foi implantada, vamos descer para implantar o cluster sentinela.
Implantar cluster sentinela
O Sentinel está instalado na mesma máquina que o Redis e o relacionamento correspondente é o seguinte:
| Hospedeiro | Redis | Sentinela |
|---|---|---|
| [Host1] 192.168.33.4 | mestre | Sentinel1 |
| [Host2] 192.168.33.5 | Escravo1 | Sentinel2 |
| [Host3] 192.168.33.6 | Escravo2 | Sentinel3 |
Como o Sentinel já está incluído no Redis 2.8.0 e superior, podemos usar diretamente a implantação redis-4.0.14 que baixamos anteriormente.
Configure sentinel.conf nas máquinas correspondentes de Master, Slave1 e Slave2, respectivamente.O seguinte mostra a configuração mínima necessária para o cluster do sentinel:
sentinel monitor mymaster 192.168.33.4 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
#后台启动
daemonize yes
#记录日志
logfile "/usr/redis/redis-4.0.14/sentinel_log.log"
#允许其他机器访问,特别要保证sentinel集群之间的机器能够相互访问
bind 0.0.0.0
#关闭保护模块，方便测试
protected-mode no
Descrição:
- monitor : A configuração instrui o Sentinel a monitorar um servidor mestre chamado mymaster com um endereço IP 127.0.0.1 e um número de porta 6379. O servidor mestre determina que a falha requer pelo menos 2 consentimentos do Sentinel (independentemente de quantos consentimentos do Sentinel você definir para determinar que um servidor é inválido, Um Sentinel precisa do suporte da maioria dos Sentinel no sistema para iniciar uma migração automática de falhas.
- down-after-milliseconds : o número de milissegundos que o Sentinel acha que o servidor foi desconectado.
- paralelas-sincronizações : a opção especifica quantos servidores escravos podem sincronizar simultaneamente com o novo servidor mestre ao executar um failover.Quanto menor o número, mais tempo será necessário para concluir o failover.
Inicie o sentinela em Master, Slave1, Slave2, respectivamente
[root@localhost src]./redis-server ../sentinel.conf --sentinel
Nesse ponto, o cluster sentinela foi criado.
Teste
Teste o recurso de failover do cluster sentinel:
-
Feche o processo mestre, em que 7081 é o número do processo mestre:
[root@localhost ~]ps -ef | grep redis [root@localhost ~]kill -s 9 7081 -
Observe os logs da sentinela:
Descrição:- + mestre da sombra, indicando que o mestre está subjetivamente offline;
- + mestre próprio, indicando que o mestre está objetivamente offline;
- + switch-master, significa reeleger o mestre;
-
Agora o redis de 192.168.33.6 é eleito como Mestre, que é Slave2, agora tentamos operar no novo Masert (Slave2) para ver se ele pode ser sincronizado com o Slave1:
#进入新的Masert（Slave2） [[email protected] src]./redis-cli 127.0.0.1:6379>set key2 value2 "ok" -
Efetuamos login no 192.168.33.5 redis (Slave1) e verificamos se podemos obter o valor de key2:
#进入Slave1 [[email protected] src]./redis-cli 127.0.0.1:6379>get key2 "value2"Podemos ver claramente que podemos obter o valor recém-inserido do novo Masert (Slave2) no Slave1; portanto, o sentinel concluiu com êxito um failover.
Referência
