Alta disponibilidade e persistência do Redis

1. Alta disponibilidade do Redis

1. Conceito

  Em servidores web, alta disponibilidade refere-se ao tempo em que o servidor pode ser acessado normalmente, e a medida é quanto tempo o serviço normal pode ser fornecido (99,9%, 99,99%, 99,999%, etc.). No entanto, no contexto do Redis, o significado de alta disponibilidade parece ser mais amplo. Além de garantir o fornecimento de serviços normais (como separação mestre-escravo, tecnologia de recuperação rápida de desastres), também é preciso considerar a expansão de capacidade de dados e segurança de dados sem perda.

2. Tecnologia de alta disponibilidade e sua função

  No Redis, as tecnologias para alcançar alta disponibilidade incluem principalmente persistência , replicação mestre-escravo , sentinelas e clusters .

2.1 Persistência

  A persistência é o método mais simples de alta disponibilidade (às vezes nem mesmo classificado como um meio de alta disponibilidade). A principal função é o backup de dados, ou seja, armazenar dados no disco rígido para garantir que os dados não sejam perdidos devido à saída do processo.

2.2 Replicação mestre-escravo

  A replicação mestre-escravo é a base do Redis altamente disponível, e sentinelas e clusters são baseados na replicação mestre-escravo para alcançar alta disponibilidade. A replicação mestre-escravo implementa principalmente backup de dados em várias máquinas, bem como balanceamento de carga para operações de leitura e recuperação de falhas simples.

  Defeitos: A recuperação de falhas não pode ser automatizada; as operações de gravação não podem ter balanceamento de carga; a capacidade de armazenamento é limitada por uma única máquina.

2.3 Sentinelas

  Com base na replicação mestre-escravo, o Sentinel implementa a recuperação automática de falhas.

  Defeitos: As operações de gravação não podem ter balanceamento de carga; a capacidade de armazenamento é limitada por uma única máquina.

2.4 Agrupamento

  Por meio do clustering, o Redis resolve o problema de que as operações de gravação não podem ter balanceamento de carga e a capacidade de armazenamento é limitada por uma única máquina e realiza uma solução de alta disponibilidade relativamente completa.

2. Persistência do Redis

1. Função de persistência

  Redis é um banco de dados na memória e os dados são armazenados na memória. Para evitar a perda permanente de dados após o processo Redis sair anormalmente devido a falha de energia do servidor e outros motivos, é necessário salvar periodicamente os dados em Redis da memória de alguma forma (dados ou comandos) para o disco rígido; quando o Redis reiniciar na próxima vez, use o arquivo persistente para obter a recuperação de dados. Além disso, os arquivos persistentes podem ser copiados para um local remoto para fins de backup de desastres.

2. Método de persistência do Redis

	Persistência RDB (Redis DataBase)	Persistência AOF (anexar somente arquivo)
princípio	Salve os registros do banco de dados Reids na memória para o disco em intervalos regulares. Semelhante a como as máquinas virtuais tiram instantâneos.	Grave o log de operação de Reids no arquivo no modo de acréscimo. Semelhante ao binlog do MySQL.
desempenho

  Como o desempenho em tempo real da persistência AOF é melhor, ou seja, menos dados são perdidos quando o processo sai inesperadamente, então AOF é atualmente o método de persistência mainstream, mas a persistência RDB ainda tem seu lugar.

3. Persistência RDB

1. Visão Geral

A persistência RDB refere-se a salvar o instantâneo dos dados no processo atual na memória no disco rígido dentro de um intervalo de tempo especificado (por isso também é chamado de persistência de instantâneo), armazenado em compactação binária e o sufixo do arquivo salvo é rdb ; quando o Redis for reiniciado, você pode ler o arquivo de instantâneo para restaurar os dados.

2. Condições de gatilho

O acionamento da persistência RDB é dividido em dois tipos: acionamento manual e acionamento automático.

2.1 Gatilho manual

Tanto o comando save quanto o comando bgsave podem gerar arquivos RDB.

O comando salvar bloqueará o processo do servidor Redis até que o arquivo RDB seja criado. Durante o bloqueio do servidor Redis, o servidor não pode processar nenhuma solicitação de comando.

O comando bgsave cria um processo filho, que é responsável por criar o arquivo RDB, e o processo pai (ou seja, o processo principal do Redis) continua a processar as solicitações.

