minhas informações de contato
Correspondência[email protected]
2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
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
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.
MULTI
Inicie uma transação;EXEC
O comando aciona a transação;
Multi、Exec、descartar
entrada de transação deMulti
Quando 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 passardiscard
Venha 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"
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
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.
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"
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.
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.
O papel da replicação mestre-escravo
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
Crie novo redis6380.conf
include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb
Crie novo redis6381.conf
include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6381.pid
port 6381
dbfilename dump6381.rdb
Inicie três servidores redis
./redis-server ../redis6379.conf
./redis-server ../redis6380.conf
./redis-server ../redis6381.conf
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
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
Equipado com banco de dados escravo, mas não com banco de dados mestre
Formato de sintaxe:
slaveof <ip> <port>
Exemplo:
Executado em 6380 e 6381.
127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
Escreva no host e leia os dados no escravo
set k1 v1
A replicação mestre-escravo pode ser dividida em 3 estágios
O processo de cópia é dividido aproximadamente em 6 processos
info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
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.
efeito:
- Detecte se o soquete de rede entre mestre e escravo está disponível.
- Detecte se o nó mestre pode atualmente aceitar comandos
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.
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.
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
O comando de gravação é
$3 r n
set r n
$4 r n
name r n
$5 r n
jjy r n
Desvio | 1000 | 1001 | 1002 | 1003 | 1004 | 1005 | 1006 | 1007 | 1008 |
---|---|---|---|---|---|---|---|---|---|
Valor do byte | $ | 3 | r | e | $ | 4 | e | a | eu |
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.
Desvantagens da replicação mestre-escravo do Redis
Quando o host Master fica inativo, precisamos resolver a mudança manualmente.
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.
Papel sentinela
Crie um novo arquivo sentinel-26379.conf
#端口
port 26379
#守护进程运行
daemonize yes
#日志文件
logfile "26379.log"
sentinel monitor mymaster localhost 6379 2
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
Crie um novo arquivo sentinel-26381.conf
#端口
port 26381
#守护进程运行
daemonize yes
#日志文件
logfile "26381.log"
sentinel monitor mymaster localhost 6379 2
Iniciando o nó sentinela
redis-sentinel sentinel-26379.conf
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
fase de monitoramento
Perceber:
- sentinela (sentinela 1)----->Inicie informações para o mestre (mestre) e escravo (escravo) e obtenha as informações completas.
- sentinela (sentinela 2) ----->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)----->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.
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:
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
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
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
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
para concluir
Redis tem três modos de cluster
Desvantagens do Modo Sentinela
deficiência:
Visão geral do modo cluster
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
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;
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
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/
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
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
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
Verifique o cluster
Conecte-se a qualquer cliente
./redis-cli -h 192.168.47.100 -p 6379 -c
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>
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.
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
Mate o nó mestre
lsof -i:8001
kill -9 pid
Observe as informações do nó
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
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"));
}
}
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