Opções de Persistência no Redis: RDB vs. AOF Explicados

A persistência no Redis determina quantos dados seu servidor Redis pode recuperar após uma reinicialização ou falha. As duas principais opções são snapshots RDB e logs AOF, e a escolha certa depende de quantos dados recentes sua aplicação pode perder.

O Redis mantém os dados na memória para velocidade. A persistência grava estado suficiente no disco para que o Redis possa reconstruir esses dados posteriormente. Você pode usar RDB, AOF, ambos ou nenhum, mas sistemas de produção devem fazer essa escolha deliberadamente.

Entendendo a Persistência no Redis

Persistência no Redis refere-se ao processo de gravar o estado atual do conjunto de dados na memória para o disco. Isso permite que o Redis recarregue os dados quando o servidor reiniciar. Sem persistência habilitada, todos os dados são perdidos ao desligar.

O Redis suporta RDB e AOF simultaneamente, oferecendo uma abordagem híbrida que combina as melhores características de ambos.

Snapshots RDB

RDB cria snapshots pontuais do seu conjunto de dados e os grava em um arquivo binário compacto, comumente chamado de dump.rdb.

Como o RDB Funciona

O RDB normalmente funciona criando um fork do processo Redis. O processo filho grava o conjunto de dados no disco enquanto o pai continua atendendo clientes. Como o RDB é um snapshot, ele captura os dados como existiam em um momento específico.

Configuração e Snapshotting

A configuração do RDB é gerenciada com diretivas save no redis.conf. Essas diretivas definem quando o Redis deve criar um snapshot automático:

# Salvar o BD se 1000 chaves mudarem em 1 minuto
save 600 1000
# Salvar o BD se 10 chaves mudarem em 10 minutos
save 300 10
# Salvar o BD se 10000 chaves mudarem em 1 segundo
save 1 10000

Para desabilitar snapshots RDB automáticos, remova as diretivas save ou defina:

save ""

Você ainda pode acionar um snapshot manual em segundo plano com BGSAVE quando necessário.

Vantagens do RDB

Arquivos compactos: Arquivos RDB são eficientes para backups, cópias e arquivos de recuperação de desastres.
Recuperação rápida: Carregar um snapshot geralmente é mais rápido do que reproduzir um longo log de comandos.
Menor sobrecarga de gravação constante: O Redis não grava cada comando no arquivo de persistência.

Desvantagens do RDB

Risco de perda de dados: Se o Redis falhar entre snapshots, as gravações após o último snapshot bem-sucedido são perdidas.
Sobrecarga de fork: Conjuntos de dados grandes podem tornar fork() caro e causar picos de latência.
Não é um log de auditoria completo: RDB armazena o estado final, não cada gravação que levou a ele.

Logs AOF

AOF (Append-Only File) oferece um nível mais alto de durabilidade de dados. Em vez de snapshots, o AOF registra cada operação de gravação recebida pelo servidor em um formato de apenas anexação.

Como o AOF Funciona

Quando o AOF está habilitado, o Redis registra comandos de gravação como SET, HSET e LPUSH em um arquivo de apenas anexação. Na reinicialização, o Redis reproduz esse arquivo para reconstruir o conjunto de dados.

Configuração do AOF

A persistência AOF está desabilitada por padrão e deve ser explicitamente habilitada no redis.conf:

appendonly yes

Crucialmente, o AOF permite a configuração da política de fsync, determinando com que frequência as gravações são forçadas ao disco:

Política fsync	Descrição	Durabilidade vs. Desempenho
`no`	SO gerencia a sincronização (menos frequente).	Mais rápido, maior risco de perda.
`everysec`	Sincroniza aproximadamente uma vez por segundo.	Bom equilíbrio. Geralmente limita a perda a cerca de um segundo durante uma falha do servidor.
`always`	Sincroniza após cada comando.	Maior durabilidade, impacto potencialmente significativo no desempenho.

Vantagens do AOF

Maior durabilidade: appendfsync everysec é um equilíbrio comum em produção; always é mais rigoroso, mas mais lento.
Intenção legível: AOF armazena comandos de gravação, então pode ser mais fácil de inspecionar do que um arquivo binário RDB.
Compactação automática: A reescrita AOF pode reduzir um log grande aos comandos mínimos necessários para reconstruir o estado atual.

Desvantagens do AOF

Arquivos maiores: Arquivos AOF são frequentemente maiores que snapshots RDB porque armazenam comandos.
Reinicialização mais lenta: Reproduzir um AOF longo pode levar mais tempo do que carregar um snapshot RDB.
Mais sobrecarga de gravação: O Redis precisa anexar comandos de gravação e sincronizá-los de acordo com sua configuração appendfsync.

Reescrita AOF

Para combater o crescimento do tamanho do arquivo, o Redis implementa a reescrita AOF. Este processo cria assincronamente um novo arquivo AOF otimizado contendo apenas os comandos necessários para alcançar o estado atual, descartando efetivamente comandos redundantes ou obsoletos (como múltiplas atualizações para a mesma chave).

RDB vs. AOF: Comparação Direta

Escolher entre RDB, AOF ou ambos depende inteiramente dos requisitos da sua aplicação para tempo de recuperação e tolerância a perda de dados.

Característica	RDB (Snapshotting)	AOF (Append-Only File)
Durabilidade/Perda de Dados	Maior perda potencial de dados (desde o último salvamento).	Perda mínima de dados (até 1 segundo, ou zero com `fsync=always`).
Tamanho do Arquivo	Muito compacto e otimizado.	Maior devido ao registro de comandos.
Tempo de Reinicialização	Carregamento muito rápido do snapshot.	Mais lento, requer reprodução de comandos.
Complexidade	Simples, configurado por intervalos de tempo.	Requer configuração cuidadosa da política `fsync`.
Caso de Uso	Backups, recuperação de desastres onde a perda de dados recentes é tolerável.	Mecanismo de persistência primário que requer alta durabilidade.

Melhor Prática: Combinando RDB e AOF

Para muitas implantações de produção, habilitar tanto RDB quanto AOF oferece uma rede de segurança útil.

Quando ambos estão habilitados:

AOF fornece o log primário de alta durabilidade.
RDB fornece um snapshot de backup rápido e compacto.

Quando ambos estão habilitados, o Redis carrega o AOF na reinicialização porque geralmente é mais completo que o último snapshot RDB. O RDB ainda fornece arquivos de backup compactos que são fáceis de copiar, testar e arquivar.

Como Habilitar Ambos

Certifique-se de que ambas as configurações estão definidas no redis.conf:

# Habilitar AOF
appendonly yes

# Manter configuração RDB (ex.: salvamento automático a cada hora)
save 3600 1

# Política fsync recomendada para AOF
appendfsync everysec

Dica sobre Reescrita AOF: Você pode acionar manualmente uma reescrita AOF a qualquer momento usando o comando BGREWRITEAOF. Isso é especialmente útil após grandes cargas de dados em lote ou operações significativas de limpeza para reduzir imediatamente o tamanho do arquivo AOF.

Conclusão

Use RDB quando quiser backups compactos e puder tolerar a perda de gravações recentes desde o último snapshot. Use AOF quando o Redis armazenar dados que devem sobreviver a falhas com perda mínima. Para dados importantes de produção, habilite AOF com appendfsync everysec, mantenha snapshots RDB para backup e teste o tempo de restauração antes que uma falha force a questão.