Mecanismo de persistência Redis AOF

Além da função de persistência RDB, o Redis também fornece a função de persistência AOF (Append Only File). Ao contrário da persistência RDB que registra o estado do banco de dados salvando pares de valores-chave no banco de dados, a persistência AOF registra o estado do banco de dados salvando os comandos de gravação executados pelo servidor Redis , conforme mostrado na figura a seguir.

Por exemplo:

O método de RDB para persistir o estado do banco de dados é salvar os pares de valores-chave das três chaves msg, frutas e números no arquivo RDB, enquanto o método de AOF para persistir o estado do banco de dados é executar o SET e SADD do servidor. RPUSH três comandos são salvos no arquivo AOF.

Implementação do Mecanismo de Persistência AOF

A realização da função de persistência AOF pode ser dividida em três etapas : acréscimo de comando (acréscimo), gravação de arquivo e sincronização de arquivo (sincronização) .

1. Anexo de Comando
   Quando a função de persistência AOF é ativada, 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 (formato de protocolo de solicitação de comando Redis):

2. Gravação e sincronização de arquivos
   O processo servidor do Redis é um loop de eventos (loop). O evento de arquivo neste loop é responsável por receber solicitações de comando do cliente e enviar respostas de comando ao cliente, enquanto eventos de tempo são responsáveis ​​por executar necessidades como funções servercron. que funcionam em intervalos regulares. Como o servidor pode executar comandos de gravação ao processar eventos de arquivo, algum conteúdo é anexado ao buffer aof_buf, portanto, antes que o servidor termine um loop de evento a cada vez, ele chamará a função flushAppendonlyFile, considere se ela precisa estar no buffer aof_buf. o conteúdo é gravado e salvo no arquivo AOF.
   Esse processo pode ser representado pelo seguinte código:
   O comportamento da função flushAppendonlyFile é determinado pelo valor da opção appendfsync configurada pelo servidor e o comportamento de cada valor diferente é mostrado na tabela a seguir.

   Se o usuário não definir ativamente o valor para a opção appendfsync, o valor padrão da opção appendfsync é everysec. Para obter mais informações sobre a opção appendfsync, consulte o exemplo de arquivo de configuração redis.conf anexado ao projeto Redis.

A eficiência e segurança da persistência AOF

O anterior dizia que o servidor precisa configurar o valor da opção appendfsync, e o valor da opção appendfsync determina diretamente a eficiência e segurança da função de persistência AOF. Para detalhes, veja abaixo:

1. Quando o valor de appendfsync é sempre, o servidor grava todo o conteúdo do buffer aof_buf no arquivo AOF em cada loop de evento e sincroniza o arquivo AOF, de modo que a eficiência de always é o mais lento dos três valores da opção appendfsync , Mas em termos de segurança, sempre também é o mais seguro, pois mesmo que haja uma falha e desligamento, a persistência AOF só perderá os dados de comando gerados em um loop de eventos.
2. Quando o valor de appendfsync é everysec, o servidor grava todo o conteúdo do buffer aof_buf no arquivo AOF em cada loop de evento e sincroniza o arquivo AOF no thread filho a cada segundo. Em termos de eficiência, o modo everysec é rápido o suficiente, e mesmo se houver um tempo de inatividade, o banco de dados perde apenas um segundo de dados de comando.
3. Quando o valor de appendfsync for no, o servidor gravará todo o conteúdo do buffer aof _buf no arquivo AOF em cada loop de evento.Quanto a sincronizar o arquivo AOF, ele é controlado pelo sistema operacional. Como as chamadas de flushAppendonlyFile em nenhum modo não precisam realizar operações de sincronização, a velocidade de gravação do arquivo AOF nesse modo é sempre a mais rápida, mas como esse modo acumula dados de gravação no cache do sistema por um período de tempo, este modo A sincronização única a duração de é geralmente a mais longa entre os três modos. Do ponto de vista da operação amortizada, a eficiência do modo no e do modo everysec é semelhante, quando ocorre uma falha, o servidor que usa o modo no perde todos os dados do comando de escrita após a última sincronização do arquivo AOF.

Carregamento e restauração de dados de arquivos AOF

