Compartilhamento de tecnologia

Check-in de aprendizagem de 7.11 dias —— Redis de aprendizagem para iniciantes (6)

2024-07-12

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Check-in de estudo de 7,11 dias

Insira a descrição da imagem aqui

1. Transação Redis

O conceito de transações e propriedades ACID

Insira a descrição da imagem aqui
Transações em nível de banco de dados

No nível do banco de dados, uma transação é um conjunto de operações que são executadas com sucesso ou nenhuma delas é executada.

Quatro características principais das transações de banco de dados

  • R: Atômico, atomicidade, executa todos os SQL como unidades de trabalho atômicas, ou todos são executados ou nenhum deles é executado;
  • C: Consistente, após a conclusão da transação, o status de todos os dados é consistente, ou seja, enquanto 100 forem subtraídos da conta A, 100 serão adicionados à conta B;
  • I: Isolamento, se múltiplas transações forem executadas simultaneamente, as modificações feitas por cada transação devem ser isoladas das demais transações;
  • D: Duração, persistência, ou seja, após a conclusão da transação, as modificações nos dados do banco de dados são armazenadas de forma persistente.

Transação Redis

Uma transação Redis é um conjunto de comandos. Todos os comandos em uma transação serão serializados e uma série de comandos será executada de maneira única, sequencial e exclusiva.

Insira a descrição da imagem aqui

Três características principais das transações Redis

  • operações de quarentena separadas : Todos os comandos na transação serão serializados e executados em ordem. Durante a execução da transação, esta não será interrompida por solicitações de comandos enviadas por outros clientes;
  • Nenhum conceito de nível de isolamento: Os comandos na fila não serão realmente executados até que sejam enviados, porque nenhuma instrução será realmente executada antes do envio da transação, portanto, não há "consulta dentro da transação para ver as atualizações na transação e consulta fora do transação"Não consigo ver".
  • Nenhuma garantia de atomicidade: Se um comando não for executado na mesma transação redis, os comandos subsequentes ainda serão executados sem reversão;

Três estágios de execução de transação Redis

Insira a descrição da imagem aqui

  • ligar:porMULTIInicie uma transação;
  • Junte-se à equipe: Enfileira vários comandos em uma transação. Esses comandos não serão executados imediatamente após recebê-los, mas serão colocados na fila de transações aguardando a execução;
  • implemento:Depende deEXECO comando aciona a transação;

Operações básicas de transações Redis

Insira a descrição da imagem aqui
Multi、Exec、descartar

entrada de transação deMultiQuando o comando for iniciado, os comandos inseridos serão colocados na fila do buffer de comando um por um e não serão executados até que oExec Posteriormente, o Redis executará os comandos da fila de buffer de comando anterior em sequência.Durante o processo de formação da equipe, você pode passardiscardVenha desistir do time.

exemplo

127.0.0.1:6379> set t1 1
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set id 12
QUEUED
127.0.0.1:6379(TX)> get id
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> get t1
QUEUED
127.0.0.1:6379(TX)> EXEC
1) OK
2) "12"
3) (integer) 2
4) (integer) 3
5) "3"
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20

abandonar transação

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set name z3
QUEUED
127.0.0.1:6379(TX)> set age 29
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> DISCARD
OK
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

Todos sentados juntos

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set name z3
QUEUED
127.0.0.1:6379(TX)> get name
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> get t1
QUEUED
127.0.0.1:6379(TX)> set email
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379(TX)> exec
(error) EXECABORT Transaction discarded because of previous errors.
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

Perceber
O conjunto de comandos contém instruções incorretas (observe que são erros de sintaxe. Eles estão todos conectados e falham).

Toda injustiça tem seu dono, toda dívida tem seu dono

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set age 11
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> set email [email protected]
QUEUED
127.0.0.1:6379(TX)> incr email
QUEUED
127.0.0.1:6379(TX)> get age
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) (integer) 5
3) OK
4) (error) ERR value is not an integer or out of range
5) "11"
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18

Perceber
Para erros de tempo de execução, ou seja, erros não gramaticais, os comandos corretos serão executados e os comandos incorretos retornarão um erro.

2. cluster redis

replicação mestre-escravo

Insira a descrição da imagem aqui
Visão geral
Entre as empresas existentes, 80% das empresas usam principalmente o serviço autônomo do Redis. Em cenários reais, o Redis em um único nó está sujeito a riscos.

