在 Redis 中，數據持久化的方式有 AOF（Append-Only File） 和 RDB（Redis Database Snapshot） 兩種選擇。在生產環境中，通常會同時設置這兩者，但許多開發者可能會有以下疑問。
"AOF 即時記錄數據，那麼 RDB 設定還有意義嗎？" "既然 AOF 是恢復的優先選擇，那麼 RDB 根本不需要吧？"
然而在實際的生產環境中，RDB 依然是必要的。以下是原因。
1. AOF 文件可能會損壞
AOF 記錄所有更改，但存在 文件損壞的風險。由於磁碟錯誤、運行中故障、不當的文件移動等原因，AOF 文件損壞時，恢復可能會變得困難。
redis-server --appendonly yes
如果在重新啟動 Redis 時 AOF 文件已損壞，則數據可能無法恢復。在這種情況下，如果有 RDB 備份，至少可以恢復部分數據。
✅ 如果只使用 AOF，但文件損壞？ 數據丟失風險上升
✅ 如果有 RDB？ 至少可以恢復部分數據
2. AOF 恢復速度較慢
AOF 需要 逐一重新執行所有更改 來進行恢復。數據越多，Redis 重新啟動時的恢復時間就越長。
例如，若 AOF 文件大小為 2GB，則 Redis 必須 執行數百萬個 SET 命令。而 RDB 則僅需加載轉儲文件，因此恢復速度更快。
✅ 如果只使用 AOF？ 恢復時間可能會延長
✅ 如果一起使用 RDB？ 可以快速恢復
3. RDB 便於備份和伺服器遷移
在生產環境中進行數據備份時，AOF 文件較大且格式為日誌，使用起來不方便。而 RDB 的 文件大小小且能夠保留特定時刻的數據，因此備份更為簡單。
✔ 使用 RDB 進行備份的範例：
cp /var/lib/redis/dump.rdb /backup/dump-2025-02-17.rdb
✔ 將數據遷移到其他伺服器的範例：
scp /var/lib/redis/dump.rdb new-server:/var/lib/redis/
✅ AOF 數據越多，備份越困難
✅ RDB 更有利於快速備份和恢復特定時點的數據
4. 可以減少磁碟 I/O 負擔
AOF 需要 將所有變更寫入磁碟，因此磁碟 I/O 負擔較大。相對而言，RDB 只需在 固定周期內存儲一次，因此對磁碟的壓力較小。
✅ 如果只使用 AOF？ 磁碟負擔可能增加
✅ 如果與 RDB 共同使用？ 可以優化性能
5. 生產環境推薦的 RDB + AOF 設定
在生產環境中，推薦以下設定。
# RDB 快照設定（當條件滿足時，將數據存儲到磁碟）
# save <seconds> <changes> [<seconds> <changes> ...]
save 900 1 300 10 60 10000
# 在 900 秒（15 分鐘）內有一個或以上的鍵變更，或在 300 秒（5 分鐘）內有 10 個或以上的鍵變更，或在 60 秒（1 分鐘）內有 10,000 個或以上的鍵變更時進行保存
# 啟用 AOF
appendonly yes
appendfsync everysec # 每秒將數據寫入磁碟，以保持性能和穩定性之間的平衡
# AOF 文件大小自動優化（重寫）
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
🔍 多個 save 條件如何評估？
在 Redis 中，所有 save 條件都是以 OR 條件 的方式運行。也就是說，只要滿足 其中一個條件，快照就會被保存。
✔ 範例 1：當 save 900 1 和 save 60 10000 被設定時 - 只要在 900 秒內有任意一個鍵發生變更，或是在 60 秒內變更 10,000 個鍵 - 就會存儲 RDB 快照。
✔ 範例 2：當新增 save 300 10 條件時 - 只要在 300 秒內有 10 個鍵變更，或是在 900 秒內有 1 個鍵變更，或是在 60 秒內有 10,000 個鍵變更 - 就會存儲 RDB 快照。
✅ 所有 save 選項均以 OR 條件評估
✅ 只要有一個滿足，就會立即保存 RDB
結論：即使有 AOF，RDB 仍然是必需的
✅ 僅依賴 AOF 無法完全保護數據
✅ 如果 AOF 損壞，RDB 將成為最後的備份
✅ AOF 的恢復速度可能較慢，因此利用 RDB 可以更快恢復
✅ RDB 更利於備份和伺服器遷移
✅ 可以減少磁碟 I/O 負擔並優化性能
✅ save 設定按照 OR 條件進行運行，任何一個滿足都會保存 RDB
因此，在生產環境中，同時設置 RDB + AOF 是最安全和最佳的方法。
在右側的搜索框中搜索 `Redis`！有其他與 Redis 相關的文章準備好給您。
也查看之前分析 AOF 重寫功能的文章。
Add a New Comment