[Redis] Compreensão aprofundada do mecanismo de persistência Redis - RDB e AOF

Diretório de artigos

1. Persistência Redis
2. Mecanismo de persistência RDB
3. Mecanismo de persistência AOF
4. Persistência mista

1. Persistência Redis

Embora o Redis seja um banco de dados na memória, os dados na memória podem ser perdidos por vários motivos, como reinicialização do servidor Redis, falha inesperada, etc. Para garantir a persistência e confiabilidade dos dados, o Redis introduz um mecanismo de persistência, que permite que os dados sejam salvos regularmente no disco, para que os dados originais possam ser restaurados na memória na próxima vez que o Redis for iniciado.

O mecanismo de persistência do Redis é uma parte importante do banco de dados Redis, que permite que os dados da memória sejam gravados no disco de diferentes maneiras para evitar perda de dados. Isto é fundamental para muitos cenários de aplicação, especialmente sistemas que precisam preservar dados por um longo período ou que possuem requisitos de alta disponibilidade.

Neste artigo, iremos nos aprofundar nos dois principais mecanismos de persistência do Redis, a saber, RDB (Redis DataBase) e AOF (Append-Only File), bem como seu funcionamento, suas vantagens e desvantagens e como configurá-los. Além disso, você conhecerá o conceito de persistência híbrida, que é uma forma de combinar RDB e AOF para aproveitar ao máximo suas respectivas vantagens. Ao ler este artigo, espero que ele possa ajudar os leitores a entender melhor o mecanismo de persistência do Redis para que possam ser configurados e gerenciados corretamente de acordo com os requisitos reais do aplicativo.

2. Mecanismo de persistência RDB

2.1 Compreensão do RBD

Conceito de RDB

RDB (Redis DataBase) é um método de persistência do Redis, usado para salvar os dados atuais na memória em um arquivo de instantâneo no disco rígido . Este arquivo de instantâneo contém todos os dados em um momento específico, incluindo pares de valores-chave, estruturas de dados, etc. O RDB funciona como um backup de um banco de dados , salvando periodicamente os dados da memória em um arquivo persistente para recuperação de dados quando necessário.

Vantagens e desvantagens do mecanismo de persistência RDB

vantagem:

Alto desempenho: o mecanismo de persistência RDB tem bom desempenho. Como o RDB é forkconcluído por meio de um processo filho, o processo principal não precisa realizar operações pesadas de IO , o que garante que o Redis mantenha alto rendimento ao gerar instantâneos RDB.
Compacto e legível: os arquivos RDB estão em um formato binário eficiente que armazena bem os dados e são muito compactos. Isso faz com que os arquivos RDB economizem espaço em disco e sejam altamente legíveis, facilitando o backup e a migração .
Adequado para recuperação de desastres: Os arquivos RDB são instantâneos completos de banco de dados que podem ser usados para recuperar dados de desastres, como falha no disco rígido ou corrupção irreversível de dados.
Backup e migração: Devido à compactação e legibilidade dos arquivos RDB, é ideal para fazer backup de dados ou migrar dados Redis entre diferentes ambientes.
Economize espaço em disco: você pode configurar a frequência de salvamento do RDB conforme necessário, controlando assim o uso do espaço em disco até certo ponto.

deficiência:

Os dados podem ser perdidos: RDB é um arquivo de instantâneo gerado regularmente. Se o servidor Redis travar entre os instantâneos, os dados após o último instantâneo poderão ser perdidos.
Não é adequado para dados em grande escala: Ao processar dados em grande escala, a geração de arquivos RDB pode causar bloqueio de longo prazo e afetar o desempenho. Em alguns casos, os tempos de bloqueio podem tornar-se inaceitáveis.
Não é adequado para necessidades de persistência em tempo real: o RDB é baseado em instantâneos e, portanto, não pode fornecer persistência em tempo real. Se você precisar que todas as operações de gravação sejam persistidas no disco imediatamente, o RDB pode não ser a melhor escolha.
Modificação do arquivo de configuração: Se o arquivo de configuração do Redis for modificado com frequência, o RDB pode se tornar inadequado porque só gerará instantâneos quando o servidor Redis for desligado normalmente. Isso pode resultar em perda de dados após alterações na configuração.