enfrentando problemas:

  • mau funcionamento da máquina. Implantamos em um servidor Redis. Quando ocorre uma falha na máquina, precisamos migrar para outro servidor e garantir que os dados estejam sincronizados.
  • Gargalo de capacidade. Quando precisarmos expandir a memória Redis, de 16G para 64G, uma única máquina definitivamente não será capaz de satisfazê-la. Claro, você pode comprar uma nova máquina 128G.

Solução

Para obter maior capacidade de armazenamento do banco de dados distribuído e suportar alto acesso simultâneo, armazenaremos os dados do banco de dados centralizado original em vários outros nós da rede.

Perceber
Para resolver este problema de um único nó, o Redis também implantará várias cópias de dados em outros nós para replicação, a fim de obter alta disponibilidade do Redis e backup redundante de dados para garantir a alta disponibilidade de dados e serviços.

O que é replicação mestre-escravo

A replicação mestre-escravo refere-se à cópia de dados de um servidor Redis para outros servidores Redis. O primeiro é chamado de nó mestre e o último é chamado de nó escravo. A replicação de dados é unilateral e só pode ser do nó mestre para o nó escravo.

Insira a descrição da imagem aqui
O papel da replicação mestre-escravo

  • Redundância de dados: A replicação mestre-escravo implementa backup dinâmico de dados, que é um método de redundância de dados além da persistência.
  • Recuperação: Quando ocorre um problema no nó mestre, o nó escravo pode fornecer serviços para obter recuperação rápida de falhas; na verdade, é um tipo de redundância de serviço;
  • balanceamento de carga: Com base na replicação mestre-escravo, com a separação de leitura e gravação, o nó mestre pode fornecer serviços de gravação e os nós escravos podem fornecer serviços de leitura (ou seja, ao escrever dados Redis, o aplicativo deve se conectar ao nó mestre , e ao ler dados Redis, o aplicativo deve se conectar ao nó escravo), compartilhando a carga do servidor, especialmente em cenários onde há menos gravação e mais leitura, compartilhar a carga de leitura por meio de vários nós escravos pode aumentar muito a simultaneidade do servidor Redis; .
  • Pedra angular de alta disponibilidade: Além das funções acima, a replicação mestre-escravo também é a base para a implementação de sentinelas e clusters. Portanto, a replicação mestre-escravo é a base para a alta disponibilidade do Redis.

Configuração do ambiente de replicação mestre-escravo

Insira a descrição da imagem aqui
Gravar arquivo de configuração
Crie novo redis6379.conf

include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb
  • 1
  • 2
  • 3
  • 4

Crie novo redis6380.conf

include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb
  • 1
  • 2
  • 3
  • 4

Crie novo redis6381.conf

include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6381.pid
port 6381
dbfilename dump6381.rdb
  • 1
  • 2
  • 3
  • 4

Inicie três servidores redis

./redis-server ../redis6379.conf
./redis-server ../redis6380.conf
./redis-server ../redis6381.conf
  • 1
  • 2
  • 3

Ver processos do sistema

[root@localhost src]# ps -ef |grep redis
root    40737    1  0 22:05 ?     00:00:00 ./redis-server *:6379
root    40743    1  0 22:05 ?     00:00:00 ./redis-server *:6380
root    40750    1  0 22:05 ?     00:00:00 ./redis-server *:6381
root    40758  40631  0 22:05 pts/0   00:00:00 grep --color=auto redis
  • 1
  • 2
  • 3
  • 4
  • 5

Verifique o status de execução de três hosts

#打印主从复制的相关信息
./redis-cli -p 6379
./redis-cli -p 6380
./redis-cli -p 6381
127.0.0.1:6379> info replication
127.0.0.1:6380> info replication
127.0.0.1:6381> info replication
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

Equipado com banco de dados escravo, mas não com banco de dados mestre

Formato de sintaxe:

slaveof  <ip> <port>
  • 1

Exemplo:

Executado em 6380 e 6381.

127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
  • 1
  • 2

Escreva no host e leia os dados no escravo

set k1 v1
  • 1

Análise do princípio da replicação mestre-escravo

Insira a descrição da imagem aqui
A replicação mestre-escravo pode ser dividida em 3 estágios

  • Fase de estabelecimento de conexão (ou seja, fase de preparação)
  • Fase de sincronização de dados
  • estágio de propagação de comando

