Redis persistence｜RDB vs. AOF 深度解析

TL;DR | 面試情境模擬

#

👴 面試官：請詳細比較 Redis 的 RDB 和 AOF 機制，並說明其差異。

🧑‍💻 你：RDB 通過 fork 子行程進行快照，體積小且恢復快，適合冷備份；AOF 則是追加寫入命令日誌，數據完整性高，但體積大。現代生產環境多採用兩者共用的 Hybrid 模式。

為什麼要persistence？（比喻理解）

#

如果 Redis 服務掛了，記憶體裡的資料就全沒了。為了救回這些資料，我們有兩種備份方式：

1. RDB (Redis Database) —— 攝影機快照

#

想像每小時用攝影機拍一張餐廳營業全景圖。

• 優點：一張照片幾秒鐘看完，恢復時直接重現快照，速度極快。
• 缺點：如果攝影機是一小時拍一次，那故障時刻前的那一小時內發生的事情全沒了。

2. AOF (Append Only File) —— 流水帳錄音筆

#

給員工一台錄音筆，記錄他做的每一道菜、每一筆交易。

• 優點：只要有錄音在，無論何時故障，我都能重播這捲錄音帶把所有動作補齊，資料極度完整。
• 缺點：錄音帶越記越長，檔案變巨大；重播（恢復）時，因為要重走一遍所有步驟，速度比較慢。

💡 深入技術解析

#

1. RDB (Redis Database)

#

在指定時間間隔內，對資料集進行快照 (Snapshot) 並儲存為二進位檔案 (dump.rdb)。

運作圖解：

[記憶體 Memory]                [硬碟 Disk]
    |------------------快照---------------> [ dump.rdb ]
    | (Fork 子行程)
    |------------------快照---------------> [ dump.rdb ]

• 機制：Redis 會 fork() 一個子行程，利用 Copy-on-Write (COW) 機制，讓子行程將當時的記憶體狀態寫入硬碟，主行程繼續處理請求，這確保了 Redis 不會因快照而阻塞。

2. AOF (Append Only File)

#

以純文字格式追加記錄 Redis 接收到的每一條寫入指令。

運作圖解：

[Redis 主程序] --(寫入指令)--> [appendonly.aof]
           |--(寫入指令)--> [appendonly.aof]
           |--(寫入指令)--> [appendonly.aof]

• AOF Rewrite (重寫) 機制：

[AOF 檔案 - 臃腫]                [AOF 檔案 - 精簡]
  SET k1 1                       
  SET k1 2   ----(Rewrite)--->   SET k1 2
  DEL k1
  SET k2 3                       SET k2 3

💡 Hybrid 模式：RDB 與 AOF 的最佳搭檔

#

現代生產環境通常會同時啟用 RDB 與 AOF，達成「資料安全性」與「恢復速度」的平衡。

運作圖解：

[客戶端請求]
      |
      V
[Redis 主程序]
  /        \
 /          \
V            V
(AOF)        (RDB)
  |            |
  V            V
[appendonly.aof]  [dump.rdb]
 (記錄即時變化)     (定期備份全貌)

為什麼這樣配合最完美？

• 日常運作：Redis 每一條寫入指令都寫入 AOF (保證安全)；後台定時觸發 RDB 快照 (保證備份狀態)。
• 重啟恢復：Redis 會優先使用 RDB 加載基礎資料狀態 (快速)，再重放自上次快照後的 AOF 記錄 (補齊細節)。

核心差異總結

#

💡 進階補充：常見追問

#

Q1：AOF Rewrite (重寫) 會阻塞主線程嗎？

#

不會。AOF 重寫會在後台子行程中進行，主行程依然正常處理請求。重寫完成後，主行程會將重寫期間產生的新變更同步到新的 AOF 檔案中。