Durante a execução do comando bgsave, apenas o processo filho fork irá bloquear o servidor, e para o comando save, todo o processo irá bloquear o servidor, então save foi basicamente abandonado, e o uso de save deve ser eliminado no online ambiente! ! !

2.2 Gatilho Automático

Ao acionar automaticamente a persistência RDB, o Redis também escolherá bgsave em vez de salvar para persistência.

#通过配置设置触发
save m n

#自动触发最常见的情况是在配置文件中通过save m n，指定当m秒内发生n次变化时，会触发bgsave。
vim /usr/local/redis/conf/redis.conf

#-----443行--以下三个save条件满足任意一个时，都会引起bgsave的调用
# save 3600 1 300 100 60 10000
save 900 1 ：当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave
save 300 10 ：当时间到300秒时， 如果redis数据发生了至少10次变化，则执行bgsave
save 60 10000 ：当时间到60秒时，如果redis数据发生了至少10000次变化， 则执行bgsave

#-----242行--是否开启RDB文件压缩

rdbcompression yes

2.3 Outros mecanismos de envio automático

Além do save mn, existem algumas outras situações que acionam o bqsave, por exemplo:

• No cenário de replicação mestre-escravo, se o nó escravo executar uma operação de cópia completa, o nó mestre executará o comando bgsave e enviará o arquivo rdb para o nó escravo.
• Quando o comando shutdown é executado, a persistência RDB é executada automaticamente.

3. Processo de execução

(1) O processo-pai do Redis julga primeiro: se está sendo executado atualmente save, ou o processo-filho de bgsave/ , se estiver em execução, o comando bgsave retorna diretamente. Os processos filhos de / não podem ser executados ao mesmo tempo, principalmente com base em considerações de desempenho: dois processos filhos simultâneos executam um grande número de operações de gravação em disco ao mesmo tempo, o que pode causar sérios problemas de desempenho.bgrewriteaofbgsavebogrewriteaof

(2) O processo pai executa a operação fork para criar um processo filho. Durante esse processo, o processo pai é bloqueado e o Redis não pode executar nenhum comando do cliente.

(3) Após a bifurcação do processo pai, bgsaveo comando retorna " Background saving started" informações e não bloqueia mais o processo pai e pode responder a outros comandos.

(4) O processo filho cria um arquivo RDB, gera um arquivo de instantâneo temporário com base no instantâneo de memória do processo pai e substitui atomicamente o arquivo original após a conclusão.

(5) O processo filho envia um sinal ao processo pai para indicar a conclusão e o processo pai atualiza as estatísticas.

4. Carregue na inicialização

O carregamento do arquivo RDB é executado automaticamente quando o servidor é iniciado e não há nenhum comando especial. No entanto, como o AOF tem uma prioridade mais alta, quando o AOF está ativado, o Redis priorizará o carregamento de arquivos AOF para restaurar os dados. Somente quando o AOF estiver fechado, o arquivo RDB será detectado e carregado automaticamente quando o servidor Redis for iniciado. O servidor é bloqueado durante o carregamento do arquivo RDB até que o carregamento seja concluído.

Quando o Redis carregar o arquivo RDB, ele verificará o arquivo RDB. Se o arquivo estiver danificado, um erro será impresso no log e o Redis falhará ao iniciar.

[Falha na transferência da imagem do link externo, o site de origem pode ter um mecanismo de link anti-roubo, é recomendável salvar a imagem e carregá-la diretamente (img-eISyZQgT-1688040423867) (C:\Users\86138\AppData\Roaming\Typora \typora-user-images\ imagem-20230629104205320.png)]

4. Persistência de AOF

1. Visão Geral

A persistência RDB é gravar dados de processo em arquivos, enquanto a persistência AOF é gravar cada comando de gravação e exclusão executado pelo Redis em um arquivo de log separado, e a operação de consulta não será gravada; quando o Redis for reiniciado, execute o arquivo AOF novamente no comando para restaurar os dados.

Comparado com o RDB, o AOF tem melhor desempenho em tempo real, tornando-se a solução de persistência dominante.

2. Ligue AOF

O servidor Redis habilita o RDB por padrão e desabilita o AOF; para habilitar o AOF, ele precisa ser configurado no arquivo de configuração.

vim /usr/local/redis/conf/redis.conf

