Comparando as Trocas de Desempenho de Persistência AOF vs. RDB

O Redis é conhecido por sua velocidade vertiginosa, frequentemente alcançando latência sub-milissegundo. No entanto, quando a persistência é ativada — permitindo que os dados sejam salvos em disco para recuperação após uma reinicialização — os desenvolvedores devem escolher um mecanismo. Os dois principais métodos de persistência no Redis são o Snapshotting (RDB) e o Append-Only File (AOF). Compreender as implicações de desempenho, as características de durabilidade e as trocas de configuração de cada um é crucial para ajustar o Redis de modo a atender aos requisitos específicos da aplicação em termos de velocidade versus segurança dos dados.

Este guia examina minuciosamente o RDB e o AOF, detalhando como eles operam, suas respectivas pegadas de desempenho na latência e fornecendo insights práticos para a escolha da estratégia de persistência correta para suas implantações Redis de alto desempenho.

Entendendo a Persistência do Redis

O Redis armazena todo o seu conjunto de dados em memória volátil. Mecanismos de persistência são necessários para mover esses dados para o disco, para que o Redis possa recarregar o conjunto de dados após uma reinicialização, garantindo a disponibilidade dos dados em interrupções ou reinicializações do serviço. Tanto o RDB quanto o AOF alcançam esse objetivo por meio de abordagens fundamentalmente diferentes, levando a perfis de desempenho distintos.

1. Snapshotting (RDB) do Banco de Dados Redis

O RDB cria um snapshot compacto e pontual de todo o conjunto de dados em intervalos especificados. Ele salva esses dados em um arquivo binário (dump.rdb).

Como o RDB Funciona e Seu Impacto no Desempenho

A persistência RDB depende muito do comando BGSAVE (Salvar em Segundo Plano). Quando um salvamento é acionado:

Forking (Bifurcação): O Redis bifurca o processo principal em um processo filho.
Snapshotting: O processo filho grava o conjunto de dados inteiro no arquivo RDB no disco.
Thread Principal Não Afetada (Principalmente): A thread principal do Redis continua a atender solicitações de clientes sem ser bloqueada durante a operação de gravação, pois o filho lida com a E/S (I/O) de disco.

Considerações sobre Desempenho:

Latência de Gravação: Geralmente, o RDB tem impacto mínimo na latência de gravação durante a operação de salvamento porque o trabalho é descarregado. O custo de desempenho primário é o pico de CPU e o burst inicial de E/S necessário quando a bifurcação ocorre e durante a gravação do arquivo grande.
Tempo de Recuperação: O RDB carrega muito rapidamente após a reinicialização porque é um único arquivo otimizado, minimizando a latência de recuperação.
Troca de Durabilidade: Se o Redis falhar entre salvamentos agendados (por exemplo, a cada 5 minutos), todas as gravações que ocorreram desde o último salvamento são perdidas. Isso torna o RDB menos durável que o AOF.

Configurando Salvamentos RDB

Os salvamentos RDB são configurados usando a diretiva save no arquivo redis.conf, especificando intervalos de tempo e o número de alterações:

save 900 1     # Salva se 1 chave for alterada em 900 segundos (15 minutos)
save 300 10    # Salva se 10 chaves forem alteradas em 300 segundos (5 minutos)
save 60 10000  # Salva se 10000 chaves forem alteradas em 60 segundos (1 minuto)

2. Persistência Append-Only File (AOF)

O AOF registra toda operação de gravação recebida pelo servidor Redis em um arquivo de log de apenas acréscimo (append-only). Quando o Redis é reiniciado, ele reproduz esses comandos sequencialmente para reconstruir o conjunto de dados.

Como o AOF Funciona e Seu Impacto no Desempenho

Ao contrário do RDB, o AOF se concentra no log transacional. O perfil de desempenho depende muito da política fsync, que dita a frequência com que o Redis força o sistema operacional a gravar dados armazenados em buffer no disco físico.

Políticas Fsync do AOF:

Política	Configuração `appendfsync`	Durabilidade	Impacto no Desempenho
A Cada Segundo	`everysec`	Boa (perde ~1 segundo de dados)	Bom equilíbrio; sobrecarga mínima. Padrão recomendado.
Sem Sincronização	`no`	Ruim (depende do buffer do SO)	Mais rápido; risco máximo de perda de dados em caso de falha do SO.
Sempre	`always`	Excelente (gravação atômica)	Mais lento; aumento significativo da latência devido à E/S de disco obrigatória em cada gravação.

Considerações sobre Desempenho:

Latência de Gravação: Ao usar appendfsync always, cada comando de gravação incorre na latência de uma sincronização de disco, diminuindo significativamente as operações em comparação com RDB ou operações em memória. Usar everysec mitiga isso significativamente ao agrupar fsyncs em lote.
Tempo de Recuperação: Os arquivos AOF podem se tornar grandes e a reprodução de milhões de comandos pode levar mais tempo do que carregar um arquivo RDB compacto, levando a uma latência de recuperação mais alta.
Tamanho do Arquivo: Os arquivos AOF são tipicamente muito maiores do que os arquivos RDB porque armazenam comandos (por exemplo, SET key value) em vez do estado final da estrutura de dados.