Como o arquivo AOF contém todos os comandos de gravação necessários para reconstruir o estado do banco de dados, o servidor só precisa ler e executar novamente os comandos de gravação salvos no arquivo AOF para restaurar o estado do banco de dados antes que o servidor seja encerrado.

As etapas detalhadas para o Redis ler o arquivo AOF e restaurar o estado do banco de dados são as seguintes:

• Crie um cliente falso sem uma conexão de rede (cliente falso): porque os comandos do Redis só podem ser executados no contexto do cliente e os comandos usados ​​ao carregar o arquivo AOF são derivados diretamente do arquivo AOF em vez da conexão de rede, portanto, o servidor Um pseudo cliente sem uma conexão de rede é usado para executar o comando de gravação salvo no arquivo AOF.O efeito do pseudo cliente executando o comando é exatamente o mesmo que o do cliente com uma conexão de rede.
• Analise e leia um comando de gravação do arquivo AOF.
• Use o pseudo cliente para executar o comando de leitura.
• Continue a executar as etapas 2 e 3 até que todos os comandos de gravação no arquivo AOF tenham sido processados.

Depois de concluir as etapas acima, o estado do banco de dados salvo no arquivo AOF será completamente restaurado.

AOF reescrever

Como a persistência AOF registra o estado do banco de dados salvando os comandos de gravação que são executados, conforme o tempo de execução do servidor passa, o conteúdo no arquivo AOF se tornará mais e mais, e o tamanho do arquivo ficará cada vez maior. Se você controlá-lo, um arquivo AOF muito grande provavelmente afetará o servidor Redis e até mesmo todo o computador host. Quanto maior o arquivo AOF, mais tempo leva para restaurar os dados usando o arquivo AOF.
Por exemplo:

apenas para registrar o estado da chave da lista, o arquivo AOF precisa salvar seis comandos.

Para o nível de aplicativo real, o número e a frequência de execução do comando de gravação serão muito maiores do que o exemplo simples acima, portanto, o problema será muito mais sério.

Para resolver o problema de expansão do volume do arquivo AOF, o Redis fornece a função de reescrita (reescrita) de arquivo AOF. Com esta função, o servidor Redis pode criar um novo arquivo AOF para substituir o arquivo AOF existente. Os arquivos AOF novos e antigos têm o mesmo status de banco de dados, mas o novo arquivo AOF não conterá comandos redundantes que desperdiçam espaço, então o novo O volume do arquivo AOF geralmente é muito menor do que o volume do arquivo AOF antigo.

Implementação de regravação de arquivo AOF:
embora o Redis nomeie a função de geração de novos arquivos AOF para substituir arquivos AOF antigos como "regravação de arquivo AOF", na verdade, a regravação de arquivo AOF não requer qualquer leitura de arquivos AOF existentes, análise ou operação de gravação, esta A função é realizada lendo o status atual do banco de dados do servidor. Considere tal situação, se o servidor executar os seguintes comandos na chave da lista:

Para salvar o estado atual da chave da lista, o servidor deve gravar seis comandos no arquivo AOF.

Se o servidor deseja registrar o estado da chave da lista com o mínimo de comandos possível, a maneira mais simples e eficiente não é ler e analisar o conteúdo do arquivo AOF existente, mas ler o valor da lista de chaves diretamente do o banco de dados e, em seguida, use A RPUSH list "c" "D" "E" "F" O comando "G" é usado para substituir os seis comandos salvos no arquivo AOF, de modo que o número de comandos necessários para salvar a chave da lista pode ser reduzido de seis para um.

O Redis coloca o programa de reescrita AOF no subprocesso para execução, que pode atingir dois objetivos ao mesmo tempo:

• Enquanto o processo filho está realizando a regravação de AOF, o processo do servidor (processo pai) pode continuar a processar solicitações de comando.
• O processo filho possui uma cópia de dados do processo servidor, e o processo filho é usado em vez do encadeamento para garantir a segurança dos dados, evitando o uso de bloqueios.

Buffer de reescrita AOF