#————1380行————修改，开启AOF
appendonly yes
#————1407行————指定AOE文件名称
appendfilename "appendonly.aof"
#————1505行————是否忽略最后一条可能存在问题的指令
aof-load-truncated yes

systemctl restart redis-server.service

3. Processo de execução

Como cada comando de gravação do Redis precisa ser gravado, o A0F não precisa ser acionado. O processo de execução do AOF é o seguinte:

• Comando anexar (anexar): Anexar o comando Redis write ao buffer aof_ buf;

• Escrita de arquivo (write) e sincronização de arquivo (sync): Sincronize o conteúdo em aof_buf para o disco rígido de acordo com diferentes estratégias de sincronização;

• Reescrita de arquivo (reescrita): reescrever periodicamente o arquivo AOF para atingir o objetivo de compactação.

3.1 Adição de instrução (anexar)

O Redis primeiro anexa o comando de gravação ao buffer em vez de gravar diretamente o arquivo, principalmente para evitar gravar o comando diretamente no disco rígido todas as vezes, fazendo com que o IO do disco rígido se torne o gargalo da carga do Redis.

O formato de comando append é o formato de protocolo da solicitação de comando Redis. É um formato de texto simples , que tem as vantagens de boa compatibilidade, legibilidade forte, processamento fácil, operação simples e evita sobrecarga secundária. No arquivo A0F, exceto o comando select usado para especificar o banco de dados (por exemplo, select 0para selecionar o banco de dados 0), que é adicionado pelo Redis, os demais são todos comandos de gravação enviados pelo cliente.

3.2 Gravação de arquivo (gravação) e sincronização de arquivo (sincronização)

O Redis fornece uma variedade de estratégias de arquivos de sincronização para a área de cache AOF. As estratégias envolvem writeas funções e fsyncfunções do sistema operacional, conforme descrito abaixo:

Para melhorar a eficiência da gravação de arquivos, em sistemas operacionais modernos, quando um usuário chama a função de gravação para gravar dados em um arquivo, o sistema operacional geralmente armazena temporariamente os dados em um buffer de memória. o limite de tempo, os dados no buffer são realmente gravados no disco rígido. fsyncEmbora esse tipo de operação melhore a eficiência, também traz problemas de segurança: se o computador parar, os dados no buffer de memória serão perdidos fdatasync; Grave no disco rígido para garantir a segurança dos dados.

Existem três métodos de sincronização para a estratégia de arquivos de sincronização da área de cache AOF, que são:

• appendfsync always: dispara o tempo todo
• appendfsync no: sem persistência
• appendfsync everysec: Acionado a cada segundo

vim /usr/local/redis/conf/redis.conf

#---1439---
appendfsync always
#解释： 命令写入aof_ buf后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。
#	   这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，
#	   严重降低了Redis的性能；即便是使用固态硬盘(SSD)，每秒大约也只能处理几万个命令，而且会大大降低SSD的寿命。

appendfsync no
#解释： 命令写入aof_ buf后调用系统write操作，不对AOF文件做fsync同步;
#	   同步由操作系统负责，通常同步周期为30秒。这种情况下，文件同步的时间不可控，
#	   且缓冲区中堆积的数据会很多，数据安全性无法保证。

appendfsync everysec
#解释： 命令写入aof_ buf后调用系统write操作，write完成后线程返回; 
#	   fsync同步文件操作由专门的线程每秒调用一次。
#	   everysec是前述两种策略的折中，是性能和数据安全性的平衡，
#	   因此是Redis的默认配置，也是我们推荐的配置。

3.3 Reescrita de arquivo (reescrita)

Com o passar do tempo, o servidor Redis executa cada vez mais comandos de gravação e o arquivo AOF se torna cada vez maior: um arquivo AOF excessivamente grande não apenas afetará a operação normal do servidor, mas também fará com que a recuperação dos dados demore muito .

A regravação de arquivo refere-se à regravação periódica do arquivo AOF para reduzir o tamanho do arquivo AOF. Deve-se observar que a reescrita AOF é para converter os dados no processo Redis em comandos de gravação e sincronizar com o novo arquivo AOF; ele não executará nenhuma operação de leitura ou gravação no arquivo AOF antigo!

