Redis Persistence: RDB vs AOF Comparison and Production S...

This is article 45 in the Big Data series. This article provides an in-depth explanation of Redis two persistence mechanisms — RDB snapshots and AOF logs — to help make informed choices in real-world scenarios.

Full illustrated version (with screenshots): CSDN Original | Juejin

Why Persistence is Needed

Redis is an in-memory database. When the process restarts or the server crashes, all in-memory data is lost. The persistence mechanism writes memory data to disk, allowing Redis to reload data upon restart, ensuring data is not lost.

---

RDB (Redis Database) Snapshot

RDB saves memory data at a specific point in time as a binary snapshot to disk (default filename dump.rdb).

Trigger Methods

Automatic trigger (configure in redis.conf):

# Format: save <seconds> <changes>
save 900 1       # Trigger if ≥1 key changes within 900 seconds
save 300 10      # Trigger if ≥10 keys change within 300 seconds
save 60 10000    # Trigger if ≥10000 keys change within 60 seconds

Manual trigger:

SAVE      # Synchronous execution, blocks all clients (not recommended for production)
BGSAVE    # Fork child process in background, main process continues serving requests

How It Works

BGSAVE uses Copy-on-Write (COW) mechanism:

1. Main process forks a child process (memory pages are shared, minimal overhead)
2. Child process writes memory data to a temporary RDB file
3. After writing completes, atomically replace the old RDB file
4. Only when the main process modifies data does it copy the corresponding memory pages, not affecting the child process snapshot

Pros and Cons

Advantages:

• Fast recovery (~3 seconds for 1GB data)
• Compact file size (~1/5 to 1/10 of memory data)
• Minimal impact on main process performance

Disadvantages:

• Risk of data loss between snapshots
• May cause brief pauses during fork on large datasets (millisecond-level)

---

AOF (Append Only File) Log

AOF records every write command in text format (default filename appendonly.aof).

Enable Configuration

appendonly yes

Flush Policy (appendfsync)

Policy	Behavior	Data Safety	Performance
always	fsync after every write	Highest (almost no data loss)	Lowest
everysec	fsync once per second (default)	High (max 1 second data loss)	Good
no	OS decides when to fsync	Lowest	Highest

Production recommendation: everysec, balances safety and performance.

appendfsync everysec

AOF Rewrite Mechanism

AOF files grow over time. Redis compresses files through rewrite: merging multiple redundant commands into equivalent minimal form. For example, 100 SET operations on the same key are merged into a single final SET.

# Manual trigger rewrite
BGREWRITEAOF

# Auto rewrite configuration
auto-aof-rewrite-percentage 100   # Trigger when AOF file grows 100% since last rewrite
auto-aof-rewrite-min-size 64mb    # Only allow auto rewrite if AOF file > 64MB

Rewrite also uses fork + COW, doesn’t block the main process.

---

RDB vs AOF Comparison

Dimension	RDB	AOF
Data Safety	Lower (may lose minutes of data)	Higher (max 1 second loss)
Recovery Speed	Fast (~3s / 1GB)	Slow (~30s / 1GB)
File Size	Small (binary compression)	Large (text记录所有命令)
Continuous I/O Overhead	Low (only during snapshot)	Medium (continuous append writes)
File Readability	Not readable (binary)	Readable (text commands)
Suitable Scenarios	Fast recovery, tolerate minor data loss	Financial transactions, zero tolerance for data loss

---

Hybrid Persistence (Redis 4.0+)

Redis 4.0 introduces hybrid persistence mode, combining RDB and AOF advantages:

aof-use-rdb-preamble yes

How it works: During AOF rewrite, the current memory state is written in RDB format at the AOF file header, and subsequent new commands are appended in AOF format. On restart, RDB part is loaded first (fast), then AOF incremental part is replayed (safe).

---

Production Environment Recommendations

Enabling both RDB + AOF is the mainstream approach:

# RDB: Provides periodic full backups
save 900 1
save 300 10
save 60 10000

# AOF: Ensures real-time data safety
appendonly yes
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# Redis 4.0+ hybrid mode
aof-use-rdb-preamble yes

When Redis restarts, it prioritizes loading the AOF file (higher safety), only loading RDB if AOF doesn’t exist.

Scenario Decision

• Cache scenario (cold start acceptable): Can disable AOF, keep only RDB to reduce I/O overhead
• Session storage / counters: everysec AOF is sufficient
• Financial / payment transactions: always AOF + periodic RDB backups + master-replica replication triple protection