Redis persistence trong production: chọn RDB, AOF hay hybrid?

8ce2065d-b008-400b-beef-3e795a49e818.jpg —

Redis thường được dùng như cache, nhưng rất nhiều hệ thống production lại đặt queue, session, rate limit counter, feature flag hoặc dữ liệu tạm quan trọng vào Redis. Nếu Redis restart mà dữ liệu biến mất, app có thể crash, mất job hoặc gây sai lệch nghiệp vụ. Vì vậy, hiểu đúng Redis persistence là bước bắt buộc trước khi chạy Redis nghiêm túc.

Bài này đi thẳng vào thực tế: RDB khác AOF thế nào, khi nào dùng hybrid, cấu hình appendfsync ra sao và checklist backup/recovery cho production.

Redis persistence là gì?

Mặc định Redis lưu dữ liệu trong RAM để đạt tốc độ cao. Persistence là cơ chế ghi dữ liệu từ memory xuống disk để Redis có thể khôi phục sau restart, crash hoặc migration.

Redis OSS có hai cơ chế chính:

• RDB: tạo snapshot dữ liệu tại một thời điểm, lưu thành file .rdb.
• AOF: ghi log các write command vào append-only file, sau đó replay để khôi phục dữ liệu.

Trong nhiều workload production, lựa chọn hợp lý là bật cả hai: AOF để giảm mất dữ liệu, RDB để backup và khôi phục nhanh hơn.

RDB: snapshot gọn, backup tốt, nhưng có thể mất dữ liệu giữa hai lần save

RDB tạo ảnh chụp dữ liệu tại một thời điểm. File RDB thường nhỏ, dễ copy đi backup và load nhanh hơn so với replay một AOF quá lớn.

# redis.conf
save 900 1
save 300 10
save 60 10000

dbfilename dump.rdb
dir /var/lib/redis

Ba dòng save trên nghĩa là Redis sẽ tạo snapshot nếu có đủ số lần thay đổi trong khoảng thời gian tương ứng. Ví dụ save 300 10 nghĩa là trong 300 giây có ít nhất 10 thay đổi thì trigger snapshot.

Ưu điểm của RDB

• File nhỏ, phù hợp để archive và backup sang object storage.
• Load nhanh khi restart, nhất là dataset lớn.
• Ít ảnh hưởng main Redis process vì snapshot chạy qua child process.

Nhược điểm của RDB

• Có thể mất dữ liệu phát sinh sau snapshot cuối cùng.
• fork() khi snapshot có thể gây latency spike nếu dataset lớn hoặc memory pressure cao.
• Không phù hợp nếu yêu cầu durability gần real-time.

AOF: durability tốt hơn, đổi lại file lớn và cần rewrite

AOF ghi lại các lệnh làm thay đổi dữ liệu. Khi Redis khởi động lại, nó replay AOF để dựng lại state. Đây là lựa chọn quan trọng khi dữ liệu Redis không được phép mất quá nhiều.

# redis.conf
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

Điểm cần hiểu nhất là appendfsync, vì nó quyết định trade-off giữa durability và performance.

appendfsync always

Redis gọi fsync gần như sau mỗi write. Durability cao nhất nhưng latency tăng mạnh. Chỉ nên dùng cho workload rất đặc biệt, nơi mất dữ liệu gần như không chấp nhận được và write throughput không quá cao.

appendfsync everysec

Đây là lựa chọn khuyến nghị cho phần lớn production. Redis flush AOF khoảng mỗi giây, cân bằng tốt giữa tốc độ và rủi ro mất dữ liệu. Nếu OS hoặc máy chủ crash, bạn thường chấp nhận rủi ro mất khoảng tối đa 1 giây dữ liệu gần nhất.

appendfsync no

Redis không chủ động fsync, để OS tự quyết định lúc ghi xuống disk. Performance tốt hơn nhưng durability thấp hơn. Chỉ nên dùng khi Redis gần như là cache, mất dữ liệu không gây hậu quả lớn.

Hybrid persistence: lựa chọn thực tế cho đa số production

Từ Redis 4.0, AOF có thể dùng RDB preamble. Nói đơn giản, phần đầu AOF là snapshot dạng RDB, phần sau là các command phát sinh sau snapshot. Cách này giúp restart nhanh hơn so với replay toàn bộ command từ đầu, trong khi vẫn giữ durability tốt của AOF.

# redis.conf
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes

# RDB snapshot vẫn hữu ích cho backup
save 900 1
save 300 10
save 60 10000

Với app web, queue nhẹ, session store hoặc service nội bộ, cấu hình hybrid + appendfsync everysec thường là baseline tốt.

