Persistência Redis: explicação detalhada de RDB e AOF

A origem da persistência RDB e AOF?

Como os dados no Redis são baseados na memória, se o servidor for desligado ou cair, os dados armazenados no Redis serão perdidos diretamente. RDB e AOF são dois mecanismos de persistência fornecidos para Redis, que podem persistir dados no Redis em disco. Quando a instância do Redis falha e reinicia, os dados podem ser restaurados de acordo com o arquivo de backup

Dois, RDB

Visão geral:

RDB também é chamado de instantâneo de dados do Redis. Simplificando, ele registra todos os dados na memória do disco. Quando a instância do Redis falha e reinicia, o arquivo de instantâneo é lido do disco para restaurar os dados. Os arquivos de instantâneo são chamados de arquivos RDB, que são salvos no diretório em execução atual por padrão (O RDB pode entender tarefas de temporização periódicas e o conteúdo da tarefa é fazer backup completo dos dados)
Cada vez que o RDB é acionado, um novo arquivo RDB será regenerado para substituir o arquivo RDB antigo, de modo a garantir que o backup obtenha os dados mais recentes.

Estratégia de gatilho RDB:

① Ao fechar a instância do Redis, o redis executará ativamente um RDB antes de fechar ( fechar não é
② Quando você usa o comando save/bgsave, o redis também persistirá os dados da memória③tempo de inatividade, tempo de inatividade significa perda de dados)

save 900 1
– significa que dentro de 900 segundos, 1 chave no redis muda, então execute um bgsave
save 300 10
– significa que dentro de 300 segundos, 1 chave no redis muda, então execute um bgsave
save 60 10000
– significa que dentro de 60 segundos, 10.000 chaves no redis são alteradas e, em seguida, um bgsave é executado

A diferença entre salvar/bgsave

Conforme mencionado anteriormente, você pode usar o comando save ou o comando bgsave para acionar o RDB, então qual é a diferença entre os dois?

Se você usar o comando save, o backup de dados será executado pelo thread principal. Como o Redis é de thread único, se você usar o comando save para fazer backup dos dados da memória, o redis não poderá responder às solicitações do usuário durante o backup de dados. Quando os dados a serem copiados são muito grandes, isso pode fazer com que a solicitação seja bloqueada e expire
Se o comando bgsave for usado, o thread principal realmente bifurca subthreads para executar operações RDB. O thread principal só bloqueia quando os subthreads são bifurcados e continua a responder às solicitações do usuário. Em seguida, o processo filho pode ler os dados da memória e persisti-los, e gerar um novo arquivo RDB para substituir o arquivo RDB antigo

Desvantagens do RDB:

O intervalo de execução do RDB é longo e há risco de perda de dados entre duas gravações do RDB.
Bifurcar processos filhos, compactar e gravar arquivos RDB são demorados

Vantagens do RDB:

Usar arquivos RDB para restaurar dados é rápido e eficiente (semelhante à cópia de arquivos)
Comparados com arquivos persistentes AOF, os arquivos RDB são menores

Configuração relacionada ao RDB:

Configure a compactação de arquivo RDB em redis.conf

# 表示的是是否开启压缩，不建议开启，虽然节省空间，但是会耗费CPU
rdbcompression yes

Configure o nome do arquivo RDB em redis.conf

# 默认的rdb文件名称
dbfilename dump.rdb

Configure o caminho de armazenamento do arquivo rdb em redis.conf

dir ./

Configure a estratégia de gatilho em redis.conf

# 15分钟内有1个key发生改变，那么就保存
save 900 1
# 5分钟内有10个key发生改变，那么就保存
save 300 10
# 1分钟内有10000个key发生改变，那么就保存
save 60 10000
# 执行的都是bgsave

3. AOF

Visão geral:

