Persistência de dados de alta disponibilidade do Redis

A alta disponibilidade do Redis é garantida pelos seguintes aspectos:

Persistência de dados
Replicação mestre-escravo
Recuperação automática de falhas
Grupo

O autor apresentará os aspectos acima um por um. O artigo de hoje apresentará primeiro a persistência de dados do Redis.

1. Por que precisamos de persistência?

O Redis é um banco de dados na memória. Todos os dados são armazenados na memória. Se a instância cair, todos os dados serão perdidos. O Redis oferece um mecanismo completo de persistência de dados, que pode persistir os dados no disco, para que possamos fazer backup e restaurar os dados rapidamente. .

Dois, método de persistência de dados Redis

O Redis oferece dois métodos de persistência de dados:

RDB: Salve os dados da memória no disco rígido na forma de um instantâneo e gere um arquivo dump.rdb, que é um arquivo binário. Como o arquivo RDB é armazenado no disco, mesmo se o processo do servidor Redis for encerrado, o arquivo RDB ainda estará lá. O servidor Redis detecta a existência do arquivo RDB quando é iniciado e carrega automaticamente o arquivo RDB e o usa para restaurar o estado do banco de dados.
AOF: a persistência de AOF registra o status do banco de dados salvando os comandos de gravação executados pelo servidor Redis. O arquivo AOF salva o protocolo de solicitação de comando de gravação do Redis , que está em formato de texto simples. Você pode abrir diretamente o arquivo AOF para visualizar o conteúdo do arquivo.

Nota:
1. O Redis ativa a função de persistência RDB por
padrão ; 2. AOF está desativado por padrão. Se a função de persistência AOF for ativada manualmente, o arquivo AOF será usado primeiro para restaurar o estado do banco de dados, porque a frequência de atualização do arquivo AOF é geralmente maior do que a frequência de atualização do arquivo RDB Alto.
Redis inicia o processo de carregamento de dados

1. Resistência RDB

1.1 Quando a persistência RDB será disparada?

As situações que acionam a persistência RDB são divididas em acionamentos manuais e acionadores automáticos.

1.1.1 Gatilho manual

Comando de disparo manual:

salvar: Bloqueio.Uma instância com grande memória irá causar um bloqueio longo durante a execução, durante o qual o processo principal não pode processar nenhuma solicitação de comando.
bgsave: processo filho fork, o processo filho é responsável pela criação de arquivos RDB e o processo pai pode continuar a processar solicitações de comando. O bloqueio ocorre na fase de bifurcação e o tempo é curto.

1.1.2 Gatilho automático

As condições para acionar RDB automaticamente são:

Use salvar configuração;
formato de configuração: salvar [segundos] [alterações]
significa que o bgsave é acionado automaticamente quando há [alterações] alterações no conjunto de dados em [segundos] segundos.
A configuração padrão é:

#只要以下3个条件中的任意一个满足，bgsave就会执行。
#服务器在900秒内，对数据库进行了至少1次修改
save 900 1
#服务器在300秒内，对数据库进行了至少10次修改
save 300 10
#服务器在60秒内，对数据库进行了至少10000次修改
save 60 10000

Princípio de implementação:

#serverCron服务定时器每100ms执行一次检查
if(now()-rdb_last_save_time < m(指定秒数) and rdb_changes_since_last_save>n(修改次数)){
    
    
   bgsave();
}

Execute a operação de cópia completa a partir do nó;
Quando o comando de desligamento é executado, o bgsave será executado automaticamente se o AOF não estiver ativado;
comando debug reload;

Nota :如果开启了自动RDB，flushall因涉及的操作较多，可能会触发自动RDB，新产生的RDB文件将为空。

1.2 Configuração relacionada a RDB em redis.conf

#RDB自动触发条件(满足任意一个就可以触发RDB)
save 900 1
save 300 10
save 60 10000
#bgsave创建快照的时候出错了（比如，fork子进程内存不足或rdb文件所在的文件夹没有写入权限），redis主进程将不再接受新的写入命令
stop-writes-on-bgsave-error yes
#对RDB文件进行压缩
rdbcompression yes 
#RDB文件名称
dbfilename dump.rdb
#对RDB进行校验
rdbchecksum yes
 #（保存目录，这里是相对目录，和redis.conf是同一个目录）
