兩大持久化引擎
- RDB (Redis Database)：指定間隔生成時間點快照（二進制）。
- AOF (Append Only File)：記錄每條寫命令，重啟時重放恢復。
可單獨啟用或同時啟用（重啟優先載入 AOF，因更完整）。亦可完全關閉（純記憶體模式）。
RDB 優缺點與配置
優點
- 單一緊湊文件，適合備份/災難恢復（可加密傳送異地）。
- 父進程僅 fork 子進程寫入，主進程無磁盤 I/O，性能影響最小。
- 大數據集恢復速度快於 AOF。
缺點
- 故障間隔內數據會丟失（預設 5 分鐘/1 次改動觸發）。
- 巨大數據集 fork() 可能阻塞主進程毫秒至秒級。
配置範例
save 900 1 # 900 秒內至少 1 次寫入
save 300 10 # 300 秒內至少 10 次
save 60 10000 # 60 秒內至少 10000 次
dbfilename dump.rdb
dir ./
手動觸發：SAVE (阻塞) / BGSAVE (非阻塞)。
AOF 優缺點與運作
優點
- 耐久性強：
fsync 策略可選（always/everysec/no），預設 everysec 兼顧效能與最多 1 秒丟失。
- 純追加日誌，
redis-check-aof 可修復截斷損壞。
- 支援背景重寫（BGREWRITEAOF），產生最小命令集，原子切換。
- 人類可讀，易於分析/手工修復（如誤執行 FLUSHALL）。
缺點
- 文件體積通常大於 RDB。
- 極高寫入負載下延遲較 RDB 不穩定。
- 歷史曾有特定命令導致重放不一致的 bug（已測試覆蓋）。
重寫流程
- fork 子進程寫入臨時 AOF。
- 父進程雙軌：新命令寫入舊 AOF + 累積記憶體緩衝。
- 子進程完成 → 發信號 → 父進程追加緩衝 → 原子替換。
RDB + AOF 雙重保險
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir ./
appendonly yes
- 啟動優先載入 AOF。
BGSAVE 與 BGREWRITEAOF 互斥執行，避免 I/O 爭用。
AOF 進階議題
- 觸發重寫：手動
BGREWRITEAOF 或自動（配置 auto-aof-rewrite-percentage/min-size）。
- fsync 策略：always(最慢最安全) / everysec(推薦) / no(交給 OS)。
- 損壞修復：備份 →
redis-check-aof --fix → 對比 → 重啟載入。
從 RDB 熱遷移至 AOF (無需重啟)
- 備份最新
dump.rdb。
- 執行：
CONFIG SET appendonly yes + CONFIG SET save "" (關閉 RDB，可選)。
- 驗證鍵數不變、寫命令正確追加。
- 修改
redis.conf 持久化設定，防重啟失效。
備份策略建議
- RDB 文件創建後不再修改，
cp 複製絕對安全（rename 原子性）。
- Cron 任務：每小時備份保留 48 小時，每日備份保留 1-2 月。
- 異地備份：每日至少推送一份至異地/異機。
