Como funciona a persistência no Redis (RDB vs AOF)?

Question

Accepted Answer

Embora Redis seja em memória, ele pode **persistir dados em disco** para que os dados sobrevivam a reinicializações. Oferece dois mecanismos — **RDB** (snapshots de ponto-no-tempo) e **AOF** (log de anexação de operações) — com diferentes trade-offs de durabilidade/desempenho.

## RDB — snapshots de ponto-no-tempo

```text
RDB takes SNAPSHOTS of the dataset at intervals, saving a compact binary file.
  ✓ Compact single-file backups; fast restarts (load the snapshot)
  ✓ Good for backups and disaster recovery; less impact on performance
  ✗ You can LOSE data since the last snapshot (e.g. last few minutes) if Redis crashes
→ Configure save points: e.g. "save after 900s if ≥1 change, 300s if ≥10 changes"
```

RDB salva periodicamente todo o conjunto de dados em um arquivo compacto — eficiente e ótimo para backups, mas uma falha perde as alterações feitas desde o último snapshot.

## AOF — log de anexação

```text
AOF logs EVERY write operation to a file; on restart, Redis replays the log to rebuild data.
  ✓ More DURABLE — less data loss (can fsync every second, or every write)
  ✓ The log can be rewritten/compacted to stay manageable
  ✗ Larger files; can be slower than RDB; restart (replay) can be slower
→ fsync policies: always (safest, slowest), everysec (good balance), no (fastest, riskiest)
```

AOF registra cada escrita, reproduzindo-a para reconstruir dados na reinicialização — mais durável (menos perda de dados) mas com arquivos maiores e potencialmente desempenho/reinicializações mais lentas.

## RDB vs AOF — o trade-off

```text
RDB → better performance, compact backups, faster restart, BUT more potential data loss
AOF → better durability (minimal data loss), BUT larger files, slower

BEST PRACTICE: use BOTH together → RDB for backups + AOF for durability
  → Redis can use both; AOF for recovery, RDB for snapshots/backups
OR: pure cache use → you may DISABLE persistence entirely (data is recreatable)
```

## Por que isso importa

Compreender a persistência do Redis é importante para **garantir a durabilidade dos dados** adequadamente quando Redis mantém dados que importam, então é conhecimento valioso para usar Redis corretamente.

Embora Redis seja primariamente em memória, o fato de que **pode persistir em disco** (para que os dados sobrevivam a reinicializações e falhas) é importante compreender, junto com os dois mecanismos e seus trade-offs. **RDB** (snapshots de ponto-no-tempo) oferece backups compactos, reinicializações rápidas e baixo impacto de desempenho, mas risco de **perder dados desde o último snapshot** em uma falha — bom para backups e aceitável quando alguma perda de dados é tolerável. **AOF** (registro de cada operação de escrita, reproduzido na reinicialização) oferece **melhor durabilidade** (perda mínima de dados, configurável via políticas de fsync) mas com arquivos maiores e potencialmente desempenho/reinicializações mais lentas.

Compreender o **trade-off** (RDB para desempenho e backups compactos vs AOF para durabilidade) e a **melhor prática comum de usar ambos juntos** (RDB para snapshots/backups mais AOF para durabilidade) reflete julgamento de configuração sólido.

Também importante é reconhecer que para **uso de pure caching** (onde os dados são recriáveis da fonte), a persistência pode ser desabilitada inteiramente — Redis nem sempre precisa de durabilidade.

Escolher a configuração de persistência correta com base no caso de uso (necessidades de durabilidade vs desempenho, ou nenhuma para pure cache) é a habilidade prática-chave.

Como a durabilidade dos dados importa quando Redis mantém dados importantes (sessões, filas, dados primários), e como compreender RDB, AOF, seus trade-offs e as melhores práticas (ambos juntos, ou nenhum para caching) é necessário para configurar Redis apropriadamente, compreender a persistência do Redis é conhecimento valioso e praticamente relevante para usar Redis responsavelmente — garantindo o nível correto de durabilidade para os dados que Redis mantém, um tópico que reflete compreensão de Redis além de simples caching.