índice
Processo de gravação de dados AOF
Três estratégias para dados de gravação AOF (appendfsync)
Configuração relacionada ao AOF
Reescrita manual AOF - como funciona a instrução bgrewriteaof
AOF
Desvantagens do armazenamento RDB
- Grande quantidade de dados armazenados, baixa eficiência
- Com base na ideia do instantâneo, cada leitura e gravação são todos dados, quando a quantidade de dados é enorme, a eficiência é muito baixa
- Baixo desempenho de IO sob grande volume de dados
- Crie um processo filho baseado em fork, consumo de memória adicional
- Risco de perda de dados causada por tempo de inatividade
Soluções
- Não escreva todos os dados, registre apenas parte dos dados
- Reduza a dificuldade de distinguir se os dados foram alterados e altere os dados gravados para o processo de operação de gravação
- Todas as operações são registradas para eliminar o risco de perda de dados
Conceito AOF
- Persistência AOF ( anexar apenas arquivo )
- Grave cada comando de gravação em um log independente e execute novamente os comandos no arquivo AOF ao reiniciar para atingir o objetivo de recuperar dados.
- Comparado com RDB, pode ser simplesmente descrito como o processo de alteração de dados de registro para geração de dados de registro
- A principal função do AOF é resolver o desempenho em tempo real da persistência de dados, sendo atualmente o principal método de persistência do Redis.
Processo de gravação de dados AOF
Três estratégias para dados de gravação AOF (appendfsync)
sempre (toda vez)
- Cada operação de gravação é sincronizada com o arquivo AOF, com zero erro de dados e baixo desempenho
everysec (por segundo)
- Sincronize as instruções no buffer para o arquivo AOF a cada segundo , com alta precisão de dados e alto desempenho
- Perda de dados em 1 segundo no caso de um tempo de inatividade repentino do sistema
não (controle do sistema)
- O sistema operacional controla o ciclo de cada sincronização com o arquivo AOF, e o processo geral é incontrolável
Função AOF ativada
- Se deve abrir a função de persistência AOF, o padrão não é aberto
- Estratégia de gravação de dados AOF
Configuração relacionada ao AOF
- Nome do arquivo persistente AOF, o nome do arquivo padrão não é appendonly.aof, é recomendado configurar appendonly-port number.aof
- O caminho de salvamento do arquivo persistente AOF é consistente com o arquivo persistente RDB.
Exemplo
Problemas encontrados na gravação de dados AOF
- O que fazer se os seguintes comandos forem executados continuamente
AOF reescrever
- Conforme os comandos continuam a ser gravados em AOF, o arquivo ficará cada vez maior. Para resolver esse problema, o Redis apresenta o mecanismo de reescrita AOF para compactar o tamanho do arquivo. O arquivo AOF reescrever os dados no Redis é o processo de gravação de um novo comando para sincronizar o arquivo AOF.
- O comando será simplesmente uma pluralidade de peças do mesmo nó de execução de dados se o resultado final for convertido em dados correspondentes à instrução de gravação.
Função de reescrita AOF
- Reduza o uso do disco e melhore a utilização do disco
- Melhore a eficiência da persistência, reduza o tempo de gravação da persistência e melhore o desempenho do IO
- Reduza o tempo de recuperação de dados e melhore a eficiência da recuperação de dados
Regras de reescrita AOF
- Os dados que expiraram no processo não são mais gravados no arquivo
- Ignore as instruções inválidas e use dados em processo para gerar diretamente ao reescrever, de modo que o novo arquivo AOF retenha apenas o comando de gravação de dados final
- 如 del key1 、 hdel key2 、 srem key3 、 set key4 111 、 set key4 222 等
- Combine vários comandos de gravação para os mesmos dados em um comando
- Por exemplo, lpush list1 a, lpush list1 b, lpush list1 c podem ser transformados em: lpush list1 abc.
- A fim de evitar o estouro do buffer do cliente causado pelo volume excessivo de dados, para lista, conjunto, hash, zset e outros tipos, cada instrução pode escrever até 64 elementos
Método de reescrita AOF
auto-aof-reescrita-min-o tamanho da
auto-aof-reescrita-percentual percentagem
Exemplo
- Arquivo de configuração
- Operação de reescrita
- Ver log
Reescrita manual AOF - como funciona a instrução bgrewriteaof
Método de reescrita automática AOF
- Substituir automaticamente a configuração da condição do acionador
auto-aof-rewrite-min-size size auto-aof-rewrite-percentage percent
- Reescrever automaticamente os parâmetros de comparação do acionador (execute o comando info Persistence para obter informações específicas)
aof_current_size aof_base_size
- Condições de disparo de reescrita automática
Exemplo
- Insira informações para ver as informações
Fluxo de trabalho AOF
- Observação: execute a reescrita para iniciar um processo principal sozinho
- Estratégia de arquivo de sincronização de buffer AOF, controlada pelo parâmetro appendfsync
- Gravação de chamada de sistema e descrição de fsync:
- A operação de gravação irá acionar o mecanismo de gravação atrasada . O Linux fornece um buffer de página no kernel para melhorar o desempenho de E / S do disco rígido.
- A operação de gravação retorna diretamente após a gravação no buffer do sistema.
- A operação síncrona do disco rígido depende do mecanismo de agendamento do sistema, como: o espaço da página do buffer está cheio ou atinge um período de tempo específico. Antes de sincronizar os arquivos, se o sistema falhar e ficar inativo neste momento, os dados no buffer serão perdidos.
- Para uma operação de arquivo único (como arquivo AOF), o fsync executa a sincronização forçada do disco rígido. O Fsync irá bloquear até que o disco rígido seja gravado no disco rígido e retorne, garantindo a persistência dos dados.
- Além de write, fsync e Linx, ele também fornece operações de sincronização e fdatasync:
A diferença entre RDB e AOF
Escolha de RDB e AOF
- Muito sensível aos dados, é recomendável usar o esquema de persistência AOF padrão
- A estratégia de persistência AOF usa everysecond, fsync uma vez a cada segundo. Essa estratégia redis ainda pode manter um bom desempenho de processamento. Quando ocorre um problema, os dados em 0-1 segundos podem ser perdidos no máximo.
- Observação: devido ao grande volume de armazenamento de arquivos AOF, a velocidade de recuperação é lenta
- A validade da fase de apresentação dos dados, recomenda-se a utilização do esquema de persistência RDB
- Os dados podem ser bem garantidos de que não há perda no estágio (o estágio é mantido manualmente pelo desenvolvedor ou pelo pessoal de operação e manutenção), e a velocidade de recuperação é relativamente rápida. A recuperação de dados do ponto do estágio geralmente adota o esquema RDB
- Observação: o uso de RDB para obter persistência de dados compactos tornará o Redis muito baixo. Resuma com atenção:
- Comparação abrangente
- A escolha entre RDB e AOF é na verdade uma troca, cada um dos quais tem vantagens e desvantagens
- Se você não consegue suportar a perda de dados em alguns minutos e é muito sensível aos dados de negócios, escolha AOF
- Se você puder suportar a perda de dados em alguns minutos e buscar a velocidade de recuperação de grandes conjuntos de dados, escolha RDB
- RDB para recuperação de desastres
- Estratégia de seguro duplo, abrir RDB e AOF ao mesmo tempo, após reiniciar o Redis dará prioridade ao uso de AOF para recuperação de dados, reduzindo a quantidade de dados perdidos
- [Nota]: Consulte o tutorial Dark Horse Redis: https://www.bilibili.com/video/BV1AE411j7Wq?t=5