dir ./

1.3 Etapas de persistência RDB

Execute o comando bgsave, o processo pai do Redis avalia se há processos filho em execução, como processos filho RDB / AOF; se houver um comando bgsave, ele retorna diretamente;
O processo pai executa a operação de bifurcação para criar um processo filho. O processo pai será bloqueado durante a operação de bifurcação. Você pode visualizar a opção latest_fork_usec por meio do comando info stats para obter a hora da última operação de bifurcação em microssegundos;
Após a bifurcação do processo pai ser concluída, o comando bgsave retorna a mensagem "Salvamento em segundo plano iniciado" e não bloqueia mais o processo pai e pode continuar a responder a outros comandos;
O processo filho cria um arquivo RDB, gera um arquivo instantâneo temporário com base na memória do processo pai e substitui atomicamente o arquivo original após a conclusão. Execute o comando lastsave para obter a hora da última geração de RDB, correspondendo à opção rdb_last_save_time das estatísticas de informação.
O processo envia um sinal ao processo pai para indicar a conclusão e o processo pai atualiza as estatísticas. Para obter detalhes, consulte as opções relacionadas a rdb_ * em info Persistência.

Nota : fork子进程时，需要生成另外一份内存，如果原来内存占用比较大，会存在内存膨胀的问题。
Para o arquivo RDB de formato incorreto, você pode usar uma redis-check-rdbferramenta para repará-lo.

2. Persistência AOF

2.1 Configuração relacionada ao AOF no redis.conf

#开启AOF，默认关闭
appendonly yes
#AOF文件名称
appendfilename appendonly.aof
 #（保存目录，这里是相对目录，和redis.conf是同一个目录）
dir ./ 

#AOF文件写入磁盘频率
appendfsync always  #每次收到写命令就立即强制写入磁盘，是最安全的。但该模式下速度也是最慢的，一般不推荐使用。
appendfsync everysec #默认方式，每秒钟强制写入磁盘一次，在性能和持久化方面做平衡，推荐该方式。
appendfsync no  #完全依赖操作系统的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不推荐。

/*AOF重写相关命令*/
#在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes
no-appendfsync-on-rewrite yes
#AOF重写触发条件
auto-aof-rewrite-percentage 100 #当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-min-size 64mb #当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。

2.2 Etapas de persistência AOF

A implementação da persistência AOF pode ser dividida em três etapas: anexação de comando, gravação de arquivo e sincronização de arquivo.

Anexo de nome: Após o servidor ter executado um comando de gravação, ele anexará o comando de gravação executado ao final do buffer aof_buf no estado do servidor no formato de protocolo;
Gravação e sincronização de arquivo: O servidor verifica regularmente se o conteúdo na área de buffer aof_buf precisa ser gravado e salvo no arquivo AOF. Se a gravação do arquivo é necessária, é definido de acordo com a opção appendfsync.Você pode definir o valor da opção appendfsync com base na eficiência e segurança da persistência AOF.

Nota : Para o arquivo AOF no formato errado, primeiro faça um backup e, em seguida, use o redis-check-aof --fixcomando para repará-lo. Após o reparo, use diff-u para comparar as diferenças de dados para descobrir os dados ausentes, e alguns podem ser modificados e concluídos manualmente.

2.3 Reescrever AOF

2.3.1 Por que o AOF foi reescrito?

Quando o comando de gravação é anexado ao arquivo AOF, o AOF se torna cada vez maior, ocupando muito espaço no disco rígido, e o carregamento de dados após a reinicialização será muito lento, portanto, a reescrita AOF é necessária.

2.3.2 Mecanismo de gatilho de reescrita AOF

Existem duas maneiras de acionar a reescrita AOF: acionamento manual e acionamento automático.