O processo de cópia é dividido aproximadamente em 6 processos

Insira a descrição da imagem aqui

  1. Salve as informações do nó mestre (mestre).
    Ver informações de status após executar slaveof
info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  1. O nó escravo (escravo) mantém a lógica relacionada à replicação por meio de tarefas agendadas que são executadas a cada segundo. Quando a tarefa agendada descobre que há um novo nó mestre, ela tentará estabelecer uma conexão de rede com o nó.
    Insira a descrição da imagem aqui
  2. Estabeleça uma conexão de rede entre o nó escravo e o nó mestre
    O nó escravo estabelecerá um soquete. O nó escravo estabelecerá um soquete com a porta 51234, que é usada especificamente para aceitar comandos de replicação enviados pelo nó mestre.

Insira a descrição da imagem aqui
4. Envie o comando ping

Após a conexão ser estabelecida com sucesso, o nó escravo envia uma solicitação de ping para a primeira comunicação.

Insira a descrição da imagem aqui

efeito:

  • Detecte se o soquete de rede entre mestre e escravo está disponível.
  • Detecte se o nó mestre pode atualmente aceitar comandos
  1. TEA.
    Se o parâmetro requirepass estiver definido no nó mestre, a verificação da senha será necessária. O nó escravo deve configurar o parâmetro masterauth para garantir que a senha seja a mesma do nó mestre para passar na verificação, se a verificação falhar, a replicação será; será encerrado e o nó escravo reiniciará o processo de replicação.

  2. Sincronize conjuntos de dados.
    Depois que a conexão de replicação mestre-escravo se comunicar normalmente, quando a replicação for estabelecida pela primeira vez, o nó mestre enviará todos os dados que contém para o nó escravo. Esta parte da operação é a etapa mais longa.
    Insira a descrição da imagem aqui

Estratégia de sincronização mestre-escravo

Quando o mestre e o escravo estão apenas conectados, a sincronização completa é executada; após a conclusão da sincronização completa, a sincronização incremental é executada; É claro que, se necessário, o escravo pode iniciar a sincronização completa a qualquer momento. A estratégia redis é que, não importa o que aconteça, a sincronização incremental será tentada primeiro e, se não tiver êxito, a máquina escrava será obrigada a realizar a sincronização completa.

Por exemplo

salvar um cache

set name jjy
  • 1

O comando de gravação é

$3 r n
set r n
$4 r n
name r n
$5  r n
jjy r n
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
Desvio100010011002100310041005100610071008
Valor do byte$3re$4eaeu

7. O comando é copiado continuamente.
Quando o nó mestre sincroniza os dados atuais com o nó escravo, o processo de estabelecimento da replicação é concluído. Em seguida, o nó mestre enviará continuamente comandos de gravação aos nós escravos para garantir a consistência dos dados mestre-escravo.

Monitoramento sentinela

Insira a descrição da imagem aqui
Desvantagens da replicação mestre-escravo do Redis

Quando o host Master fica inativo, precisamos resolver a mudança manualmente.

Insira a descrição da imagem aqui

Problemas de exposição:
Depois que o nó mestre ficar inativo e o serviço de gravação não puder ser usado, será necessário alternar manualmente, selecionar novamente o nó mestre e definir manualmente o relacionamento mestre-escravo.

Tecnologia de comutação mestre-escravo

Quando o servidor mestre fica inativo, um servidor escravo precisa ser alternado manualmente para o servidor mestre, o que requer intervenção manual, é demorado e trabalhoso e também fará com que o serviço fique indisponível por um período de tempo.Esta não é uma abordagem recomendada, mais frequentemente damos prioridade aModo sentinela

Visão geral do Sentinela

O modo Sentinel é um modo especial. Primeiro, o Redis fornece comandos Sentinel como um processo independente. O princípio é que o sentinela monitora várias instâncias do Redis em execução, enviando comandos e aguardando a resposta do servidor Redis.

Insira a descrição da imagem aqui
Papel sentinela

  • Monitoramento de cluster: Responsável por monitorar se os processos redis master e slave estão funcionando corretamente
  • notificação: se uma instância do Redis falhar, o sentinela será responsável por enviar mensagens como notificações de alarme ao administrador.
  • failover: Se o nó mestre desligar, ele será automaticamente transferido para o nó escravo.
  • Centro de configuração: Se ocorrer failover, notifique o cliente sobre o novo endereço mestre