O nome completo do AOF é Append Only File (append file), cada comando processado pelo Redis será registrado no arquivo AOF, que pode ser considerado um arquivo de log de comando (O que o AOF armazena não são os dados em si, mas o comando para executar a operação de gravação redis, que é semelhante a armazenar comandos como inserir/atualizar em vez de dados）

Estratégia de gatilho: acione redis.conf de acordo com o arquivo de configuração

Cada vez que um comando é executado, ele é imediatamente gravado no arquivo AOF (o desempenho é pior, é executado pelo processo principal)

appendfsync always

Depois que o comando de gravação for executado, coloque-o primeiro no buffer AOF e, em seguida, grave os dados no buffer no arquivo AOF a cada 1s. A configuração padrão (o desempenho é melhor, mas os dados dentro de 1s podem ser perdidos)

appendfsync everysec

Depois que o comando de gravação for executado, coloque-o primeiro no buffer AOF e o sistema operacional decidirá gravá-lo de volta no disco de maneira adequada (a confiabilidade é relativamente baixa e o desempenho é o melhor)

appendfync no

item de configuração	Momento da escovação	vantagem	deficiência
Sempre	Disco de escova síncrono	Baixa confiabilidade, quase nenhuma perda de dados	impacto no desempenho
cada segundo	Escova por segundo	desempenho moderado	Perda de dados de até 1s
não	controle do sistema operacional	melhor performance	Baixa confiabilidade, possível perda de grandes quantidades de dados

Mecanismo de reescrita AOF:

Como o AOF grava comandos, quando muitos comandos são executados, muitos comandos redundantes serão gravados, por exemplo:

# 添加key1的值
set key1 v1
# 修改key1的值
set key1 v2
# 删除key1的值
del key1

Na verdade, key1 foi excluído no final, então todos os comandos sobre key1 são realmente inúteis, mas todos os comandos são registrados em AOF, o que fará com que o arquivo AOF seja grande e armazene muitos comandos redundantes.
Usando o comando bgrewriteaof, o arquivo AOF pode ser reescrito para obter o mesmo efeito com o mínimo de comando. Após a execução do comando, todos os comandos redundantes serão excluídos para obter o efeito de compactação do arquivo AOF.

Vantagens da AOF:

Através da configuração, os dados de backup podem se tornar mais completos e seguros
Menos recursos de CPU são ocupados cada vez que o AOF é executado (por ser um acréscimo, o RDB é todo copiado novamente)

Desvantagens da AOF:

A restauração usando arquivos AOF é lenta e todas as instruções precisam ser executadas sequencialmente
Os arquivos AOF podem ser muito maiores que o RDB, registrando todas as operações de gravação

Configuração AOF:

Configure AOF em redis.conf para habilitar

# 表示的是开启，默认是no
appendonly yes

Configure o nome do arquivo AOF em redis.conf

# 这里表示的是AOF文件名称
appendfilename "appendonly.aof"

Configure a estratégia de gatilho de reescrita em redis.conf

# AOF文件比上次文件增长超过百分之百则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才能触发重写
auto-aof-rewrite-min-size 64mb

Em quarto lugar, a comparação entre RDB e AOF

	RDB	AOF
Persistência	Tire instantâneos de toda a memória em intervalos regulares	Registrar cada comando executado
integridade de dados	Incompleto, perdido entre backups	Relativamente completo, dependendo da estratégia de escovação
Tamanho do arquivo	Haverá compactação, o tamanho do arquivo é menor	Grave comandos, o tamanho do arquivo é muito grande
Velocidade de recuperação do tempo de inatividade	breve	lento
Prioridade de recuperação de dados	Baixo porque a integridade dos dados não é tão boa quanto AOF	Alto devido à maior integridade dos dados
Uso de recursos do sistema	Consumo alto e pesado de CPU e memória	Recursos baixos, principalmente de E/S de disco, mas o AOF consumirá muitos recursos de CPU e memória ao reescrever
cenas a serem usadas	A perda de dados pode ser tolerada por vários minutos e a busca por uma velocidade de inicialização mais rápida	Altos requisitos de segurança de dados são comuns

5. Pontos de conhecimento:

O RDB está habilitado por padrão e o AOF está desabilitado por padrão.

6. Uso real

No uso real, geralmente, um deles não será ativado sozinho, mas uma combinação dos dois será usada em conjunto. De acordo com a tolerância a desastres, o RDB pode executar RDB periodicamente para obter arquivos de backup em momentos especificados. AOF tem dados mais completos, com muito pouca perda de dados.