Gatilho manual: execute manualmente o comando BGREWRITEAOF;
Auto: configurando o redis.conf no auto-aof-rewrite-percentagee auto-aof-rewrite-min-sizepara perceber que essas duas condições são 同时满足acionadas quando o AOF.

2.3.3 Regras de reescrita AOF

A reescrita de AOF não lê e analisa o arquivo AOF existente, ela é obtida lendo o status atual do banco de dados do servidor.
Portanto, os dados expirados não serão gravados no novo arquivo AOF e vários comandos para a mesma chave serão substituídos por um comando devido à leitura direta do status do banco de dados. Além disso, para evitar o estouro do buffer de entrada do cliente causado por muitos dados contidos em uma chave, o programa de reescrita primeiro determinará a chave que contém ao processar chaves que podem conter vários elementos, como listas, conjuntos, conjuntos ordenados e hashes. Se o número de elementos exceder o valor constante configurado (o padrão é 64), ele será dividido em vários comandos.

2.3.4 Etapas de reescrita AOF

Execute a solicitação de reescrita AOF. Se o processo atual estiver realizando a reescrita AOF, a operação de reescrita não será realizada. Se o processo estiver executando o bgsave, ele aguardará a conclusão da execução antes de executar.
O processo pai executa fork para criar um processo filho, e a sobrecarga é equivalente ao processo bgsave.
(1) Depois que a operação de bifurcação do processo principal for concluída, continue a responder aos outros comandos. Todos os comandos de modificação ainda são gravados no buffer AOF e sincronizados com o disco rígido de acordo com a estratégia appendfsync para garantir a exatidão do mecanismo AOF original.
(2) Como a operação fork usa tecnologia copy-on-write, o processo filho só pode compartilhar os dados da memória durante a operação fork. Como o processo pai ainda responde aos comandos, o Redis usa o "buffer de reescrita AOF" para salvar essa parte dos novos dados para evitar que essa parte dos dados seja perdida durante a geração do novo arquivo AOF.
O processo filho grava no novo arquivo AOF de acordo com o instantâneo da memória e as regras de mesclagem de comando. A quantidade de dados gravados no disco rígido em lotes cada vez é controlada pela configuração aof-rewrite-incremental-fsync, o padrão é 32 MB, para evitar que o disco rígido seja bloqueado por muitos dados em um único flash.
(1) Depois que o novo arquivo AOF é gravado, o processo filho envia um sinal para o processo pai, e o processo pai atualiza as estatísticas. Para obter detalhes, consulte aof_ * estatísticas relacionadas em persistência de informações.
(2) O processo pai grava os dados no buffer de reescrita AOF no novo arquivo AOF.
(3) Substitua o arquivo antigo pelo novo arquivo AOF para completar a reescrita AOF.

3. Comparação de RDB e AOF

O desempenho do RDB é superior ao do AOF:
● Os dados são armazenados em modo binário e o arquivo de dados é relativamente pequeno e o carregamento é rápido;
● Ao armazenar, é armazenado de acordo com a estratégia de salvamento na configuração. Bom, e o AOF geralmente funciona no modo de armazenamento em tempo real ou quase em tempo real. Relativamente falando, a frequência de armazenamento é alta, mas a eficiência é baixa.
A segurança dos dados AOF é maior do que a do RDB:
● O armazenamento é baseado na ideia de lotes cumulativos, ou seja, se permitido, quanto mais dados acumulados, maior a eficiência de gravação, mas o acúmulo de dados é completado pelo acúmulo de tempo Sim, se os dados não forem gravados no RDB por muito tempo, mas o Redis encontrar um travamento, então os dados não gravados não podem ser recuperados, mas o método AOF é ao contrário, de acordo com a estratégia de frequência de armazenamento configurada pelo AOF, o mínimo pode ser alcançado Perda de dados e alta capacidade de recuperação de dados.
A escolha entre os dois é uma escolha entre desempenho e segurança de dados.

3. Referências

https://zhuanlan.zhihu.com/p/111306444
"Projeto e implementação do Redis"