Habilitando e Configurando AOF

O AOF é desativado por padrão e é ativado configurando appendonly yes em redis.conf. A configuração crucial é appendfsync:

appendonly yes
appendfilename "appendonly.aof"
# Configuração recomendada para o equilíbrio entre durabilidade vs. velocidade
appendfsync everysec

Análise das Trocas de Desempenho: AOF vs. RDB

A escolha entre RDB e AOF requer priorizar a velocidade operacional bruta (latência) ou a recuperação de dados garantida.

Latência e Vazão (Throughput)

RDB (Melhor para Velocidade Bruta): Como as gravações são tratadas por um processo em segundo plano, a thread principal do Redis tem um impacto direto mínimo de E/S durante os salvamentos. Isso geralmente resulta em uma latência de gravação geral menor, a menos que o sistema esteja muito carregado quando a bifurcação BGSAVE ocorre.
AOF (modo always): Esta configuração é a mais lenta porque a latência de disco é introduzida diretamente em cada comando de gravação do cliente, levando a latências p99 mais altas.
AOF (modo everysec): Isso fornece um desempenho quase semelhante ao RDB para a maioria das operações, pois as operações de fsync são armazenadas em buffer e são menos frequentes.

Durabilidade e Risco de Perda de Dados

AOF (Melhor para Durabilidade): Oferece a durabilidade mais alta, especialmente com appendfsync always. Mesmo com everysec, a perda de dados é limitada a um segundo.
RDB (Pior para Durabilidade): A perda de dados pode se estender por minutos ou horas, dependendo do agendamento de salvamento.

Tempo de Recuperação

RDB (Recuperação Rápida): Tempos de reinicialização mais rápidos devido ao formato binário otimizado e compacto.
AOF (Recuperação Mais Lenta): A reprodução de um log de comandos grande pode levar mais tempo do que o carregamento de um snapshot, aumentando o tempo de inatividade durante as reinicializações.

Melhores Práticas: Usando Ambos os Métodos de Persistência

Para ambientes que exigem alto desempenho e fortes garantias de durabilidade, a abordagem recomendada é ativar a persistência RDB e AOF simultaneamente.

Quando ambos estão ativados, o Redis usa o arquivo AOF para a reprodução durante a inicialização, a fim de alcançar a máxima consistência dos dados. Ele continua a gerar snapshots RDB periodicamente.

Por que usar ambos?

Recuperação Mais Rápida: Se o arquivo AOF ficar corrompido ou extremamente grande, o Redis pode usar o snapshot RDB mais recente como ponto de partida, acelerando significativamente o processo subsequente de reprodução do AOF.
Eficiência de Reescrita do AOF: O Redis pode acionar automaticamente uma operação de reescrita do AOF (que gera um novo arquivo AOF compacto, descartando comandos redundantes) com base no snapshot RDB mais recente, o que geralmente é mais eficiente do que reescrever apenas a partir do log AOF existente.

Trecho de Configuração para Ambos:

# 1. Habilitar RDB
save 900 1

# 2. Habilitar AOF com sincronização 'everysec'
appendonly yes
appendfsync everysec

Gerenciamento do Tamanho do Arquivo AOF (Reescrita)

Uma preocupação operacional significativa com o AOF é o crescimento do tamanho do arquivo. Com o tempo, o arquivo AOF pode se tornar enorme, pois registra toda modificação, mesmo aquelas que sobrescrevem valores anteriores. Para combater isso, o Redis oferece a reescrita do AOF.

A Reescrita do AOF gera um novo arquivo AOF otimizado que contém apenas o conjunto mínimo de comandos necessários para reconstruir o estado atual do conjunto de dados. Esse processo é acionado automaticamente quando o tamanho do arquivo AOF atual excede um certo múltiplo do tamanho base.

auto-aof-rewrite-percentage 100  # Reescrever quando o arquivo AOF for 100% maior que o tamanho base
auto-aof-rewrite-min-size 64mb    # Não reescrever a menos que o arquivo tenha pelo menos 64MB

Aviso sobre a Reescrita: Assim como o salvamento RDB, a reescrita AOF envolve a bifurcação do processo. Se o seu sistema tiver restrição de memória, essa duplicação temporária do uso da memória (a instância ativa mais a cópia sendo reescrita) pode levar à instabilidade ou ao swapping.

Conclusão

As escolhas de persistência do Redis são um equilíbrio direto entre latência e durabilidade. O RDB se destaca na recuperação rápida e na sobrecarga mínima de gravação, mas arrisca a perda de dados. O AOF oferece segurança de dados superior, mas pode introduzir latência de gravação dependendo da política fsync.

Para a maioria das cargas de trabalho de produção que priorizam alto rendimento com segurança razoável, habilitar o AOF com appendfsync everysec é a recomendação padrão. Para sistemas de missão crítica que exigem perda de dados próxima de zero, habilitar tanto RDB quanto AOF fornece a melhor resiliência operacional e flexibilidade de ajuste de desempenho.