No entanto, há um problema que precisa ser resolvido ao usar subprocessos. Durante a reescrita AOF do subprocesso, o processo do servidor ainda precisa continuar a processar solicitações de comando e novos comandos podem modificar o estado do banco de dados existente, tornando o servidor atual O status do banco de dados é inconsistente com o status do banco de dados salvo no arquivo AOF reescrito.

Para resolver esse problema de inconsistência de dados, o servidor Redis configura um buffer de reescrita AOF. Esse buffer é usado depois que o servidor cria um processo filho. Quando o servidor Redis executa um comando de gravação, ele também envia o comando de gravação para AOF buffer e buffer de reescrita AOF, conforme mostrado na figura.
Isso significa que durante a reescrita AOF realizada pelo processo filho, o processo do servidor precisa realizar as três tarefas a seguir:

• Execute o comando enviado pelo cliente.
• Anexe o comando de gravação executado ao buffer AOF.
• Anexe o comando de gravação executado ao buffer de reescrita AOF.

Desta forma, você pode garantir:

• O conteúdo do buffer AOF será periodicamente gravado e sincronizado com o arquivo AOF, e o processamento do arquivo AOF existente continuará normalmente.

• A partir da criação do processo filho, todos os comandos de gravação executados pelo servidor serão gravados no buffer de reescrita AOF.

Quando o processo filho concluir o trabalho de reescrita AOF, ele enviará um sinal ao processo pai. Depois de receber o sinal, o processo pai chamará uma função de processamento de sinal e realizará as seguintes tarefas:

• Grave todo o conteúdo do buffer de reescrita AOF no novo arquivo AOF. Neste momento, o status do banco de dados salvo no novo arquivo AOF será consistente com o status do banco de dados atual do servidor.

• Renomeie o novo arquivo AOF, substitua atomicamente o arquivo AOF existente e conclua a substituição dos arquivos AOF novos e antigos.

por exemplo:

• Quando o processo filho começa a ser reescrito, há apenas uma chave k1 no banco de dados do processo do servidor (processo pai). Quando o processo filho conclui a reescrita do arquivo AOF, há três novas chaves k2, k3 e k4 no banco de dados do processo do servidor.
• Depois que o processo filho envia um sinal para o processo do servidor, o processo do servidor anexa os três comandos chave k2, k3 e k4 gravados no buffer de reescrita AOF ao final do novo arquivo AOF e, em seguida, substitui o antigo AOF pelo novo Arquivo AOF Arquivo, conclua a operação de regravação em segundo plano do arquivo AOF.

O acima é a reescrita do plano de fundo AOF, que é o princípio de realização do comando BGREWRITEAOF .

Resumindo

• O arquivo AOF registra o status do banco de dados do servidor salvando todas as solicitações de comando de gravação para modificar o banco de dados.
• Todos os comandos no arquivo AOF são salvos no formato do protocolo de solicitação de comando do Redis.
• A solicitação de comando será primeiro armazenada no buffer AOF e depois gravada e sincronizada periodicamente com o arquivo AOF.
• Os diferentes valores da opção appendfsync têm um grande impacto na segurança da função de persistência AOF e no desempenho do servidor Redis.
• Contanto que o servidor carregue pessoas e execute novamente os comandos salvos no arquivo AOF, o estado original do banco de dados pode ser restaurado.
• A regravação de AOF pode gerar um novo arquivo AOF. Este novo arquivo AOF tem o mesmo status de banco de dados que o arquivo AOF original, mas tem um tamanho menor.
• A reescrita de AOF é um nome ambíguo. Esta função é realizada lendo pares de valores-chave no banco de dados. O programa não precisa ler, analisar ou gravar nenhum arquivo AOF existente.
• Ao executar o comando BGREWRITEAOF, o servidor Redis manterá um buffer de reescrita AOF, que registrará todos os comandos de gravação executados pelo servidor durante a criação de um novo arquivo AOF pelo processo filho. Quando o processo filho terminar de criar o novo arquivo AOF, o servidor acrescentará todo o conteúdo do buffer de reescrita ao final do novo arquivo AOF, para que os status do banco de dados salvos nos arquivos AOF novos e antigos sejam consistentes. Por fim, o servidor substitui o arquivo AOF antigo pelo novo arquivo AOF para concluir a operação de regravação do arquivo AOF.