Persistence trong Redis: RDB vs AOF — Lưu dữ liệu xuống Disk
Bạn có biết?
Redis lưu dữ liệu trong memory — nhanh nhưng “mất điện” là mất hết. Vậy khi server restart, dữ liệu đi đâu? Câu trả lời nằm ở persistence — cơ chế ghi dữ liệu xuống disk. Redis cung cấp hai cách: RDB (snapshot định kỳ) và AOF (ghi log từng lệnh). Hiểu rõ cả hai giúp bạn không bao giờ mất dữ liệu quan trọng.
Tại sao cần Persistence?
Redis là in-memory database — tất cả dữ liệu nằm trong RAM. Nếu Redis crash hoặc restart:
- Không có persistence → Mất toàn bộ dữ liệu
- Có RDB → Khôi phục từ snapshot gần nhất (có thể mất vài phút dữ liệu)
- Có AOF → Khôi phục gần như đầy đủ (mất vài giây hoặc không mất)
RDB — Redis Database Backup
RDB tạo snapshot toàn bộ dataset tại một thời điểm và lưu vào file dump.rdb.
Cách hoạt động
# Redis tự động tạo snapshot theo cấu hình
# Ví dụ: sau 900 giây nếu có ít nhất 1 key thay đổi
save 900 1
# Hoặc sau 300 giây nếu có ít nhất 10 keys thay đổi
save 300 10
# Hoặc sau 60 giây nếu có ít nhất 10000 keys thay đổi
save 60 10000
Cấu hình RDB
Trong file redis.conf:
# Snapshot rules
save 900 1
save 300 10
save 60 10000
# Tên file dump
dbfilename dump.rdb
# Thư mục lưu file
dir /var/lib/redis/
# Nén file dump (mặc định bật)
rdbcompression yes
# Kiểm tra checksum khi load
rdbchecksum yes
# Tắt RDB (nếu chỉ dùng AOF)
save ""
Tạo snapshot thủ công
# Tạo snapshot ngay lập tức (background)
BGSAVE
# Redis fork process con để tạo snapshot
# Không block chính process
# Tạo snapshot foreground (block Redis)
SAVE
# Dùng khi cần đảm bảo snapshot hoàn thành ngay
Kiểm tra thông tin RDB
# Xem thông tin persistence
INFO persistence
# Kết quả:
# rdb_changes_since_last_save:150
# rdb_bgsave_in_progress:0
# rdb_last_save_time:1711785600
# rdb_last_bgsave_status:ok
# rdb_last_bgsave_time_sec:2
Ưu điểm RDB
- Nhanh khi restore — Load một file dump, nhanh hơn AOF nhiều
- File nhỏ — Snapshot nén, dung lượng thấp
- Phù hợp backup — Dễ copy, lưu trữ, chuyển đi
- Ít ảnh hưởng performance — BGSAVE chạy background
Nhược điểm RDB
- Có thể mất dữ liệu — Nếu crash giữa 2 snapshot, mất dữ liệu trong khoảng đó
- Fork có thể chậm — Dataset lớn → fork tốn thời gian, có thể gây delay
- Không phù hợp real-time — Snapshot định kỳ, không phải từng lệnh
AOF — Append Only File
AOF ghi từng lệnh vào file log. Khi restart, Redis replay lại tất cả lệnh để khôi phục dữ liệu.
Cách hoạt động
Mỗi khi có lệnh ghi (SET, HSET, LPUSH…), Redis append lệnh đó vào file AOF. Khi restart, Redis đọc file AOF và thực thi lại từng lệnh theo thứ tự.
# Ví dụ: bạn thực hiện các lệnh sau
127.0.0.1:6379> SET user:1 "Alice"
OK
127.0.0.1:6379> SET user:2 "Bob"
OK
127.0.0.1:6379> HSET user:1 age 25 city "Hanoi"
(integer) 2
# File appendonly.aof sẽ ghi lại cả 3 lệnh này
# Khi Redis restart → replay lại → dữ liệu được khôi phục
So với RDB (snapshot toàn bộ dataset), AOF ghi chi tiết hơn nhưng file sẽ lớn hơn và restore chậm hơn.
Cấu hình AOF
# Bật AOF
appendonly yes
# Tên file AOF
appendfilename "appendonly.aof"
# Fsync policy (quan trọng nhất!)
# always: mỗi lệnh đều ghi disk — an toàn nhất, chậm nhất
# everysec: ghi disk mỗi giây — cân bằng tốt (mặc định)
# no: để OS tự quyết định — nhanh nhất, rủi ro nhất
appendfsync everysec
# Rewrite khi AOF quá lớn
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
So sánh fsync policies
| Policy | An toàn | Performance | Mất dữ liệu tối đa |
|---|---|---|---|
| always | Cao nhất | Chậm nhất | 0 (không mất) |
| everysec | Cao | Tốt | 1 giây |
| no | Thấp | Nhanh nhất | Không xác định |
Khuyến nghị: Dùng everysec — cân bằng tốt giữa an toàn và hiệu năng.
AOF Rewrite
Sau thời gian dài, file AOF phình to vì chứa mọi lệnh (kể cả lệnh ghi đè). AOF Rewrite tối ưu lại file:
# Ví dụ file AOF gốc:
SET user:1 "Alice"
SET user:1 "Bob" # Ghi đè
SET user:1 "Charlie" # Ghi đè
# Sau rewrite (chỉ giữ giá trị cuối):
SET user:1 "Charlie"
# Trigger rewrite thủ công
BGREWRITEAOF
# Kiểm tra tiến trình
INFO persistence
# aof_rewrite_in_progress:0
# aof_last_rewrite_status:ok
# aof_current_size:1048576
# aof_base_size:524288
RDB + AOF — Hybrid Persistence
Từ Redis 4.0, bạn có thể kết hợp cả hai để có ưu điểm của cả RDB và AOF:
# Bật cả RDB và AOF
appendonly yes
save 900 1
save 300 10
# Hybrid mode (Redis 7+)
# AOF file sẽ chứa:
# - Base: RDB format (nhanh khi load)
# - Incremental: AOF format (an toàn)
aof-use-rdb-preamble yes
Lợi ích hybrid:
- Load nhanh như RDB (base snapshot)
- An toàn như AOF (incremental logs)
- File nhỏ hơn AOF thuần
So sánh RDB vs AOF vs Hybrid
| Tiêu chí | RDB | AOF | Hybrid (RDB+AOF) |
|---|---|---|---|
| Dữ liệu mất khi crash | Vài phút | 0-1 giây | 0-1 giây |
| Restore speed | Nhanh | Chậm | Nhanh |
| File size | Nhỏ | Lớn | Trung bình |
| Performance impact | Thấp | Trung bình | Trung bình |
| Phù hợp | Backup, DR | High durability | Production |
Cấu hình cho Production
Scenario 1: Cache layer (có thể mất dữ liệu)
# Chỉ cần RDB để restart nhanh
save 900 1
save 300 10
appendonly no
Scenario 2: Session store (cần durability)
# AOF với everysec
appendonly yes
appendfsync everysec
save 900 1 # Backup thêm
Scenario 3: Primary database (không được mất dữ liệu)
# AOF always + RDB backup
appendonly yes
appendfsync always
save 3600 1
save 300 100
aof-use-rdb-preamble yes
Scenario 4: High throughput (ưu tiên performance)
# RDBchủ yếu, AOF everysec
save 3600 1
appendonly yes
appendfsync everysec
no-appendfsync-on-rewrite yes
Khôi phục dữ liệu
Khôi phục từ RDB
# 1. Dừng Redis
redis-cli SHUTDOWN
# 2. Copy file dump.rdb vào thư mục dir
cp /backup/dump.rdb /var/lib/redis/
# 3. Khởi động Redis (tự động load dump.rdb)
redis-server /etc/redis/redis.conf
Khôi phục từ AOF
# 1. Dừng Redis
redis-cli SHUTDOWN
# 2. Copy file appendonly.aof vào thư mục dir
cp /backup/appendonly.aof /var/lib/redis/
# 3. Khởi động Redis (tự động replay AOF)
redis-server /etc/redis/redis.conf
# Kiểm tra file AOF có hợp lệ không
redis-check-aof /var/lib/redis/appendonly.aof
Best Practices
- Dùng Hybrid mode — Kết hợp RDB + AOF cho production (Redis 7+)
- Chọn everysec — Cân bằng tốt giữa an toàn và hiệu năng
- Backup RDB định kỳ — Copy file dump.rdb sang nơi khác
- Monitor disk space — AOF có thể phình to, cần rewrite
- Test restore — Định kỳ test khôi phục dữ liệu
- Separate disk — Đặt file persistence trên disk khác với data
Lưu ý quan trọng
- RDB fork tốn memory — Khi fork, cần gấp đôi memory tạm thời
- AOF rewrite cũng fork — Tương tự RDB, cần extra memory
- Không tắt persistence trên production — Trừ khi dùng Redis chỉ như cache
- Giám sát persistence — Dùng
INFO persistenceđể theo dõi

Bước tiếp theo
Bạn đã nắm vững Persistence trong Redis! Tiếp theo, chúng ta sẽ tìm hiểu về Replication & High Availability — cách Redis đảm bảo hệ thống luôn sẵn sàng.
👉 Bài tiếp theo: Replication & High Availability trong Redis