Construção do ambiente de monitoramento sentinela

Insira a descrição da imagem aqui

Crie um novo arquivo sentinel-26379.conf

#端口
port 26379
#守护进程运行
daemonize yes
#日志文件
logfile "26379.log"
sentinel monitor mymaster localhost 6379 2
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

parâmetro:
monitor sentinela mymaster 192.168.92.128 6379 2 O significado da configuração é: o nó sentinela monitora o nó mestre 192.168.92.128:6379 O nome do nó mestre é mymaster. o nó mestre: pelo menos 2 são necessários Somente quando dois nós sentinela concordam a falha do nó mestre pode ser determinada e o failover executado.

Crie um novo arquivo sentinel-26380.conf

#端口
port 26380
#守护进程运行
daemonize yes
#日志文件
logfile "26380.log"
sentinel monitor mymaster localhost 6379 2
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

Crie um novo arquivo sentinel-26381.conf

#端口
port 26381
#守护进程运行
daemonize yes
#日志文件
logfile "26381.log"
sentinel monitor mymaster localhost 6379 2
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

Iniciando o nó sentinela

redis-sentinel sentinel-26379.conf
  • 1

Ver o status do nó sentinela

[root@localhost src]# ./redis-cli -p 26379
127.0.0.1:26379> 
127.0.0.1:26379> 
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.66.100:6379,slaves=2,sentinels=3
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11

Análise do princípio de funcionamento do Sentinel

Insira a descrição da imagem aqui
fase de monitoramento
Insira a descrição da imagem aqui

Perceber:

  • sentinela (sentinela 1)-----&gt;Inicie informações para o mestre (mestre) e escravo (escravo) e obtenha as informações completas.
  • sentinela (sentinela 2) -----&gt;Inicie informações para o mestre (mestre), você saberá as informações da sentinela existente (sentinela 1) e se conectará ao escravo (escravo).
  • sentinela (sentinela 2)-----&gt;Inicie uma assinatura para sentinela (sentinela 1).

Estágio de notificação

O Sentinel envia continuamente notificações ao mestre e ao escravo para coletar informações.

fase de failover

Na fase de notificação, caso a notificação enviada pelo sentinela não receba resposta do mestre, ele marcará o mestre como SRI_S_DOWN e enviará o status do mestre para cada sentinela. Quando outros sentinelas souberem que o mestre morreu, eles dizem. Não acredito. Também irei verificar e enviar. Os resultados são compartilhados com cada sentinela. Quando metade dos sentinelas achar que o mestre está inativo, eles marcarão o mestre como SRI_0_DOWN.
Insira a descrição da imagem aqui
Aí vem a pergunta:

Neste momento, o mestre deverá ser substituído. Quem será o mestre?

Como votar

Caminho:

O sentinela que receber primeiro o aviso eleitoral votará a favor.

Elimine alguns casos:

  • Não ON-line
  • Resposta lenta
  • Desconectado do master original por muito tempo
  • princípio de prioridade

failover

Insira a descrição da imagem aqui
Visão geral
Demonstra os recursos de monitoramento e failover automático do Sentinel quando o nó mestre falha.

Demonstrar failover
Use o comando kill para eliminar o nó mestre

ps aux |grep redis
kill -9 pid
  • 1
  • 2

Ver informações do nó sentinela

Se você usar imediatamente o comando info Sentinel no nó sentinela para visualizá-lo.

[root@localhost src]# ./redis-cli -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6381,slaves=5,sentinels=3
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9

Perceber
Você descobrirá que o nó mestre não foi trocado, porque levará algum tempo para o sentinela detectar a falha do nó mestre e transferi-lo.

Reinicie o nó 6379

[root@localhost src]# ./redis-cli info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:down
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

Os arquivos de configuração serão reescritos
Durante a fase de failover, os arquivos de configuração dos nós sentinela e mestre-escravo serão reescritos.

include /usr/local/redis/redis.conf
pidfile "/var/run/redis_6379.pid"
port 6379
dbfilename "dump6379.rdb"
# Generated by CONFIG REWRITE
daemonize yes
protected-mode no
appendonly yes
slowlog-max-len 1200
slowlog-log-slower-than 1000
save 5 1
user default on nopass ~* &* +@all
dir "/usr/local/redis"
replicaof 127.0.0.1 6381
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