Em resumo, o mecanismo de persistência RDB tem um bom desempenho em termos de desempenho, backup e compactação e é adequado para muitos cenários de uso, mas deve-se notar que os dados podem ser perdidos e precisam ser cuidadosamente considerados ao lidar com dados em grande escala. Se você tiver requisitos mais elevados de persistência em tempo real, poderá considerar o uso do mecanismo de persistência AOF ou persistência híbrida para compensar as deficiências do RDB.

Configuração relacionada ao RDB

A persistência RDB do Redis pode ser configurada no arquivo de configuração do Redis (geralmente redis.conf). A seguir estão alguns itens de configuração comuns relacionados à persistência RDB:

Com que frequência salvar instantâneos:

save 900 1        # 表示在900秒（15分钟）内，如果至少有1个键发生变化，就会触发RDB快照保存。
save 300 10       # 表示在300秒（5分钟）内，如果至少有10个键发生变化，就会触发RDB快照保存。
save 60 10000     # 表示在60秒内，如果至少有10000个键发生变化，就会触发RDB快照保存。

Esses itens de configuração definem as condições de acionamento para persistência RDB. De acordo com requisitos específicos do aplicativo, os instantâneos RDB podem ser acionados com base em diferentes intervalos de tempo e no número de alterações de chave.

Nome e caminho do arquivo RDB:
```
dbfilename dump.rdb    # 指定RDB快照文件的名称
dir /var/lib/redis     # 指定RDB文件的保存路径
```
Esses itens de configuração permitem especificar o nome e o caminho para salvar o arquivo de instantâneo RDB. Observe que você precisa garantir que a pasta exista e tenha as permissões apropriadas.
Desative a persistência automática do RDB:
```
save ""              # 禁用自动RDB持久化
```
Se desejar desabilitar a persistência RDB acionada automaticamente, você poderá savedefinir o item de configuração como uma string vazia.
Compressão persistente RDB:
```
rdbcompression yes  # 开启 RDB 文件压缩（默认情况下是开启的）
```
Este item de configuração controla se o arquivo RDB gerado deve ser compactado. Ativá-lo pode reduzir o tamanho do arquivo RDB, mas ocupará recursos adicionais da CPU.
Arquivo de ponto de verificação:
```
rdbchecksum yes     # 在保存RDB文件时是否进行校验和检查（默认情况下是开启的）
```
Este item de configuração controla se devem ser realizadas verificações de soma de verificação ao salvar arquivos RDB para garantir a integridade do arquivo.

Observe que para que as alterações na configuração tenham efeito, o servidor Redis precisa ser reiniciado. Dependendo das necessidades da aplicação e do volume de dados, esses itens de configuração podem ser ajustados para atender aos requisitos de desempenho e durabilidade.

2.2 Tempo de disparo do RDB

O tempo de acionamento do RDB é dividido em duas formas: acionamento automático e acionamento manual:

Gatilho automático

O acionamento automático é obtido através da frequência de salvamento de snapshots no arquivo de configuração. No arquivo de configuração do Redis (redis.conf), você pode definir uma ou mais savediretivas para definir quando acionar automaticamente o salvamento de snapshots RDB. Cada savecomando possui dois parâmetros, o primeiro parâmetro é o intervalo de tempo em segundos e o segundo parâmetro é o número de chaves que foram alteradas.

Por exemplo, aqui está um exemplo de configuração acionada automaticamente para salvar um instantâneo:

save 900 1        # 表示在900秒（15分钟）内，如果至少有1个键发生变化，就会触发RDB快照保存。
save 300 10       # 表示在300秒（5分钟）内，如果至少有10个键发生变化，就会触发RDB快照保存。
save 60 10000     # 表示在60秒内，如果至少有10000个键发生变化，就会触发RDB快照保存。

Esses itens de configuração definem as condições sob as quais o RDB aciona automaticamente o salvamento do snapshot. O Redis verificará essas condições regularmente e, se alguma delas for atendida, acionará a geração do instantâneo RDB.

Claro que se configurado save "", o acionamento automático será desabilitado.

Gatilho manual: SAVE e BGSAVE

O acionamento manual de instantâneos RDB é obtido por meio de comandos Redis. Existem dois comandos principais disponíveis:

Comando SAVE: Use o comando SAVE para gerar imediatamente um instantâneo RDB, que será executado no 阻塞servidor Redis até que a geração do instantâneo RDB seja concluída. 这个命令不常用，因为它会导致 Redis 服务器在生成快照期间停止响应其他请求.

gramática:

SAVE

Comando BGSAVE: Use o comando BGSAVE para gerar instantâneos RDB em segundo plano sem bloquear a operação normal do servidor Redis. Este é o método de acionamento manual geralmente recomendado.

BGSAVE

O comando BGSAVE usa chamadas de sistema fornecidas pelo sistema operacional forkpara iniciar um processo filho responsável por gerar arquivos de instantâneo RDB, enquanto o processo principal continua respondendo a outras solicitações. Assim que a geração for concluída, o BGSAVE salva o arquivo RDB em disco e notifica o processo principal.

O processo de operação do comando BGSAVE:

ilustrar:

Ao executar o comando BGSAVE, o processo pai do Redis determinará primeiro se há outros processos filhos em execução, como processos filhos executando comandos relacionados a RDB ou AOF. Se houver, o comando BGSAVE neste momento retornará diretamente.

O processo pai será executado para forkcriar o processo filho, e o processo pai será bloqueado durante o processo de bifurcação.Através info statsda latest_fork_usecopção de visualização de comando, você pode obter o tempo gasto para a última forkoperação, em microssegundos.

Após a conclusão da execução do processo pai fork, o comando BGSAVE retornará a mensagem "Salvamento em segundo plano iniciado", depois disso, o processo pai não estará mais bloqueado e poderá continuar respondendo a outros comandos. Ao mesmo tempo, o processo filho é responsável por gerar arquivos de instantâneo RDB.

Quando o processo filho cria um arquivo RDB, ele gera um arquivo instantâneo temporário baseado na memória do processo pai. Após a conclusão, o dump.rdbarquivo original será substituído atomicamente. A execução lastsavedo comando pode obter a última vez que o RDB foi gerado, correspondente à opção infoestatística .rdb_last_save_time

Depois que o processo filho concluir a criação do arquivo RDB, ele enviará um sinal ao processo pai para indicar a conclusão e o processo pai atualizará as estatísticas.

Os snapshots RDB acionados manualmente geralmente são usados para fazer backup de dados do Redis, gerenciar manualmente estratégias de persistência ou criar snapshots consistentes de dados antes de executar determinadas operações. Em suma, o tempo de acionamento do RDB pode ser alcançado de duas maneiras: acionamento automático e acionamento manual, dependendo dos requisitos específicos da aplicação e das estratégias de gerenciamento. O acionamento automático é um mecanismo para salvamento periódico, enquanto o acionamento manual permite criar instantâneos RDB imediatamente quando necessário.

2.3 Processamento de arquivos RDB

O arquivo RDB é um arquivo de instantâneo do banco de dados Redis, que salva os dados atuais na memória para que possam ser restaurados quando necessário. A seguir estão informações importantes sobre o manuseio e gerenciamento de arquivos RDB:

Salvar arquivo RDB

Caminho para salvar o arquivo: os arquivos RDB são salvos no diretório especificado no arquivo de configuração do Redis, por padrão /var/lib/redis/. O nome do arquivo é especificado pelos parâmetros no arquivo de configuração dbfilenamee o padrão é "dump.rdb". CONFIG SETVocê pode usar o comando para alterar dinamicamente o diretório de salvamento e o nome do arquivo enquanto o Redis está em execução , por exemplo:
```
CONFIG SET dir /new/directory/
CONFIG SET dbfilename newdump.rdb
```
Isso salvará o arquivo RDB em um novo diretório e usará um novo nome de arquivo.
Salvamento manual: O salvamento do arquivo RDB pode ser acionado manualmente pela execução SAVEou comando. O comando bloqueará outras solicitações enquanto o servidor Redis gera o arquivo RDB, enquanto o comando irá gerar o arquivo RDB em segundo plano sem bloquear outras operações.BGSAVESAVEBGSAVE
```
  SAVE
BGSAVE
```

Compactar arquivos RDB

Redis usa o algoritmo LZF por padrão para compactar os arquivos RDB gerados para reduzir o tamanho do arquivo e economizar espaço em disco e largura de banda da rede. A compactação está habilitada por padrão, mas podemos modificá-la dinamicamente com o seguinte comando:

CONFIG SET rdbcompression yes   # 开启RDB文件压缩
CONFIG SET rdbcompression no    # 禁用RDB文件压缩

Embora a compactação de arquivos RDB consuma recursos da CPU, geralmente é recomendado ativá-la, especialmente quando o espaço em disco e a largura de banda da rede são limitados, pois pode reduzir significativamente o tamanho do arquivo.

Verifique o arquivo RDB

O Redis carregará o arquivo RDB quando for iniciado. Se o arquivo estiver danificado ou tiver o formato errado, o Redis se recusará a iniciar. Para verificar a integridade e validade dos arquivos RDB, você pode usar as ferramentas fornecidas pelo Redis redis-check-rdb. Esta ferramenta detectará arquivos RDB e gerará relatórios de erros correspondentes para nos ajudar a identificar e resolver problemas.

Verifique o arquivo RDB:

Processar e gerenciar arquivos RDB é uma tarefa importante para garantir a durabilidade e confiabilidade dos dados Redis. Compreender como salvar, compactar e verificar arquivos RDB pode nos ajudar a gerenciar melhor os bancos de dados Redis.

3. Mecanismo de persistência AOF

3.1 Compreendendo a AOF

O conceito de AOF

AOF (Append-Only File) é um mecanismo de persistência do Redis, usado para 写操作以追加的方式记录到一个文本文件中implementar a persistência de dados no servidor Redis. Cada operação de gravação é anexada ao final do arquivo AOF na forma de um comando Redis, portanto, o arquivo AOF é um arquivo de log que registra as operações de gravação em ordem cronológica.

Vantagens e desvantagens da AOF

vantagem:

Segurança de dados : AOF registra cada operação de gravação, portanto, no caso de falha ou travamento do servidor, apenas os dados após a última operação de gravação serão perdidos. Isso fornece maior segurança de dados.
Legibilidade : um arquivo AOF é um arquivo de texto fácil de ler e entender para humanos. Isso torna os arquivos AOF muito úteis quando você precisa recuperar dados manualmente ou fazer depuração.
Flexibilidade : O modo anexado de gravação de arquivos AOF torna a persistência de dados muito em tempo real. Diferentes estratégias de sincronização podem ser selecionadas de acordo com as necessidades, de totalmente síncronas a assíncronas.
Reescrita automática : o Redis fornece um mecanismo de reescrita automática para arquivos AOF, que pode evitar que os arquivos AOF sejam muito grandes e melhorar o desempenho.

deficiência:

Tamanho do arquivo : em comparação com a persistência RDB, os arquivos AOF geralmente são maiores porque contêm o texto do comando para cada operação de gravação. Isso pode ocupar mais espaço em disco.
Desempenho de gravação : a persistência AOF fará com que cada operação de gravação seja anexada ao arquivo AOF, o que pode ter um certo impacto no desempenho de gravação, especialmente ao usar uma estratégia de gravação síncrona.

Configuração relacionada ao AOF

No Redis, você pode CONFIGconfigurar os parâmetros relacionados à persistência AOF através do arquivo de configuração ou usando o comando. A seguir estão algumas opções de configuração AOF comumente usadas:

appendonly: Usado para ativar ou desativar a persistência AOF. Defina como "sim" para ativar o AOF e como "não" para desativá-lo. Por padrão, a persistência AOF está desabilitada e precisa ser habilitada manualmente.
appendfilename: Especifique o nome do arquivo AOF, o padrão é "appendonly.aof". Você pode alterar o nome do arquivo conforme necessário.
appendfsync: especifique a estratégia para sincronizar arquivos AOF com o disco. As opções disponíveis incluem "sempre" (sincronizar cada gravação), "everysec" (sincronizar uma vez por segundo) e "não" (totalmente assíncrono).
auto-aof-rewrite-percentagee auto-aof-rewrite-min-size: usado para configurar as condições de disparo para reescrita automática AOF. O primeiro indica a porcentagem pela qual o tamanho do arquivo AOF aumentou em relação ao tamanho da última reescrita quando a reescrita foi acionada, e o último indica o tamanho mínimo do arquivo AOF.

