Persistence trong Redis: RDB vs AOF

Photo of author

Văn Ngọc Tân

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

  1. Dùng Hybrid mode — Kết hợp RDB + AOF cho production (Redis 7+)
  2. Chọn everysec — Cân bằng tốt giữa an toàn và hiệu năng
  3. Backup RDB định kỳ — Copy file dump.rdb sang nơi khác
  4. Monitor disk space — AOF có thể phình to, cần rewrite
  5. Test restore — Định kỳ test khôi phục dữ liệu
  6. 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
Redis persistence RDB and AOF data durability
RDB và AOF đảm bảo dữ liệu không mất khi Redis restart

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

0 0 đánh giá
Đánh giá bài viết
Theo dõi
Thông báo của
guest
0 Góp ý
Cũ nhất
Mới nhất Được bỏ phiếu nhiều nhất
Phản hồi nội tuyến
Xem tất cả bình luận