持久化功能可以有效地避免因程序退出造成的資料丟失問題：當下次重啟時利用之前持久化的檔案即可實現資料恢復。Redis 支援 RDB（Redis DataBase）和 AOF（Append Only File）兩種持久化機制

1. RDB

RDB 持久化是把當前程序資料生成的快照（SNAPSHOTTING）儲存到硬碟的過程，觸發 RDB 持久化過程分為手動觸發和自動觸發。

1.1 觸發機制

1.1.1 save

阻塞當前 Redis 伺服器，直到 RDB 過程完成，不建議使用。

1.1.2 bgsave

Redis 程序執行 fork 操作建立子程序，持久化過程由子程序負責（非同步），阻塞只發生在 fork 階段。

fork 的作用是複製一個與當前程序一樣的程序。

新程序的所有資料（變數、環境變數、程式計數器等） 數值都和原程序一致，但是是一個全新的程序，並作為原程序的子程序.

1.1.3 自動觸發

• 使用 save 進行了相關配置
• 若從主節點執行全量複製操作，主節點自動執行 bgsave 生成 rdb 檔案併發送給從節點
• 執行 debug reload 命令重新載入 Redis 時，自動觸發 save 操作
• 預設情況下執行 shutdown 命令時，若沒有開啟 AOF 則自動執行 bgsave

1.2 bgsave流程

• 執行 bgsave 命令，Redis 父程序判斷當前是否存在正在執行的子程序，若存在則直接返回
• 父程序執行 fork 操作
• fork 完成後，bgsave 命令返回Background saving started資訊，且不再阻塞父程序，父程序可繼續響應其他命令
• 子程序建立 RDB 檔案，根據父程序記憶體生成臨時快照檔案，完成後對原有檔案進行原子替換
• 子程序完成操作後給父程序傳送訊號，父程序更新統計資訊

1.3 RDB檔案的處理

1.3.1 目錄及名稱

1. 通過配置檔案

dbfilename dump.rdb
dir ./

2. 通過命令

CONFIG SET parameter value

config set dir newDir				# 設定新的儲存目錄
config set dbfilename newFileName	# 設定新的檔名
 

1.3.2 是否壓縮

1. 配置檔案

rdbcompression yes
預設開啟，使用了LZF演算法，大幅降低檔案體積

2. 命令

config set rdbcompression yes

1.4 優缺點

1.4.1 優點

• RDB 是緊湊的二進位制檔案，代表 Redis 在某個時間點上的資料快照，適用於備份、全景複製等場景。
• Redis 載入 RDB 恢復資料遠快於 AOF

1.4.2 缺點

• 做不到實時持久化/秒級持久化，因為 fork 操作屬於重量級操作
• 新舊版本的 RDB 檔案存在相容性問題

2. AOF

AOF 持久化是以獨立日誌的方式記錄每次寫命令（只追加不該寫），重啟時再重新執行一遍 AOF 檔案中的命令來恢復資料。

AOF 檔案的存放目錄與命名跟 RDB 檔案類似，不再贅述。開啟 AOF 需要在配置檔案中進行配置 appendonly yes

Redis 4.0 開始支援 RDB 和 AOF 的混合持久化（預設關閉，可以通過配置項 aof-use-rdb-preamble 開啟）。

如果把混合持久化開啟，AOF 重寫的時候就直接把 RDB 的內容寫到 AOF 檔案開頭。這樣做的好處是可以結合 RDB 和 AOF 的優點, 快速載入同時避免丟失過多的資料。當然缺點也是有的， AOF 裡面的 RDB 部分是壓縮格式不再是 AOF 格式，可讀性較差。

2.1 AOF 流程

• 所有的寫命令會追加到 aof-buf（緩衝區）中
• AOF 緩衝區根據對應的策略向硬碟做同步操作
• 隨著 AOF 檔案越來越大，需要定期對 AOF 檔案進行重寫，達到壓縮目的
• Redis 伺服器重啟後，可以載入 AOF 檔案進行資料恢復

2.2 append

AOF 命令寫入的內容是文字協議格式

2.3 sync

Redis 提供了多種 AOF 緩衝區同步檔案策略，在配置檔案中通過 appendfsync 引數進行配置，具體如下：

• always

  命令寫入緩衝區後立即呼叫系統 fsync 操作同步到 AOF 檔案中，效能較差但資料完整性較好

• everysec

  命令寫入緩衝區後每秒呼叫一次系統 fsync 操作同步到 AOF 檔案中，可能丟失本秒鐘的資料

• no

  命令寫入緩衝區後由作業系統決定多久呼叫一次系統 fsync 操作同步到 AOF 檔案中（通常最長30秒）

2.4 rewrite

2.4.1 重寫

AOF 重寫機制可以壓縮檔案體積（如合併多條寫命令），AOF 重寫過程可以手動觸發和自動觸發：

• 手動觸發：呼叫 bgrewriteaof 命令
• 自動觸發：根據配置檔案中的 auto-aof-rewrite-percentage 100 和 auto-aof-rewrite-min-size 64mb 引數確定觸發時機。

2.4.2 重寫流程

1. 執行 bhrewriteaof 重寫請求

   若當前程序正在執行 bhrewriteaof，請求不執行直接返回；

   若當前程序正在執行 bgsave 操作，命令延遲到 bgsave 完成後再執行

2. 父程序執行 fork 建立子程序

3. 接下來分為兩步：

   • 主程序繼續響應其他命令，所有修改命令寫入 aof_buf 緩衝區並根據 appendsync 策略同步到硬碟
   • fork 操作運用寫時複製技術，子程序只能共享 fork 操作時的記憶體資料。由於父程序依然響應命令，Redis 使用 aof_rewrite_buf 緩衝區儲存這部分新資料，防止新 AOF 檔案生產期間丟失這部分資料

4. 子程序根據記憶體快照，按照命令合併規則寫入到新的 AOF 檔案

5. 接下來分為三步：

   • 新 AOF 檔案寫入完成後，子程序給父程序傳送訊號，父程序更新統計資訊
   • 父程序把 aof_rewrite_buf 緩衝區的資料寫入到 AOF 檔案
   • 使用新的 AOF 檔案替換掉舊的，完成重寫

2.5 load

AOF 和 RDB 同時開啟時，優先載入 AOF 檔案。