Hur fungerar Redis persistens (RDB vs AOF)?

Question

Accepted Answer

Även om Redis är en minnesdatabas kan den **spara data till disk** så att data överlever omstarter. Den erbjuder två mekanismer — **RDB** (ögonblicksbilder vid en viss tidpunkt) och **AOF** (tilläggskö för operationer) — med olika kompromisser mellan hållbarhet och prestanda.

## RDB — ögonblicksbilder vid en viss tidpunkt

```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 sparar regelbundet hela datamängden till en kompakt fil — effektivt och utmärkt för säkerhetskopior, men en krasch förlorar ändringar som gjorts sedan den senaste ögonblicksbilden.

## AOF — tilläggskö

```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 registrerar varje skrivning och spelar upp den för att återuppbygga data vid omstart — mer hållbar (mindre dataförlust) men med större filer och potentiellt långsammare prestanda/omstarter.

## RDB vs AOF — kompromissen

```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)
```

## Varför det spelar roll

Att förstå Redis persistens är viktigt för **att säkerställa lämplig datahållbarhet** när Redis innehåller data som spelar roll, så det är värdeful kunskap för att använda Redis på rätt sätt.

Even om Redis i första hand är en minnesdatabas är det viktigt att förstå att den **kan spara till disk** (så data överlever omstarter och krascher) tillsammans med de två mekanismerna och deras kompromisser. **RDB** (ögonblicksbilder vid en viss tidpunkt) erbjuder kompakta säkerhetskopior, snabba omstarter och låg prestandapåverkan, men riskerar att **förlora data sedan den senaste ögonblicksbilden** vid en krasch — bra för säkerhetskopior och godtagbar när viss dataförlust är acceptabel. **AOF** (loggning av varje skrivoperation, uppspelad vid omstart) erbjuder **bättre hållbarhet** (minimal dataförlust, konfigurerbar via fsync-principer) men med större filer och potentiellt långsammare prestanda/omstarter.

Att förstå **kompromissen** (RDB för prestanda och kompakta säkerhetskopior vs AOF för hållbarhet) och den vanliga **bästa praktiken att använda båda tillsammans** (RDB för ögonblicksbilder/säkerhetskopior plus AOF för hållbarhet) återspeglar ett sunt konfigurationsbeslut.

Det är också viktigt att erkänna att för **ren caching-användning** (där data är återskapbar från källan) kan persistens inaktiveras helt — Redis behöver inte alltid hållbarhet.

Att välja rätt persistenskonfiguration baserat på användningsfallet (behov av hållbarhet vs prestanda, eller ingen för ren cache) är den viktigaste praktiska färdigheten.

Eftersom datahållbarhet spelar roll när Redis innehåller viktig data (sessioner, köer, primär data) och eftersom förståelse för RDB, AOF, deras kompromisser och bästa praktiker (båda tillsammans, eller ingen för caching) är nödvändig för att konfigurera Redis lämpligt, är förståelse för Redis persistens värdeful, praktiskt relevant kunskap för att använda Redis ansvarsfullt — för att säkerställa rätt nivå av hållbarhet för den data Redis innehåller, ett ämne som återspeglar förståelse av Redis bortom enkel caching.