Persistência no Redis: RDB e AOF

1. Introdução à Persistência no Redis

O Redis é amplamente conhecido como um banco de dados in-memory, mas isso não significa que seus dados precisam ser voláteis. Por padrão, o Redis mantém tudo em RAM para oferecer latências de microssegundos, porém, sem persistência, uma reinicialização do servidor resultaria em perda total dos dados. Para cenários onde a durabilidade importa — como cache de consultas SQL lentas, sessões de usuário ou filas de tarefas — o Redis oferece dois mecanismos de persistência: RDB (Redis Database Backup) e AOF (Append-Only File).

A escolha entre RDB e AOF envolve um trade-off clássico entre desempenho e durabilidade. O RDB gera snapshots periódicos do conjunto de dados, sendo mais leve em operação normal, mas sujeito a perda de dados entre snapshots. O AOF registra cada operação de escrita em um log, oferecendo maior durabilidade às custas de maior overhead de I/O. Compreender esses mecanismos é essencial para projetar sistemas que combinem a velocidade do Redis com a confiabilidade esperada de bancos SQL.

2. RDB (Redis Database Backup) — Snapshots Pontuais

O mecanismo RDB salva o estado completo do banco em um arquivo binário chamado dump.rdb. O salvamento ocorre de forma assíncrona através de um processo filho (fork), permitindo que o Redis continue atendendo requisições durante a operação.

Configuração de triggers automáticos no redis.conf:

save 900 1       # Se pelo menos 1 chave mudar em 900 segundos (15 min)
save 300 10      # Se pelo menos 10 chaves mudarem em 300 segundos (5 min)
save 60 10000    # Se pelo menos 10000 chaves mudarem em 60 segundos

Comandos manuais:

  • SAVE — Bloqueante: para todas as operações até finalizar o snapshot.
  • BGSAVE — Não bloqueante: cria um processo filho via fork para salvar.

Vantagens:
- Arquivo compacto, ideal para backups periódicos e transferência para data lakes.
- Excelente performance de leitura, pois carrega todo o dataset de uma vez.
- Não degrada a performance de escrita durante snapshots (com BGSAVE).

Desvantagens:
- Perda potencial de dados entre snapshots (até 15 minutos com configuração padrão).
- Fork pode consumir memória adicional em datasets muito grandes (cópia em escrita).

3. AOF (Append-Only File) — Log de Escrita Contínua

O AOF registra cada comando de escrita (SET, DEL, INCR, etc.) em um arquivo de log sequencial. Durante a recuperação, o Redis reproduz esses comandos para reconstruir o dataset.

Políticas de sincronização (appendfsync):

# redis.conf
appendonly yes
appendfsync everysec   # Recomendado para produção: perda máxima de 1 segundo
# appendfsync always   # Máxima durabilidade, menor throughput
# appendfsync no       # Delega ao SO, maior risco de perda

Reescrita do AOF (BGREWRITEAOF): Para evitar que o arquivo AOF cresça indefinidamente, o Redis reescreve o log mantendo apenas o estado final. Por exemplo, 1000 incrementos em uma chave viram um único SET chave 1000.

Vantagens:
- Durabilidade superior: com everysec, perda máxima de 1 segundo de dados.
- Formato de log legível por humanos, útil para auditoria e debugging.
- Reescrita eficiente que não interrompe operações.

Desvantagens:
- Arquivos maiores que RDB para o mesmo dataset.
- Overhead de I/O em escrita, especialmente com appendfsync always.
- Recuperação mais lenta que RDB, pois precisa reexecutar comandos.

4. Comparação Detalhada: RDB vs. AOF

Característica RDB AOF
Performance de leitura Excelente (carga única) Moderada (replay de comandos)
Performance de escrita Alta (sem log síncrono) Menor (fsync frequente)
Perda máxima de dados Até último snapshot 1 segundo (everysec)
Tamanho em disco Compacto Maior (mesmo após rewrite)
Tempo de recuperação Segundos Dezenas de segundos a minutos
Legibilidade Binário (dump.rdb) Texto (appendonly.aof)

