A diferença entre o mecanismo de persistência do Redis RDB e AOF

O Redis oferece suporte a duas formas de persistência, uma é RDB e a outra é AOF. Um deles pode ser usado sozinho ou os dois podem ser usados ​​em combinação.

 

Resumo online


Instantâneo de memória RDB , pode ser definido no redis

save 900 1 (1 operação de redis em 900s fará uma persistência)
save 300 10 (10 operações de redis em 300s farão uma persistência)
save 60 10000 (10.000 operações de redis em 60s farão uma persistência)
    
    Benefícios: O desempenho é melhor que AOF. Existem muitas
    desvantagens: pode haver perda de dados. Por exemplo: 11:05 minutos para persistir uma vez, se o redis morrer às 11:04, os quatro minutos de
    dados serão perdidos

AOF (Anexar somente arquivo)
anexa todas as operações de alterações do redis (adição, exclusão, modificação) ao arquivo de log.
    Vantagens: relativamente seguro, mesmo se o redis estiver inativo, os dados originais podem ser restaurados rapidamente.
    Desvantagens: afetará o desempenho do redis

 Um, RDB

A persistência do método RDB é realizada por meio de snapshot. Quando certas condições são atendidas, o Redis automaticamente faz um snapshot de todos os dados da memória e o armazena no disco rígido . As condições para obter um instantâneo podem ser personalizadas pelo usuário no arquivo de configuração e consistem em dois parâmetros: a hora e o número de chaves alteradas . Um instantâneo será tirado quando o número de chaves alteradas dentro do tempo especificado for maior que o valor especificado . RDB é o método de persistência padrão adotado pelo Redis, e 3 condições foram predefinidas no arquivo de configuração:

save 900 1

save 300 10

save 60 10000

O parâmetro save especifica as condições do instantâneo, pode haver várias condições e a relação entre as condições é "ou".

Conforme mencionado acima, salvar 900 1 significa tirar um instantâneo se pelo menos uma chave for alterada em 15 minutos (900 segundos). Se você deseja desativar os instantâneos automáticos, você só precisa excluir alguns parâmetros de salvamento.

Por padrão, o Redis armazenará o arquivo de instantâneo no arquivo dump.rdb no diretório atual.Você pode configurar o caminho de armazenamento e o nome do arquivo de instantâneo configurando os dois parâmetros dir e dbfilename.

O processo de implementação do mecanismo de instantâneo é o seguinte:

  (1) O Redis usa a função fork para fazer uma cópia (processo filho) do processo atual (processo pai);

  (2) O processo pai continua a receber e processar os comandos enviados pelo cliente, e o processo filho começa a gravar os dados da memória no arquivo temporário do disco rígido;

  (3) Quando o processo filho terminar de gravar todos os dados, ele substituirá o antigo arquivo temporário RDB pelo arquivo, e a operação de captura instantânea agora está concluída.

Quando a bifurcação é executada, o sistema operacional (sistema operacional tipo Unix) usará a estratégia de cópia na gravação, ou seja, quando a função bifurcação ocorre, os processos pai e filho compartilham os mesmos dados de memória, e quando o pai processo deseja alterar uma parte dos dados (como executar um comando de gravação), o sistema operacional fará uma cópia da parte dos dados para garantir que os dados do processo filho não sejam afetados, para que o novo arquivo RDB armazene a memória dados no momento em que a bifurcação é executada. Além de instantâneos automáticos, você também pode enviar manualmente os comandos SAVE ou BGSAVE para fazer o Redis executar instantâneos. A diferença entre os dois comandos é que o primeiro é o processo principal para operações de instantâneo, que bloqueará outras solicitações, e o último executará operações de instantâneo por meio de subprocessos bifurcados.

A persistência é obtida por meio do RDB. Assim que o Redis for encerrado de forma anormal, todos os dados alterados após o último instantâneo serão perdidos. Precisamos definir o tempo de salvamento automático do instantâneo de acordo com os requisitos.

2. AOF

Por padrão, o Redis não habilita a persistência AOF (anexar apenas o arquivo). Você pode passar o parâmetro appendonly

Ligar:

append apenas sim

Depois de abrir o AOF, cada um realiza uma alteração persistente nos comandos do Redis de dados, o Redis será o comando gravado no arquivo AOF do disco rígido. [Somente para instruções de gravação de dados]    O local de salvamento do arquivo AOF é o mesmo que o local do arquivo RDB, que é definido pelo parâmetro dir. O nome do arquivo padrão é appendonly.aof, que pode ser modificado pelo parâmetro appendfilename : appendfilename appendonly.aof

À medida que mais e mais comandos são executados, o tamanho do arquivo AOF fica cada vez maior. Mesmo que os dados reais na memória possam não ser muitos, o Redis irá reescrever automaticamente o arquivo AOF sempre que certas condições forem atendidas.

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

O significado do parâmetro de porcentagem de reescrita automática é que quando o tamanho do arquivo AOF atual excede a porcentagem do tamanho do arquivo AOF no momento da última reescrita, ele será reescrito novamente. Se não tiver sido reescrito antes, ele será reescrito na inicialização com base no tamanho do arquivo AOF. O parâmetro auto-aof-rewrite-min-size limita o tamanho mínimo do arquivo AOF que pode ser reescrito. Normalmente, não nos importamos muito com o arquivo AOF, mesmo se houver muitos comandos redundantes nele quando o arquivo AOF for pequeno. Além de permitir que o Redis execute a regravação automaticamente, também podemos usar ativamente o comando BGREWRITEAOF para realizar manualmente a regravação AOF

Deve-se observar que embora o AOF registre o comando no arquivo AOF toda vez que a operação de alteração do conteúdo do banco de dados for executada, na verdade, devido ao mecanismo de cache do sistema operacional, os dados não são realmente gravados no disco disco, mas entrou no cache do disco rígido do sistema. Por padrão, o sistema executará uma operação de sincronização a cada 30 segundos para realmente gravar o conteúdo do cache do disco rígido no disco rígido. Durante esses 30 segundos, se o sistema sair de forma anormal, os dados no cache do disco rígido serão perdidos. De modo geral, os aplicativos que permitem a persistência de AOF não podem tolerar essas perdas. Isso exige que o Redis solicite ativamente que o sistema sincronize o conteúdo armazenado em cache com o disco rígido após gravar o arquivo AOF. No Redis, podemos definir o tempo de sincronização por meio do parâmetro appendfsync:

# appendfsync always

appendfsync everysec

# appendfsync no

Por padrão, o Redis usa a regra everysec, ou seja, uma operação de sincronização é realizada a cada segundo. sempre significa que a sincronização será realizada toda vez que uma gravação for realizada, que é a maneira mais segura e lenta. não significa que a operação de sincronização não é executada ativamente, mas é totalmente entregue ao sistema operacional (ou seja, uma vez a cada 30 segundos), que é a maneira mais rápida, mas menos segura. Em geral, é suficiente usar o valor padrão de everysec, que leva em consideração o desempenho e a segurança.

O Redis permite que AOF e RDB sejam ativados ao mesmo tempo, o que não apenas garante a segurança dos dados, mas também facilita a execução de backups e outras operações. Neste momento, após reiniciar o Redis, o Redis usará o arquivo AOF para recuperar os dados, pois a persistência do método AOF pode perder menos dados.



 

Acho que você gosta

Origin blog.csdn.net/qq_27828675/article/details/102471724
Recomendado
Clasificación