para concluir

  • Os nós mestre-escravo no sistema Sentinel não são diferentes dos nós mestre-escravo comuns. A descoberta e transferência de falhas são controladas e concluídas pelo Sentinel.
  • Os nós sentinela são essencialmente nós redis.
  • Cada nó sentinela só precisa configurar o nó mestre de monitoramento para descobrir automaticamente outros nós sentinela e nós escravos.
  • Durante as fases de inicialização e failover do nó sentinela, os arquivos de configuração de cada nó serão reescritos (config rewrite).

Modo cluster

Redis tem três modos de cluster

  • modo mestre-escravo
  • Modo sentinela
  • Modo cluster

Desvantagens do Modo Sentinela
Insira a descrição da imagem aqui
deficiência

  • Quando o master desligar, o sentinela elegerá um master Durante a eleição, não haverá como acessar o Redis e haverá uma interrupção temporária no acesso;
  • No modo sentinela, apenas o nó mestre pode ser escrito externamente e o nó escravo só pode ser usado para leitura. Embora um único nó Redis suporte até 10W QPS, durante promoções de comércio eletrônico, toda a pressão de gravação de dados recai sobre o mestre.
  • A memória de nó único do Redis não pode ser definida como muito grande. Se os dados forem muito grandes, a sincronização mestre-escravo será muito lenta quando o nó for iniciado, levará muito tempo;

Visão geral do modo cluster
Insira a descrição da imagem aqui
O cluster Redis é um cluster de serviço distribuído composto por vários grupos de nós mestre-escravos. Possui replicação, alta disponibilidade e recursos de fragmentação.

Vantagens do cluster Redis

  • O cluster Redis possui vários mestres, o que pode reduzir o impacto de problemas de acesso transitórios.
  • O cluster Redis possui vários mestres, o que pode fornecer maior simultaneidade
  • O cluster Redis pode ser armazenado em fragmentos para que mais dados possam ser armazenados

Construção do modo cluster

A construção do cluster Redis requer pelo menos 3 nós mestres. Construímos 3 nós mestres aqui, cada um com um nó escravo, para um total de 6 nós Redis;
Insira a descrição da imagem aqui
Construção de cluster

Crie 6 nós Redis diferentes com números de porta 6379, 6380, 6381, 6382, 6383 e 6384, respectivamente.

Perceber: Os arquivos dump.rdb e appendonly.aof devem ser excluídos antes da cópia.

1. Crie um novo arquivo de configuração
Crie os arquivos redis6379.config, redis6380.config, redis6381.config, redis6382.config, redis6383.config, redis6384.config Modifique o número da porta no arquivo de configuração para que corresponda ao número da porta do arquivo.

daemonize yes
dir /usr/local/redis-7.2.4/redis-cluster/6382/
bind 192.168.47.100
port 6382
dbfilename dump6382.rdb
cluster-enabled yes
cluster-config-file nodes-6382.conf
cluster-node-timeout 5000
appendonly yes
protected-mode no
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

parâmetro

  • cluster-config-file: O arquivo de configuração de persistência do cluster, que contém o status de outros nós, variáveis ​​de persistência, etc., será gerado automaticamente no diretório dir configurado acima. Cada nó manterá um arquivo de configuração do cluster durante a operação sempre que as informações do cluster forem alteradas (como adicionar ou remover nós), todos os nós do cluster atualizarão as informações mais recentes para o arquivo de configuração quando o nó for reiniciado; o arquivo de configuração para obter informações do cluster e você poderá reingressar facilmente no cluster. O arquivo de configuração do cluster é mantido pelo Redis e não requer modificação manual.
  • habilitado para cluster: habilita o cluster

Criar pasta

mkdir -p /usr/local/redis-7.2.4/redis-cluster/6379/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6380/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6381/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6382/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6383/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6384/
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

Inicie seis nós

[root@bogon src]# ./redis-server ../redis6379.config
[root@bogon src]# ./redis-server ../redis6380.config
[root@bogon src]# ./redis-server ../redis6381.config
[root@bogon src]# ./redis-server ../redis6382.config
[root@bogon src]# ./redis-server ../redis6383.config
[root@bogon src]# ./redis-server ../redis6384.config
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