Outro ponto a observar sobre regravação de arquivo: Para persistência AOF, a regravação de arquivo é fortemente recomendada, mas não necessária; mesmo sem regravação de arquivo, os dados podem ser persistidos e iniciados no Redis Tempo para importar; portanto, em algumas implementações, a regravação automática de arquivo será desligado e agendado para ser executado em um determinado horário todos os dias por meio de uma tarefa agendada.

A razão pela qual a regravação de arquivos pode compactar arquivos AOF

• Os dados expirados não são mais gravados no arquivo;
• Comandos inválidos não são mais gravados no arquivo: por exemplo, alguns dados são definidos repetidamente ( set mykey v1, set mykey v2), alguns dados são excluídos ( sadd myset v1, del myset), etc.
• Vários comandos podem ser combinados em um: por exemplo sadd myset v1, sadd myset v2, sadd myset vt3 pode ser combinado em um sadd myset v1 v2 v3.

Pelo conteúdo acima, pode-se ver que, como os comandos executados pelo AOF são reduzidos após a regravação, a regravação do arquivo pode não apenas reduzir o espaço ocupado pelo arquivo, mas também acelerar a velocidade de recuperação.

Gatilho de regravação de arquivo

O gatilho de regravação de arquivo pode ser dividido em gatilho manual e gatilho automático.

• Gatilho manual : chame bgrewriteaof o comando diretamente, a execução do comando é bgsaveum pouco semelhante à do subprocesso fork para executar um trabalho específico e ambos são bloqueados apenas quando fork.
• Gatilho automático : Automatize a execução definindo auto-aof-rewrite-min-size opções e opções . Somente quando as duas opções forem atendidas ao mesmo tempo, a reescrita AOF será acionada automaticamente, ou seja, a operação.auto-aof-rewrite-percentage BGREWRITEAOFauto-aof-rewrite-min-size auto-aof-rewrite-percentagebgrewriteaof

vim /usr/local/redis/conf/redis.conf
#----1480----
auto-aof-rewrite-percentage 100
#当前AOF文件大小(即aof_current_size)是上次日志重写时AOF文件大小(aof_base_size)两倍时，发生BGREWRITEAOF操作
auto-aof-rewrite-min-size 64mb
#当前A0F文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWR ITEAOF

4. O processo de regravação de arquivos

Com relação ao processo de regravação de arquivos, há dois pontos que precisam de atenção especial:

• A reescrita é realizada pela bifurcação do processo filho do processo pai;
• O comando de gravação executado por cerdtis durante a reescrita precisa ser anexado ao novo arquivo kac, e o cache aofrewite_buf é introduzido para oedis.

O processo específico é o seguinte:

1. O processo pai do Redis primeiro julga se existe um processo bgsavefilho em execução no momento bgrewriteaof , se existir, bgrewriteaofo comando retornará diretamente, se existir bgsave, o comando será bgsaveexecutado após a conclusão da execução
2. O processo pai executa uma operação de bifurcação para criar um processo filho e o processo pai é bloqueado durante esse processo.
3. • Após a bifurcação do processo pai, bgrewriteaofo comando " Background append only file rewrite started" retorna informações e não bloqueia mais o processo pai, podendo responder a outros comandos. Todos os comandos de gravação do Redis ainda são gravados no buffer AOF e sincronizados com o disco rígido de acordo com a estratégia appendfsync para garantir a correção do mecanismo AOF original.
   • Como a operação fork usa a tecnologia copy-on-write, o processo filho só pode compartilhar os dados da memória durante a operação fork. Como o processo pai ainda está respondendo ao comando, o Redis usa o buffer de reescrita AOF ( aof_rewrite_buf) para salvar essa parte dos dados para evitar a perda dessa parte dos dados durante a geração do novo arquivo AOF. Ou seja, bgrewriteaofdurante a execução, os comandos de gravação do Redis são anexados a aof_ bufdois aof_ rewirte_ bufbuffers ao mesmo tempo.
4. O processo filho grava em um novo arquivo AOF de acordo com as regras de mesclagem de comando de acordo com o instantâneo de memória.
5. • Depois que o processo filho terminar de gravar o novo arquivo AOF, ele enviará um sinal ao processo pai e o processo pai atualizará as informações estatísticas, que podem ser info persistencevisualizadas por meio de .
   • O processo pai grava os dados no buffer de reescrita AOF no novo arquivo AOF, garantindo assim que o estado do banco de dados salvo no novo arquivo AOF seja consistente com o estado atual do servidor.
   • Substitua o arquivo antigo pelo novo arquivo AOF para concluir a reescrita do AOF.

