O endereço do texto original é atualizado e o efeito de leitura é melhor!
https://www.codermast.com/database/redis/redis-advance-persistence.htmlO problema com o Redis de ponto único
- Problema de perda de dados: o Redis é um armazenamento na memória e os dados podem ser perdidos quando o serviço é reiniciado. Resolvido implementando persistência de dados Redis.
- Problema de simultaneidade: embora a capacidade de simultaneidade do Redis de nó único seja boa, ela não pode satisfazer cenários de alta simultaneidade, como 618. Crie um cluster mestre-escravo para obter separação de leitura e gravação.
- Problema de recuperação de falhas: se o Redis ficar inativo, o serviço ficará indisponível e um método automático de recuperação de falhas será necessário. Aproveite o Redis Sentinel para detecção de integridade e recuperação automática.
- Problema de capacidade de armazenamento: o Redis é baseado em memória e a quantidade de dados que pode ser armazenada em um único ponto é difícil de atender à demanda por dados massivos. Crie um cluster fragmentado e use o mecanismo de slot para obter expansão dinâmica.
# Persistência RDB
O nome completo do RDB é arquivo Redis Database Backup (arquivo de backup de dados Redis), também conhecido como instantâneo de dados Redis. Simplificando, todos os dados na memória são gravados no disco. Quando a instância do Redis falhar e reiniciar, leia o arquivo de instantâneo do disco e restaure os dados.
Os arquivos de instantâneo são chamados de arquivos RDB, que são salvos no diretório em execução atual por padrão.
saveComando: Crie um instantâneo RDB, executado pelo processo principal do Redis, que bloqueará todos os comandos. O RDB precisa ser gravado no disco e as operações de E/S são lentas.bgsaveComando: Inicia o processo filho para executar o RDB para evitar que o processo principal seja afetado.
O RDB será executado uma vez quando o Redis estiver inativo.
Por padrão, um arquivo dump.rdb será gerado no diretório atual. Quando o Redis for iniciado na próxima vez, esse arquivo será carregado por padrão para restaurar os dados do Redis.
O Redis possui um mecanismo interno para acionar o RDB, que pode ser encontrado no arquivo redis.conf no seguinte formato:
<span style="color:#2c3e50"><code>save 900 1 // 900 秒内，如果至少有 1 个 key 被修改，则执行 bgsave
save 300 10 // 300 秒内，如果至少有 10 个 key 被修改，则执行 bgsave
save 60 10000 // 60 秒内，如果至少有 10000 个 key 被修改，则执行 bgsave
save "" // 表示禁用 RDB
rdbcompression yes // 是否压缩，建议不开启，压缩也会消耗 CPU ，磁盘空间相对廉价
dbfilename dump.rdb // RDB 文件名称
dir ./ // 文件保存的路径目录
</code></span>No início do bgsave, o processo principal será bifurcado para obter o processo filho, e o processo filho compartilhará os dados de memória do processo principal. Após a conclusão da bifurcação, leia os dados da memória e grave-os no arquivo RDB.
O processo de bifurcação está bloqueado e o Redis não pode responder às solicitações do cliente no momento. A velocidade do fork é muito rápida, pois o fork copia apenas a tabela de páginas correspondente, em vez de copiar os dados reais, semelhante ao índice que copia apenas os dados.
Fork usa a tecnologia copy-on-write:
- Quando o processo principal executa uma operação de leitura, o acesso à memória compartilhada
- Quando o processo principal executa uma operação de gravação, uma cópia dos dados é copiada e a operação de gravação é executada.
caso extremo
Quando o processo filho grava um novo arquivo RDB, o processo principal modifica uma grande quantidade de dados neste momento, então os dados precisam ser copiados. Quando o processo principal precisa modificar todos os dados, ele precisa do dobro da memória original. Portanto, quando configuramos o serviço Redis, não podemos alocar toda a memória real para o Redis e precisamos reservar uma parte do espaço do buffer.
Resumo da persistência RDB:
O processo de bgsave no modo RDB:
- Fork o processo principal para obter um processo filho, compartilhando espaço de memória
- O processo filho lê os dados da memória e grava novos arquivos RDB
- Substitua arquivos RDB antigos por novos arquivos RDB
Quando o RDB será executado? O que significa salvar 60 1000?
- O padrão é executar o RDB quando o serviço Redis for interrompido.
- salvar 60 10000 significa que o RDB será acionado se pelo menos 1000 modificações forem realizadas em 60 segundos
Desvantagens dos RDBs?
- O intervalo de execução do RDB é longo e há risco de perda de dados entre duas gravações do RDB
- Leva tempo para bifurcar subprocessos, compactar e gravar arquivos RDB
# Persistência AOF
O nome completo do AOF é Append Only File (arquivo anexado). Cada comando de gravação processado pelo Redis será registrado no arquivo AOF, que pode ser considerado como um arquivo de log de comando.
O AOF está desativado por padrão, você precisa modificar o arquivo de configuração redis.conf para ativar o AOF
<span style="color:#2c3e50"><code>appendonly yes // 是否开启 AOF 功能，默认是关闭的
appendfilename "appendonly.aof" // AOF 的文件名称
</code></span>A frequência de gravação do comando AOF também pode ser configurada através do arquivo redis.conf:
<span style="color:#2c3e50"><code>appendfsync always // 表示每执行一次写命令，立刻记录到 AOF 文件中
appendfsync everysec // 写命令执行完先放入 AOF 缓冲区，然后每隔 1 秒将缓冲区数据写入到 AOF 文件，是默认方案
appendfsync no // 写命令执行完先放入 AOF 缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
</code></span>| item de configuração | Tempo de escovação | vantagem | deficiência |
|---|---|---|---|
| Sempre | Disco de pincel sincronizado | Alta confiabilidade, quase nenhuma perda de dados | impacto no desempenho |
| cada segundo | Pincel por segundo | desempenho moderado | Até 1 segundo de perda de dados |
| não | controle do sistema operacional | melhor performance | Baixa confiabilidade, possível perda de grandes quantidades de dados |
AOF é um comando de gravação e o arquivo AOF será muito maior que o arquivo RDB. E o AOF registrará várias operações de gravação na mesma chave, mas apenas a última operação de gravação é significativa. Ao executar o comando bgrewriteaof, o arquivo AOF pode ser reescrito para obter o mesmo efeito com o menor número de comandos.
O Redis também reescreverá automaticamente o arquivo AOF quando o limite for acionado. Limites também podem ser configurados em redis.conf:
<span style="color:#2c3e50"><code>auto-aof-rewrite-percentage 100 // AOF 文件比上次文件增长多少百分比，则触发重写
auto-aof-rewrite-min-size 64mb // AOF 文件体积最小多大以上才触发重写
</code></span># Comparação entre RDB e AOF
RDB e AOF têm suas próprias vantagens e desvantagens.Se os requisitos de segurança de dados forem altos, eles geralmente são usados em combinação no desenvolvimento real.
| Persistência | integridade de dados | Tamanho do arquivo | Velocidade de recuperação do tempo de inatividade | Prioridade de Recuperação de Dados | Uso de recursos do sistema | cenas a serem usadas |
|---|---|---|---|---|---|---|
| RDB | Tire instantâneos de toda a memória em intervalos regulares | Incompleto, perdido entre backups | Haverá compactação, o tamanho do arquivo é pequeno | breve | Baixa porque a integridade dos dados não é tão boa quanto AOF | Consumo alto e pesado de CPU e memória |
| AOF | Registrar cada comando executado | Relativamente completo, dependendo da estratégia de escovagem | Comandos de gravação, o tamanho do arquivo é muito grande | lento | Alto devido à maior integridade de dados | Baixo, principalmente recursos de E/S de disco, mas o AOF ocupará muitos recursos de CPU e memória ao reescrever |