Escolhendo a Melhor Estratégia de Persistência do Redis: RDB vs AOF.

O Redis armazena dados em memória, então você precisa de uma estratégia de persistência antes de confiar nele para qualquer coisa que não possa ser facilmente reconstruída. A escolha entre RDB e AOF afeta quantos dados você pode perder, a rapidez com que o Redis reinicia e a quantidade de E/S de disco que sua carga de trabalho gera.

Use RDB quando snapshots periódicos forem suficientes. Use AOF quando precisar de maior durabilidade. Use ambos quando quiser durabilidade prática mais backups fáceis, mas ainda teste a recuperação com seu conjunto de dados real.

Entendendo a Persistência no Redis

Persistência no Redis refere-se à capacidade de salvar o conjunto de dados em memória no disco, para que possa ser recarregado após uma reinicialização ou falha do servidor. Sem persistência, todos os dados armazenados no Redis seriam perdidos se o servidor parar ou falhar. O Redis oferece dois métodos distintos para alcançar isso:

RDB (Redis Database): Um snapshot pontual do seu conjunto de dados.
AOF (Append-Only File): Um log de cada operação de escrita realizada pelo servidor.

Ambos os métodos têm suas próprias características e são adequados para diferentes cenários.

Redis Database (RDB)

A persistência RDB realiza snapshots pontuais do seu conjunto de dados Redis em intervalos especificados. Quando uma operação de salvamento RDB é acionada, o Redis bifurca um processo filho. O processo filho então escreve todo o conjunto de dados em um arquivo RDB temporário. Assim que o arquivo é concluído, o arquivo RDB antigo é substituído pelo novo.

Como o RDB Funciona

Bifurcação: O servidor Redis bifurca um novo processo filho.
Snapshot: O processo filho começa a escrever todo o conjunto de dados em um arquivo RDB temporário.
Conclusão: Quando o processo filho termina de escrever, ele substitui o arquivo RDB antigo pelo novo temporário.
Limpeza: O processo filho é encerrado.

Este processo garante que o Redis possa continuar atendendo solicitações do cliente enquanto o snapshot está sendo tirado, pois o processo pai permanece responsivo.

Vantagens do RDB

Backups Compactos: Os arquivos RDB são compactados em binário, oferecendo uma representação muito compacta do seu conjunto de dados Redis. Isso os torna ideais para backups e recuperação de desastres.
Reinicializações Rápidas: Recarregar um arquivo RDB é significativamente mais rápido do que reproduzir um arquivo AOF, especialmente para grandes conjuntos de dados, pois envolve carregar um único arquivo binário pré-formatado.
E/S de Disco Mínima: Os salvamentos RDB ocorrem apenas em intervalos configurados, o que significa que o Redis realiza E/S de disco mínima quando não está salvando. Isso pode levar a um desempenho mais alto durante operações normais.
Fácil de Transferir: Por ser um único arquivo compacto, os backups RDB são fáceis de transferir para data centers remotos para recuperação de desastres ou fins de arquivamento.

Desvantagens do RDB

Potencial Perda de Dados: A principal desvantagem é o potencial de perda de dados. Se o Redis falhar entre os pontos de salvamento, todos os dados escritos desde o último salvamento RDB bem-sucedido serão perdidos.
Pico de Desempenho durante a Bifurcação: Para conjuntos de dados muito grandes, a operação inicial fork() pode ser lenta e bloquear o servidor Redis por um curto período, especialmente se o uso de memória for alto.
Persistência Não em Tempo Real: O RDB não foi projetado para persistência de dados em tempo real. É mais adequado para cenários onde perder alguns minutos de dados é aceitável.

Configuração do RDB

A persistência RDB é habilitada por padrão no redis.conf usando a diretiva save. Você pode especificar várias regras save:

# Salvar o banco de dados a cada 900 segundos (15 minutos) se pelo menos 1 chave mudou
save 900 1

# Salvar o banco de dados a cada 300 segundos (5 minutos) se pelo menos 10 chaves mudaram
save 300 10

# Salvar o banco de dados a cada 60 segundos se pelo menos 10000 chaves mudaram
save 60 10000

# Desabilitar a persistência RDB (comente todas as diretivas save, ou defina explicitamente abaixo)
# save ""

Você também pode acionar um salvamento RDB manualmente usando os comandos SAVE (bloqueante) ou BGSAVE (não bloqueante) no redis-cli.

Append-Only File (AOF)

