Persistence của Redis hoạt động như thế nào (RDB vs AOF)?

Question

Accepted Answer

Mặc dù Redis là in-memory, nó có thể **lưu dữ liệu xuống disk** để dữ liệu sống sót qua các lần khởi động lại. Nó cung cấp hai cơ chế — **RDB** (snapshot tại một thời điểm) và **AOF** (log append-only của các thao tác) — với các đánh đổi độ bền/hiệu năng khác nhau.

## RDB — snapshot tại một thời điểm

```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 định kỳ lưu toàn bộ dataset vào một file gọn — hiệu quả và tuyệt vời cho backup, nhưng một sự cố sẽ mất các thay đổi kể từ snapshot cuối.

## AOF — log append-only

```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 ghi lại mọi write, replay lại để dựng lại dữ liệu khi khởi động lại — bền hơn (mất dữ liệu ít hơn) nhưng với file lớn hơn và hiệu năng/khởi động lại có thể chậm hơn.

## RDB vs AOF — sự đánh đổi

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

## Tại sao điều này quan trọng

Hiểu persistence của Redis quan trọng để **đảm bảo độ bền dữ liệu** đúng mức khi Redis giữ dữ liệu quan trọng, nên đó là kiến thức giá trị để dùng Redis đúng cách.

Mặc dù Redis chủ yếu là in-memory, việc nó **có thể lưu xuống disk** (để dữ liệu sống sót qua khởi động lại và sự cố) là điều quan trọng cần hiểu, cùng với hai cơ chế và các đánh đổi của chúng. **RDB** (snapshot tại một thời điểm) cung cấp backup gọn, khởi động lại nhanh, và ít ảnh hưởng hiệu năng, nhưng có nguy cơ **mất dữ liệu kể từ snapshot cuối** khi có sự cố — tốt cho backup và chấp nhận được khi một số mất mát dữ liệu là dung thứ được. **AOF** (ghi log mọi thao tác write, replay khi khởi động lại) cung cấp **độ bền tốt hơn** (mất dữ liệu tối thiểu, cấu hình qua các chính sách fsync) nhưng với file lớn hơn và hiệu năng/khởi động lại có thể chậm hơn.

Hiểu **sự đánh đổi** (RDB cho hiệu năng và backup gọn vs AOF cho độ bền) và **best practice phổ biến là dùng cả hai cùng nhau** (RDB cho snapshot/backup cộng AOF cho độ bền) phản ánh phán đoán cấu hình đúng đắn.

Cũng quan trọng là nhận ra rằng đối với cách dùng **caching thuần** (nơi dữ liệu có thể tái tạo từ nguồn), persistence có thể được tắt hoàn toàn — Redis không phải lúc nào cũng cần độ bền.

Chọn cấu hình persistence đúng dựa trên use case (nhu cầu độ bền vs hiệu năng, hoặc không cần cho cache thuần) là kỹ năng thực hành chủ chốt.

Vì độ bền dữ liệu quan trọng khi Redis giữ dữ liệu quan trọng (session, queue, dữ liệu chính), và vì hiểu RDB, AOF, các đánh đổi của chúng, và các best practice (cả hai cùng nhau, hoặc không cần cho caching) là cần thiết để cấu hình Redis đúng cách, hiểu persistence của Redis là kiến thức giá trị, có liên quan về mặt thực hành để dùng Redis có trách nhiệm — đảm bảo đúng mức độ bền cho dữ liệu Redis giữ, một chủ đề phản ánh sự hiểu biết về Redis vượt ra ngoài caching đơn giản.