[Falha na transferência da imagem do link externo, o site de origem pode ter um mecanismo de link anti-roubo, é recomendável salvar a imagem e carregá-la diretamente (img-7snIQ0N8-1688040423869) (C:\Users\86138\AppData\Roaming\Typora \typora-user-images\ imagem-20230629120540966.png)]

5. Carregue na inicialização

Quando o AOF estiver ativado, o Redis carregará primeiro o arquivo AOF para restaurar os dados ao iniciar; somente quando o AOF estiver desativado, ele carregará o arquivo RDB para restaurar os dados.

Quando o AOF estiver ativado, mas o arquivo AOF não existir, ele não será carregado mesmo que o arquivo RDB exista.

Quando o Redis carregar o arquivo AOF, ele verificará o arquivo AOF. Se o arquivo estiver danificado, um erro será impresso no log e o Redis falhará ao iniciar. No entanto, se o final do arquivo AOF estiver incompleto (o tempo de inatividade repentino da máquina pode facilmente levar ao final incompleto do arquivo) e o parâmetro aof-load- truncatedestiver ativado, um aviso será gerado no log, o Redis ignora o final do arquivo AOF, e a inicialização é bem-sucedida.

aof-load-truncated O parâmetro é ativado por padrão.

6. Vantagens e desvantagens de RDB e AOF

6.1 Vantagens e desvantagens da persistência RDB

Vantagens : Os arquivos RDB são compactos, de tamanho pequeno, rápidos na transmissão de rede, adequados para cópia completa; a velocidade de recuperação é muito mais rápida que AOF. Obviamente, uma das vantagens mais importantes do RDB em comparação com o AOF é o impacto relativamente pequeno no desempenho.

Desvantagens : A desvantagem fatal dos arquivos RDB é que o método de persistência dos instantâneos de dados determina que a persistência em tempo real não pode ser alcançada. Hoje, quando os dados estão se tornando cada vez mais importantes, uma grande quantidade de perda de dados geralmente é inaceitável, então persistência AOF tornar-se mainstream. Além disso, os arquivos RDB precisam atender a um formato específico e ter baixa compatibilidade (por exemplo, versões antigas do Redis não são compatíveis com novas versões de arquivos RDB). Para persistência RDB, por um lado, o processo principal do Redis será bloqueado quando o bgsave executar a operação de bifurcação; por outro lado, gravar dados no disco rígido pelo processo filho também trará pressão de E/S.

6.2 Vantagens e desvantagens da persistência de AOF

Correspondendo à persistência RDB, a vantagem do AOF é que ele suporta persistência de segundo nível e boa compatibilidade. A desvantagem é que o arquivo é grande, a velocidade de recuperação é lenta e tem um grande impacto no desempenho.

Para persistência de AOF, a frequência de gravação de dados no disco rígido é bastante aumentada (segundo nível na estratégia everysec), a pressão de IO é maior e pode até causar problemas adicionais de bloqueio de AOF.

A reescrita do arquivo AOF é similar ao bgsave do RDB, e haverá bloqueio durante fork e pressão I0 do processo filho. Relativamente falando, como o AOF grava dados no disco rígido com mais frequência, ele terá um impacto maior no desempenho do processo principal do Redis.

Cinco, gerenciamento de desempenho do Redis

1. Veja o uso de memória do Redis

192.168.145.60:7001> info memory

2. Taxa de fragmentação da memória

mem_fragmentation_ratio：内存碎片率。mem_fragmentation_ratio = used_memory_rss / used_memory
used_memory_rss：是Redis向操作系统申请的内存。
used_memory：是Redis中的数据占用的内存。
used_memory_peak：redis内存使用的峰值。

2.1 Como ocorre a fragmentação da memória?

O Redis possui seu próprio gerenciador de memória interna para gerenciar o aplicativo e a liberação de memória para melhorar a eficiência do uso da memória.

Quando o valor no Redis é excluído, a memória não é liberada diretamente e retornada ao sistema operacional, mas ao gerenciador de memória interna do Redis.

Ao solicitar memória no Redis, primeiro verifique se há memória suficiente disponível em seu próprio gerenciador de memória.