Verifique se cada nó inicia com sucesso

[root@bogon src]# ps -ef | grep redis
root    3889    1 0 09:56 ?    00:00:03 ./redis-server 0.0.0.0:6379 [cluster]
root    3895    1 0 09:56 ?    00:00:03 ./redis-server 0.0.0.0:6380 [cluster]
root    3901    1 0 09:57 ?    00:00:03 ./redis-server 0.0.0.0:6381 [cluster]
root    3907    1 0 09:57 ?    00:00:02 ./redis-server *:6382 [cluster]
root    3913    1 0 09:57 ?    00:00:02 ./redis-server 0.0.0.0:6383 [cluster]
root    3919    1 0 09:57 ?    00:00:02 ./redis-server 0.0.0.0:6384 [cluster]
root    4247  2418 0 10:22 pts/0  00:00:00 grep --color=auto redis
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

Configurar o cluster

Formato do comando: --cluster-replicas 1 significa criar um nó escravo para cada mestre

Perceber: O IP aqui é o IP real da máquina onde cada nó está localizado.

[root@localhost src]# ./redis-cli --cluster create 192.168.47.100:6379 192.168.47.100:6380 192.168.47.100:6381 192.168.47.100:6382 192.168.47.100:6383 192.168.47.100:6384 --cluster-replicas 1
  • 1

Insira a descrição da imagem aqui

Verifique o cluster

Conecte-se a qualquer cliente

./redis-cli -h 192.168.47.100  -p 6379 -c
  • 1

parâmetro:

‐h: endereço do host
-p: número da porta
‐c: indica modo cluster

Teste de escrita de dados

[root@bogon src]# ./redis-cli -p 6379 -c
127.0.0.1:6379> set name zhangsan
-> Redirected to slot [5798] located at 192.168.47.100:6380
OK
192.168.47.100:6380> get name
"zhangsan"
192.168.47.100:6380>
[root@bogon src]# ./redis-cli -p 6383 -c
127.0.0.1:6383> get name
-> Redirected to slot [5798] located at 192.168.47.100:6380
"zhangsan"
192.168.47.100:6380>
[root@bogon src]# ./redis-cli -p 6383 -c
127.0.0.1:6383> readonly
OK
127.0.0.1:6383> get name
"zhangsan"
127.0.0.1:6383>
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18

Análise do Princípio do Padrão de Cluster

Cluster Redis Todos os dados são divididos em 16384 slots (slots), e cada nó é responsável por uma parte dos slots. As informações do slot são armazenadas em cada nó. Somente o nó mestre receberá slots e o nó escravo não receberá slots.

Insira a descrição da imagem aqui

Algoritmo de posicionamento de slot: k1 = 127001

Por padrão, o Cluster usará o algoritmo crc16 para fazer hash do valor da chave para obter um valor inteiro e, em seguida, usará esse valor inteiro para o módulo 16384 para obter o slot específico.

HASH_SLOT = CRC16(chave) % 16384

Recuperação
Ver nós

192.168.66.103:8001> cluster nodes
  • 1

Mate o nó mestre

lsof -i:8001
kill -9 pid
  • 1
  • 2

Observe as informações do nó

Insira a descrição da imagem aqui

Cluster Redis operacional Java

Insira a descrição da imagem aqui
Modificar arquivo de configuração

spring.data.redis.cluster.nodes=192.168.47.100:6381,192.168.47.100:6383,192.168.47.100:6380
  • 1

Perceber
1. O cluster Redis requer pelo menos três nós para garantir alta disponibilidade.
2. Você deve tentar evitar adicionar ou excluir nós enquanto o cluster Redis estiver em execução, pois isso pode causar migração de dados e, portanto, afetar o desempenho geral do cluster Redis.

Código escrito em Java

@SpringBootTest
public class CluseterTest {

  @Autowired
  private RedisTemplate<String,Object> redisTemplate;

  @Test
  void string() {
    //  保存字符串
    redisTemplate.opsForValue().set("itbaizhan","itbaizhan123");

    System.out.println(redisTemplate.opsForValue().get("itbaizhan"));

   }
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15

Se meu conteúdo for útil para você, por favorCurta, comente, favorito .Criar não é fácil, o apoio de todos é o que me faz continuar
Insira a descrição da imagem aqui