Essas opções de configuração podem ser encontradas no arquivo de configuração do Redis (geralmente redis.conf) ou podem CONFIGser definidas dinamicamente por meio de comandos. Com base nas suas necessidades e cenários de aplicação, a persistência AOF pode ser configurada de forma flexível para atingir a persistência de dados e os requisitos de desempenho.

3.2 Uso da AOF

Use a demonstração

Depois de configurar as opções relacionadas ao AOF, você precisa usar o comando service redis-server restartpara reiniciar o servidor Redis. Após reiniciar, você descobrirá que há dump.rdbum arquivo adicional no mesmo diretório do arquivo appendonly.aof:

Defina dois dados no Redis:

Visualizar appendonly.aofarquivo:

o conteúdo do arquivo é o comando para gravar os dados agora.

Encerre abruptamente o servidor Redis e reinicie-o:

conecte-se e consulte o banco de dados Redis e descubra se os dados não foram perdidos:

Fluxo de trabalho AOF

O diagrama de fluxo de trabalho é o seguinte:

Todos os comandos de gravação são anexados ao aof_bufbuffer.
O buffer AOF executa operações de sincronização com o disco rígido de acordo com a política correspondente.
À medida que os arquivos AOF ficam cada vez maiores, os arquivos AOF precisam ser reescritos regularmente para obter compactação.
Quando o servidor Redis é iniciado, os comandos do arquivo AOF são carregados para recuperação de dados.

Escrita de comandos:
o conteúdo escrito pelo comando AOF segue diretamente o formato do protocolo de texto do Redis. Por exemplo, set hello worldo comando é representado em formato de protocolo de texto no buffer AOF da seguinte forma:

*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n

As razões pelas quais o Redis escolhe o protocolo de texto incluem boa compatibilidade, implementação simples e legibilidade.

Por que usar aof_bufbuffer:

O buffer AOF (aof_buf) existe para melhorar o desempenho de gravação. Como o Redis responde aos comandos em um único thread, se cada gravação for sincronizada diretamente no disco rígido, o desempenho será seriamente afetado. Ao escrever primeiro comandos no buffer, o Redis pode reduzir efetivamente o número de operações de E/S e melhorar o desempenho. Além disso, o Redis também oferece uma variedade de estratégias de sincronização de buffer, permitindo que os usuários façam compensações com base nos requisitos de desempenho e segurança de dados.

3.3 Estratégia de arquivo de sincronização AOF

O Redis fornece uma variedade de estratégias de arquivo de sincronização de buffer AOF, que são controladas por redis.confparâmetros no arquivo de configuração () appendfsync.Os valores configuráveis e suas descrições são mostrados na tabela a seguir:

Valores configuráveis	ilustrar
sempre	Cada passagem na `write`gravação `aof_buf`forçará uma chamada imediata `fsync`para sincronizar os dados no disco, garantindo a segurança dos dados, mas com baixo desempenho de gravação.
cada segundo	Anexando `write`primeiro à operação `aof_buf`e depois executando uma operação de sincronização a cada segundo, os dados são sincronizados no arquivo AOF para equilibrar o desempenho e a segurança dos dados.
não	Somente as operações de gravação são `write`anexadas por `aof_buf`, as operações de sincronização são controladas pelo sistema operacional. Essa configuração fornece o melhor desempenho de gravação, mas menor segurança de dados.

Notas sobre chamadas do sistema writee :fsync

writeA operação acionou o mecanismo de gravação atrasada. O kernel do Linux fornece buffers de página para melhorar o desempenho de E/S do disco rígido. writeA operação retorna imediatamente após gravar os dados no buffer do sistema. A sincronização com o disco depende do mecanismo de agendamento do sistema operacional, por exemplo, quando a página do buffer está cheia ou um intervalo de tempo específico é atingido. Se o sistema travar ou travar antes de sincronizar os arquivos, os dados no buffer poderão ser perdidos.
fsyncÉ uma operação para um único arquivo, realiza a sincronização forçada do disco rígido e fsyncbloqueia até que os dados sejam gravados no disco rígido.

Diferentes valores de configuração:

alwaysQuando configurado , cada gravação força a sincronização do arquivo AOF, o que resulta em baixo desempenho. Em um disco rígido SATA geral, ele suporta apenas algumas centenas de gravações TPS. Geralmente não é recomendado configurar isso, alwaysa menos que os dados sejam muito importantes.
noQuando a configuração está incorreta , como a política de sincronização do sistema operacional não é controlada, embora o desempenho seja melhorado, o risco de perda de dados aumenta bastante. Geralmente não é recomendado configurar isto no, a menos que a importância dos dados seja muito baixa.
Configurado como everysecé a configuração padrão e a opção de configuração recomendada, que leva em consideração a segurança e o desempenho dos dados. Em teoria, apenas 1 segundo de dados será perdido, no máximo.

Essas opções de configuração permitem que os usuários escolham uma estratégia de sincronização AOF adequada com base nos requisitos de desempenho e segurança de dados.

3.4 Mecanismo de reescrita AOF

Por que reescrever arquivos AOF

O arquivo AOF foi reescrito para resolver o problema de um grande número de comandos inválidos que podem existir no Redis. Vamos ilustrar com alguns exemplos simples:

No Redis, a seguinte série de comandos de gravação é executada:

SET key1 123
SET key1 hello
SET key1 world
SET key1 123

Embora 4 comandos de gravação tenham sido executados acima, apenas os dados gravados pelo último comando existem no Redis, ou seja, o key1valor é 123.

Da mesma forma, a seguinte série de comandos de gravação foi executada:

SET key2 123
SET key2 hello
SET key2 world
SET key2 123
DEL key2

Embora 5 comandos de gravação tenham sido executados acima, eles key2no final não existiam no Redis.

Por exemplo, execute o seguinte comando no Redis:
Antes de reescrever:
Depois de reescrever:

Neste momento, constatou-se que apareciam caracteres ilegíveis, ou seja, eram armazenados em formato binário, a razão para isso era que AOP e RDB estavam habilitados ao mesmo tempo, então a estratégia de persistência adotada pelo Redis neste momento era híbrida persistência.

Use a ferramenta de verificação fornecida pelo Redis redis-check-aofpara verificar o arquivo AOF e você descobrirá que o arquivo AOF é legal:

Pode-se concluir a partir dos dois exemplos simples acima:

Sem o mecanismo de reescrita de arquivo AOF, o Redis continuará a armazenar um grande número de comandos inválidos, o que fará com que o arquivo AOF fique grande, ocupe muito espaço em disco e reduza o desempenho de leitura do arquivo AOF.
A reescrita do arquivo AOF resolve esse problema limpando esses comandos inválidos e gerando um novo arquivo AOF mais compacto e eficiente. O novo arquivo AOF contém apenas comandos de gravação válidos, o que ajuda a reduzir o tamanho do arquivo, melhorar o desempenho de leitura e garantir que nenhum dado válido seja perdido. Esta é a razão pela qual os arquivos AOF precisam ser reescritos.

Como acionar a reescrita AOF

A reescrita de arquivos AOF pode ser acionada das duas maneiras a seguir:

Acionamento manual : Ao chamar o comando fornecido pelo Redis BGREWRITEAOF, o processo de reescrita do arquivo AOF pode ser acionado manualmente. Este comando começará imediatamente a reescrever o arquivo AOF sem afetar a operação normal do Redis.
Acionamento automático : o Redis também oferece suporte ao acionamento automático de reescrita de arquivos AOF. O tempo de acionamento é determinado com base em dois parâmetros de configuração:
- auto-aof-rewrite-min-size: Este parâmetro define o tamanho mínimo do arquivo AOF, em MB. O valor padrão é 64 MB. Somente quando o tamanho do arquivo AOF exceder esse limite a reescrita automática será considerada.
- auto-aof-rewrite-percentage: Este parâmetro define a taxa de crescimento do tamanho do arquivo AOF em relação à última reescrita, expressa como uma porcentagem. O valor padrão é 100%. Se o tamanho do arquivo AOF ultrapassar essa porcentagem desde a última reescrita, a reescrita automática será acionada.
Por exemplo, se auto-aof-rewrite-min-sizedefinido como 64 MB e auto-aof-rewrite-percentagedefinido como 100%, a reescrita automática só será acionada se o tamanho do arquivo AOF exceder 64 MB e tiver aumentado 100% ou mais desde a última reescrita.

O acionamento automático da reescrita de arquivos AOF visa garantir que os arquivos AOF não cresçam sem limites e evitar a execução de operações de reescrita com muita frequência. Isso pode manter o arquivo AOF em um tamanho razoável sem perder dados, melhorar o desempenho e reduzir o uso de espaço em disco.