A persistência AOF registra cada operação de escrita recebida pelo servidor Redis. Em vez de salvar todo o conjunto de dados periodicamente, o AOF registra os comandos que modificam o conjunto de dados. Quando o Redis reinicia, ele reexecuta esses comandos no arquivo AOF para reconstruir o conjunto de dados original.

Como o AOF Funciona

Registro de Comandos: Cada comando de escrita executado pelo Redis é anexado ao arquivo AOF.
Política fsync: O Redis tem várias políticas fsync para controlar com que frequência o buffer AOF é sincronizado com o disco:
- appendfsync always: Sincroniza após cada comando. Isso oferece a melhor durabilidade, mas é o mais lento.
- appendfsync everysec: Sincroniza uma vez por segundo. Este é um bom equilíbrio entre durabilidade e desempenho (padrão e recomendado).
- appendfsync no: Depende do sistema operacional para liberar o buffer AOF para o disco. Oferece o melhor desempenho, mas a menor durabilidade.
Reescrita AOF: Com o tempo, o arquivo AOF pode crescer muito devido a comandos redundantes (por exemplo, atualizar a mesma chave várias vezes). A reescrita AOF otimiza o arquivo AOF criando um novo arquivo AOF menor contendo apenas os comandos necessários para reconstruir o conjunto de dados atual. Este processo é semelhante ao mecanismo de bifurcação do RDB.

Vantagens do AOF

Melhor Durabilidade: Com appendfsync always ou everysec, o AOF oferece durabilidade mais forte do que os snapshots RDB periódicos. Com everysec, o Redis geralmente limita a perda a cerca de um segundo de gravações confirmadas, embora falhas do sistema operacional ou disco ainda possam afetar a durabilidade.
Menos Perda de Dados: Em caso de falha, você perde significativamente menos dados, se houver, dependendo da sua política fsync.
Formato Inspecionável: O AOF armazena comandos do protocolo Redis, portanto, pode ser inspecionado e reparado com ferramentas Redis mais facilmente do que um arquivo RDB.

Desvantagens do AOF

Tamanho de Arquivo Maior: Os arquivos AOF são geralmente muito maiores do que os arquivos RDB para o mesmo conjunto de dados porque armazenam comandos em vez de dados compactos.
Recuperação Mais Lenta: Reproduzir um grande arquivo AOF na inicialização pode ser mais lento do que carregar um arquivo RDB, pois o Redis precisa executar cada comando.
Impacto no Desempenho: Dependendo da política fsync, o AOF pode introduzir mais E/S de disco, potencialmente impactando o desempenho de gravação. appendfsync always é especialmente impactante.
Sobrecarga de Reescrita AOF: Embora a reescrita AOF ajude a gerenciar o tamanho do arquivo, o próprio processo de reescrita consome recursos de CPU e E/S e pode bloquear momentaneamente o Redis se o conjunto de dados for muito grande, semelhante à bifurcação do RDB.

Configuração do AOF

Para habilitar o AOF, você precisa definir appendonly yes no seu redis.conf:

# Habilitar persistência AOF
appendonly yes

# O nome do arquivo append only (padrão: "appendonly.aof")
appendfilename "appendonly.aof"

# Opções appendfsync: always, everysec, no
appendfsync everysec

# Reescrita automática do arquivo AOF quando ele tem o dobro do tamanho da base e tem pelo menos 64MB
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

RDB vs. AOF: Uma Visão Geral Comparativa

Característica	RDB (Backup do Banco de Dados Redis)	AOF (Arquivo Append-Only)
Mecanismo	Snapshots pontuais (arquivo binário)	Log de operações de escrita no formato do protocolo Redis
Perda de Dados	Perda potencial entre pontos de salvamento	Geralmente cerca de um segundo com `everysec`; mais forte com `always`
Desempenho	Maior desempenho de gravação durante operações normais, bloqueio potencial no `fork()`	Gravações mais lentas com `fsync` forte, E/S mais consistente
Tamanho do Arquivo	Arquivos binários muito compactos	Geralmente maior, cresce com as operações
Tempo de Recuperação	Mais rápido para grandes conjuntos de dados	Mais lento para grandes conjuntos de dados (reproduzindo comandos)
Facilidade de Backup	Arquivo único e compacto; fácil para backups/recuperação de desastres	Arquivo maior, potencialmente mais difícil de gerenciar sem reescrita
Legibilidade	Não legível por humanos	Mais inspecionável que o RDB
Padrão no Redis	Sim (com diretivas `save`)	Não (`appendonly no` por padrão)