Esse mecanismo do Redis melhora a taxa de utilização da memória, mas fará com que alguma memória no Redis não seja usada por si só, mas não seja liberada, resultando em fragmentação da memória.

2.2 Rastreie a taxa de fragmentação da memória

Rastrear a taxa de fragmentação da memória é muito importante para entender o desempenho dos recursos da instância do Redis:

• É normal que a taxa de fragmentação da memória esteja entre 1 e 1,5. Esse valor indica que a taxa de fragmentação da memória é relativamente baixa e também indica que o Redis não troca memória.
• Se a taxa de fragmentação da memória exceder 1,5, significa que o Redis consome 150% da memória física real necessária, dos quais 50% é a taxa de fragmentação da memória.
• Se a taxa de fragmentação da memória for menor que 1, significa que a alocação de memória do Redis excede a memória física e o sistema operacional está trocando memória. Necessidade de aumentar a memória física disponível ou reduzir o uso de memória do Redis.

2.3 Resolver o problema da alta taxa de fragmentação

Se sua versão do Redis for inferior a 4.0, você precisará inserir shutdown saveo comando na ferramenta redis-cli para permitir que o banco de dados Redis execute a operação de salvamento, feche o serviço Redis e reinicie o servidor. Após a reinicialização do servidor Redis, o Redis retornará a memória inútil ao sistema operacional e a taxa de fragmentação cairá.

A partir da versão 4.0 do Redis, é possível desfragmentar a memória online sem reiniciar.

config set activedefrag yes     #自动碎片清理，内存就会自动清理了。
memory purge					#手动碎片清理

3. Uso de memória

Se o uso de memória da instância redis exceder o máximo de memória disponível, o sistema operacional começará a trocar memória e espaço de troca.

3.1 Formas de evitar a troca de memória

• Escolha instalar uma instância do Redis para o tamanho dos dados em cache;
• Use o armazenamento de estrutura de dados Hash tanto quanto possível;
• Defina o tempo de expiração da chave.

4. Chave de recuperação interna

A estratégia de eliminação de dados de memória garante uma alocação razoável de recursos de memória limitados do redis.

Quando o limite máximo definido é atingido, uma estratégia de reciclagem de chave precisa ser selecionada. Por padrão, a estratégia de reciclagem é proibir a exclusão.
Modifique maxmemory-policyo valor do atributo no arquivo de configuração:

vim /usr/local/redis/conf/redis.conf
--1149--
maxmemory-policy noenviction

volátil-lru: use o algoritmo LRU para eliminar dados do conjunto de dados com o tempo de expiração definido (remova a chave usada menos recentemente, para a chave com TTL definido) volátil-ttl: selecione do conjunto de dados com o tempo de expiração definido
Eliminar dados que estão prestes a expirar (remover a chave expirada mais recentemente)
volátil-random: selecionar aleatoriamente os dados do conjunto de dados com um tempo de expiração definido para eliminar (remover aleatoriamente da chave com TTL definido) allkeys-
lru: usar o algoritmo LRU para eliminar dados de todos os conjuntos de dados (remover a chave menos usada, para todas as chaves)
allkeys-random: escolher a eliminação de dados do conjunto de dados aleatoriamente (remover a chave aleatoriamente)
noenviction: proibir a eliminação de dados (não excluir até que um erro seja relatado quando estiver cheio)

Resumir

1. O conceito de recuperação de desastres

É manter os negócios do sistema de sobrevivência funcionando ininterruptamente, garantindo que os dados do sistema de produção sejam perdidos o mínimo possível em caso de desastres naturais, falhas de equipamentos e danos induzidos pelo homem.

2. Método de persistência do Redis

RDB持久化：定时把redis内存中的数据进行快照和压缩保存
		  RDB保存的文件占用空间小，网络传输快，恢复速度比AoF快，但兼容性较差
          RDB持久化期间，在fork子进程时会阻塞父进程，由于是定时持久化，实时性不如AOF
AOF持久化： 以追加的方式将redis写操作的命令记录到文件中，实时性比RDB好
          支持秒级持久化，兼容性较好，缺点持久化文件占用空间较大，恢复速度较慢，对IO性能消耗较大AOF文件重写期间，在fork子进程时会阻塞父进程，且对IO性能消耗更大

3. A diferença entre RDB e AOF

RDB：是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，
     先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
 
AOF：是以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，
     可以打开文件看到详细的操作记录。