Quản lý AOF rewrite để tránh file phình quá lớn

AOF là log append-only nên sẽ lớn dần theo thời gian. Redis có cơ chế rewrite để compact file, loại bỏ command dư thừa. Ví dụ key counter bị tăng 1.000 lần có thể được rewrite thành state cuối cùng thay vì giữ toàn bộ lịch sử.

# redis.conf
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

Khi file AOF tăng vượt ngưỡng, Redis sẽ rewrite trong background. Tuy vậy, rewrite cũng dùng fork(), vì vậy cần theo dõi memory và latency nếu dataset lớn.

Checklist cấu hình Redis persistence production

• Bật appendonly yes nếu dữ liệu cần giữ sau restart.
• Dùng appendfsync everysec cho phần lớn workload production.
• Bật aof-use-rdb-preamble yes để restart nhanh hơn.
• Giữ RDB snapshot để backup định kỳ.
• Đặt dir vào volume/disk persistent, không để trong filesystem tạm.
• Monitor disk usage, AOF rewrite, fork latency và Redis memory.
• Backup file persistence ra remote storage, không chỉ giữ trên cùng một máy.
• Test restore định kỳ, vì backup chưa test thì chưa phải backup.

Ví dụ cấu hình Redis với Docker Compose

Một lỗi phổ biến là bật persistence nhưng không mount volume. Khi container bị xoá, dữ liệu trên disk trong container cũng mất. Hãy mount thư mục dữ liệu ra volume riêng.

services:
  redis:
    image: redis:7-alpine
    command:
      - redis-server
      - --appendonly
      - "yes"
      - --appendfsync
      - everysec
      - --save
      - "900"
      - "1"
      - --save
      - "300"
      - "10"
      - --save
      - "60"
      - "10000"
    volumes:
      - redis-data:/data
    restart: unless-stopped

volumes:
  redis-data:

Với workload quan trọng hơn, bạn nên tách Redis config thành file riêng, mount vào container và quản lý bằng Git để dễ audit.

Kiểm tra persistence đang hoạt động

redis-cli CONFIG GET appendonly
redis-cli CONFIG GET appendfsync
redis-cli INFO persistence

Trong output INFO persistence, hãy chú ý các field như rdb_last_bgsave_status, aof_enabled, aof_last_bgrewrite_status, aof_current_size và lỗi liên quan đến save/rewrite.

Troubleshooting nhanh

Redis restart nhưng mất dữ liệu

• Kiểm tra có mount volume đúng vào /data không.
• Kiểm tra appendonly yes có thực sự được Redis load không.
• Kiểm tra quyền ghi của user Redis vào thư mục dữ liệu.

AOF quá lớn

• Bật hoặc giảm ngưỡng auto-aof-rewrite-percentage.
• Chạy BGREWRITEAOF trong giờ thấp tải nếu cần.
• Đảm bảo disk còn đủ trống trong lúc rewrite.

Latency spike khi snapshot/rewrite

• Theo dõi memory fragmentation và fork time.
• Dùng SSD/NVMe thay vì disk chậm.
• Tránh để Redis gần chạm giới hạn RAM.
• Cân nhắc replica chuyên làm backup nếu dataset lớn.

FAQ

Redis persistence có thay thế database không?

Không nên xem Redis persistence là thay thế trực tiếp cho database chính. Redis vẫn phù hợp nhất cho cache, queue, session, leaderboard, realtime state hoặc data structure tốc độ cao. Dữ liệu nghiệp vụ quan trọng vẫn nên có source of truth riêng.

Nên chọn RDB hay AOF?

Nếu chỉ cần backup định kỳ và chấp nhận mất vài phút dữ liệu, RDB có thể đủ. Nếu cần durability tốt hơn, bật AOF. Với production phổ biến, hybrid RDB + AOF là lựa chọn cân bằng.

appendfsync everysec có an toàn không?

Đây là cấu hình cân bằng và được dùng rộng rãi. Nó không đảm bảo zero data loss, nhưng giảm rủi ro xuống mức thường chấp nhận được cho nhiều hệ thống: khoảng tối đa 1 giây dữ liệu gần nhất khi crash nghiêm trọng.

Kết luận

Nếu Redis của bạn chỉ là cache thuần, mất dữ liệu không sao, persistence có thể đơn giản. Nhưng khi Redis giữ dữ liệu có giá trị, hãy bật AOF, dùng appendfsync everysec, giữ RDB snapshot cho backup và test restore định kỳ. Với đa số hệ thống production, Redis hybrid persistence là điểm khởi đầu an toàn và thực dụng nhất.