Fluxo de execução reescrito do AOP

O fluxo de execução da reescrita de AOP é o seguinte:

Execute a solicitação de reescrita AOF.
- Se o processo atual estiver executando a reescrita AOF, a solicitação não será executada.
- Se o processo atual estiver executando uma operação bgsave, o comando de reescrita será atrasado até que o bgsave seja concluído.
O processo pai executa fork para criar um processo filho.
Processo de reescrita:
a. O processo principal continua respondendo a outros comandos após a bifurcação. Todas as operações de modificação serão gravadas no buffer AOF e sincronizadas no disco rígido de acordo com a política appendfsync para garantir a exatidão do antigo mecanismo de arquivo AOF.
b. O processo filho possui apenas todas as informações de memória antes da bifurcação, portanto, o processo pai precisa gravar as operações de modificação durante o período após a bifurcação no buffer de reescrita AOF.
O processo filho mescla os comandos em um novo arquivo AOF baseado no instantâneo da memória.
O processo filho completa a reescrita:
a. Após a gravação do novo arquivo, o processo filho envia um sinal ao processo pai.
b. O processo pai anexa os comandos salvos temporariamente no buffer de reescrita AOF ao novo arquivo AOF.
c. Substitua o arquivo AOF antigo pelo novo arquivo AOF.

4. Persistência mista

Persistência híbrida significa que o Redis usa métodos de persistência AOF (Append-Only File) e RDB (Redis Database) para garantir a durabilidade dos dados. Esta estratégia combina dois métodos de persistência diferentes para dar conta de diferentes necessidades e cenários.

Veja como funciona a persistência híbrida e suas vantagens:

1. Persistência AOF:

AOF é um arquivo de log de gravação anexado que registra os comandos para cada operação de gravação e os parâmetros desses comandos.
A persistência AOF é em tempo real, ou seja, cada operação de gravação é anexada ao arquivo AOF, garantindo a integridade dos dados.
Os arquivos AOF podem ser usados para recuperação de dados e o Redis pode reconstruir o estado dos dados executando novamente os comandos nos arquivos AOF.

2. Persistência RDB:

RDB é uma persistência de instantâneo que salva dados na memória Redis em disco em formato binário.
A persistência RDB é ponto a ponto, ou seja, um arquivo de instantâneo é gerado dentro de um intervalo de tempo especificado, geralmente após a alteração dos dados da memória.
Um arquivo RDB é um arquivo binário compactado usado para restaurar rapidamente o estado de todo o banco de dados quando necessário.

Como funciona a persistência híbrida:

O Redis habilita métodos de persistência AOF e RDB.
Os arquivos AOF registram cada operação de gravação, enquanto os arquivos RDB geram instantâneos em intervalos específicos.
Durante a recuperação de dados, o Redis tentará primeiro usar o arquivo AOF para recuperação, pois contém mais comandos históricos e pode fornecer uma recuperação de dados mais completa.
Se o arquivo AOF estiver danificado ou muito grande, o Redis poderá usar o arquivo RDB para inicialização rápida e, em seguida, executar o reparo dos dados com base no arquivo AOF.

Vantagens da persistência híbrida:

Segurança de dados: AOF fornece anexação de dados e registros históricos em tempo real, tornando os dados mais seguros. RDB fornece um método de recuperação rápida.
Desempenho: as operações de gravação AOF são mais eficientes que o RDB, e o RDB fornece recuperação rápida de dados.
Flexibilidade: A persistência híbrida permite escolher o método de recuperação apropriado com base em diferentes necessidades e cenários.
Reduza a perda de dados: Como os arquivos AOF contêm operações históricas, a possibilidade de perda de dados pode ser reduzida.

Resumindo, a persistência híbrida combina os dois métodos de persistência AOF e RDB, leva em consideração o desempenho e a recuperação em tempo real, fornece uma estratégia de proteção de dados mais abrangente e torna o Redis mais poderoso e confiável em diferentes cenários de aplicação. No entanto, deve-se observar que a persistência híbrida pode aumentar a sobrecarga de armazenamento e a carga de E/S do disco, portanto, é necessária uma consideração cuidadosa durante a configuração.