Casos de uso típicos:
- RDB: Backup noturno para data warehouse, cache de consultas SQL analíticas, cenários onde perda de 15 minutos é aceitável.
- AOF: Sessões de usuário, transações de e-commerce, filas de mensagens críticas.

5. Estratégias Híbridas e Configuração Avançada

A recomendação oficial do Redis para produção é ativar ambos os mecanismos simultaneamente. Nesse modo, o Redis prioriza o AOF na recuperação (por ser mais completo), mas mantém o RDB para backups rápidos.

Configuração híbrida no redis.conf:

save 900 1
save 300 10
save 60 10000

appendonly yes
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-use-rdb-preamble yes

O parâmetro aof-use-rdb-preamble (Redis 5+) faz com que o AOF comece com um snapshot RDB, acelerando a recuperação híbrida. A reescrita automática do AOF ocorre quando o arquivo atual (aof_current_size) dobra de tamanho em relação à base (aof_base_size).

6. Monitoramento e Manutenção da Persistência

Ferramentas de verificação de integridade:

# Verificar dump.rdb
redis-check-rdb /var/lib/redis/dump.rdb

# Verificar appendonly.aof (e corrigir se possível)
redis-check-aof --fix /var/lib/redis/appendonly.aof

Métricas importantes via INFO persistence:

rdb_last_save_time: 1698765432      # Timestamp do último RDB bem-sucedido
rdb_last_bgsave_status: ok
aof_current_size: 524288000         # Tamanho atual do AOF em bytes
aof_base_size: 262144000            # Tamanho base após última reescrita
aof_last_rewrite_time_sec: 12       # Tempo da última reescrita

Boas práticas:
- Armazenar RDB/AOF em discos separados do sistema operacional.
- Configurar stop-writes-on-bgsave-error yes para evitar dados inconsistentes.
- Realizar backups manuais periódicos dos arquivos de persistência.

7. Integração com Bancos de Dados Relacionais (SQL)

O Redis frequentemente atua como cache persistente para consultas SQL lentas. A integração entre os mecanismos de persistência do Redis e bancos SQL segue pipelines típicos:

Pipeline de extração SQL → Redis → Persistência híbrida:

1. Consulta SQL pesada (ex: relatório mensal) é executada no PostgreSQL
2. Resultado é armazenado no Redis via SET com TTL (ex: 1 hora)
3. Redis persiste com RDB a cada 5 minutos (backup) + AOF everysec (durabilidade)
4. Em caso de falha do Redis, recupera-se via AOF (perda < 1s)
5. Backup diário do dump.rdb é enviado para storage externo (S3, NFS)

Estratégia de warm-up: Ao reiniciar o Redis após manutenção, o dump.rdb é carregado rapidamente (segundos), restaurando o cache de consultas SQL sem precisar reprocessar as queries originais.

Sincronização com snapshots SQL: Empresas que usam WAL-G (PostgreSQL) ou mysqldump podem alinhar os snapshots RDB do Redis com os backups SQL, garantindo consistência temporal entre cache e banco relacional.

8. Conclusão e Recomendações Finais

A persistência no Redis não é um recurso opcional — é uma decisão arquitetural que impacta diretamente a confiabilidade do sistema. O RDB oferece snapshots compactos e rápidos para recuperação em massa, ideal para cenários analíticos e backups periódicos. O AOF garante durabilidade com perda mínima de dados, essencial para transações críticas. A combinação de ambos, com aof-use-rdb-preamble, representa o estado da arte em persistência Redis.

Checklist para produção:
- [ ] Ativar appendonly yes com appendfsync everysec
- [ ] Configurar saves RDB com intervalos adequados ao volume de dados
- [ ] Habilitar aof-use-rdb-preamble yes
- [ ] Configurar reescrita automática do AOF (100% / 64MB)
- [ ] Monitorar rdb_last_save_time e aof_current_size
- [ ] Testar recuperação completa em ambiente de staging
- [ ] Integrar backup dos arquivos .rdb/.aof com política de retenção

Para aprofundamento, explore temas vizinhos como replicação Redis Sentinel, Redis Streams para mensageria persistente e PgBouncer para pooling de conexões SQL.

Referências