A Abordagem Híbrida: RDB e AOF Juntos

O Redis pode usar snapshots RDB e AOF juntos. Quando o AOF está habilitado, o Redis usa o AOF para recuperação na inicialização porque geralmente está mais atualizado. O Redis moderno também pode usar um preâmbulo RDB dentro de arquivos AOF reescritos quando aof-use-rdb-preamble yes está habilitado, o que acelera as reescritas e reinicializações.

Reescritas Mais Rápidas: A parte RDB do AOF híbrido fornece um snapshot inicial muito mais rápido para o processo de reescrita.
Reinicializações Mais Rápidas (Potencialmente): Quando o Redis reinicia, ele primeiro carrega a parte RDB do arquivo AOF, que é mais rápida, e depois reproduz os comandos AOF subsequentes.
Melhor Durabilidade: Ainda se beneficia da perda mínima de dados do AOF.

Verifique sua versão e configuração do Redis antes de assumir que o AOF híbrido está habilitado.

Escolhendo a Estratégia de Persistência Correta

A estratégia de persistência ideal depende dos requisitos específicos da sua aplicação para durabilidade de dados, desempenho e tempo de recuperação.

1. Quando Usar Apenas RDB

Caso de Uso Principal: Cache / Dados Não Críticos: Se o Redis é usado principalmente como um cache onde perder alguns dados em uma falha é aceitável, ou se seus dados podem ser facilmente reconstruídos de outra fonte.
Altos Requisitos de Desempenho: Quando o desempenho de gravação é primordial e a perda ocasional de dados é tolerável.
Backups de Recuperação de Desastres: Os arquivos RDB são excelentes para criar snapshots periódicos para arquivamento de longo prazo ou recuperação de desastres. Você pode usar cron para um BGSAVE e depois mover o arquivo .rdb para fora do local.
Eficiência de Memória: Se você está fortemente limitado em espaço em disco.

2. Quando Usar Apenas AOF

Caso de Uso Principal: Durabilidade Absoluta: Quando cada operação de escrita é crítica e perder até alguns segundos de dados é inaceitável (por exemplo, transações financeiras, dados críticos do usuário). Neste caso, appendfsync always pode ser considerado, embora com um custo de desempenho significativo.
Depuração/Auditoria: A natureza legível por humanos do AOF pode ser benéfica para entender as mudanças nos dados.

3. Quando Usar Ambos RDB e AOF (Recomendado para a Maioria das Aplicações Críticas)

Durabilidade e Recuperação Equilibradas: Esta é geralmente a abordagem recomendada para sistemas de produção onde a durabilidade dos dados é importante, mas você também deseja reinicializações e backups eficientes.
Robustez: Fornece uma camada extra de proteção. Se um método de persistência for corrompido, você ainda pode ser capaz de recuperar com o outro.
AOF Híbrido: Aproveite o formato AOF com preâmbulo RDB onde suportado e habilitado.

Dicas Práticas e Melhores Práticas

Monitore o Uso do Disco: Tanto RDB quanto AOF podem consumir espaço em disco significativo. Monitore seu uso de disco para garantir que você não fique sem espaço, especialmente antes de reescritas AOF ou salvamentos RDB.
Política fsync: Para AOF, appendfsync everysec é a escolha mais comum e recomendada, oferecendo um bom equilíbrio entre durabilidade e desempenho. Evite appendfsync no para dados críticos.
Reescrita AOF: Configure auto-aof-rewrite-percentage e auto-aof-rewrite-min-size cuidadosamente para garantir que os arquivos AOF sejam otimizados regularmente sem consumo excessivo de recursos.
Discos/Locais Separados: Se possível, armazene seus arquivos de persistência (AOF e RDB) em um disco ou partição diferente do seu sistema operacional e logs de aplicativos para evitar contenção de E/S.
Backups Externos: Independentemente da sua estratégia de persistência, faça backup regularmente de seus arquivos RDB e AOF para um local externo (por exemplo, S3, Google Cloud Storage) para uma recuperação robusta de desastres.
Teste a Recuperação: Periodicamente, teste seu processo de recuperação com sua estratégia de persistência escolhida para garantir que os dados possam ser restaurados com sucesso.

Conclusão

Escolha a persistência com base nos requisitos de recuperação, não por hábito. O Redis usado apenas como cache pode frequentemente usar RDB ou nenhuma persistência. O Redis usado para sessões, filas ou estado de aplicativo geralmente precisa de AOF, backups testados e um teste de reinicialização que prove que os dados voltam rápido o suficiente.