持久化

概念：利用永久性儲存介質儲存資料，在特定的時間將儲存的資料進行恢復的工作機制

作用：防止資料意外丟失，備份恢復；遠端建立資料副本

1. 持久化方式

• RDB——資料快照：將記憶體中當前資料狀態進行儲存，快照形式，儲存資料結果，儲存格式簡單。
• AOF——過程日誌：將資料的操作過程進行儲存。日誌形式，儲存操作過程，儲存格式複雜。

2中持久化方式既可以同時使用，又可以單獨使用，或都不使用。

2. 快照持久化

2.1 配置選項

dbfilename dump.rdb

• 設定磁碟上快照檔案的名稱，預設值為dump.rdb
• 通常設定為：dump-埠號.rdb

dir

• 設定儲存.rdb檔案的路徑
• 通常設定成儲存空間較大的目錄，目錄名稱data

rdbcompression yes

• 設定是否對快照檔案進行壓縮。預設yes，使用LZF壓縮
• 預設開啟狀態，如果設定為no，可節省CPU執行時間，但會使儲存檔案變大

2.2 啟動方式

save

客戶端向Redis傳送 save 命令來建立一個快照。在快照建立完畢前不會再響應其他命令，有可能造成長時間阻塞，線上環境不建議使用。

bgsave

客戶端向Redis傳送 bgsave 命令來建立一個快照。Redis會呼叫fork來建立一個子程序，由子程序負責將快照寫入磁碟，而父程序則繼續處理命令請求。

配置項：

• stop-writes-on-bgsave-error yes（預設）——後臺儲存過程中如果出現錯誤情況是否停止儲存操作。

save配置

在config檔案中設定了save配置選項，限定時間範圍內key的變化數量達到配置的數量即進行持久化。如果設定了多個save配置選項，那麼任意一個save配置選項所設定的條件被滿足時，都會觸發一次 bgsave 指令。

save second changes

• second：監控時間範圍
• changes：監控key的變化量

其他

• 全量複製
• 關閉伺服器——接收到 shutdown/term 命令，自動執行 save 命令

3. AOF持久化

3.1 配置選項

appendonly yes|no

• 是否開啟AOF持久化，預設不開啟

dbfilename appendonly.aof

• 設定磁碟上快照檔案的名稱，預設值為`appendonly.aof
• 通常設定為：appendonly-埠號.rdb

dir

• 設定儲存.aof檔案的路徑，與rdb持久化檔案一致即可

3.2 寫入策略

appendsync

• always——每個Redis寫命令都要同步寫入硬碟。會嚴重降低Redis的速度
• everysec——每秒執行一次同步，顯示地將多個寫命令同步到硬碟（宕機丟失1s內資料）
• no——讓作業系統來決定何時進行同步，整個過程不可控

3.2 AOF重寫

3.2.1 問題

• Redis不斷記錄寫命令，導致AOF檔案越來越大。甚至佔滿整個磁碟空間
• Redis重啟通過重新執行AOF檔案恢復資料，如果AOF檔案非常大，還原時間就可能會非常長

3.2.2 重寫方式

1. 手動重寫

方式：使用者向Redis傳送 BGREWRITEAOF 命令，該命令通過移除AOF檔案中的冗餘命令來重寫AOF檔案。 原理：與 BGSAVE 建立快照原理相似，Redis會建立一個子程序，由子程序負責對AOF檔案進行重寫。

2. 自動重寫

與快照持久化通過設定 save 選項自動執行 BGSAVE 一樣，AOF持久化可以通過設定如下兩個選項來自動執行 BGREWRITEAOF。

• auto-aof-rewrite-min-size size
• auto-aof-rewrite-percentage percentage

示例：

當AOF檔案的體積大於64MB，並且AOF檔案的體積比上一次重寫之後的體積大了至少一倍（100%）時，Rdis將自動執行 BGREWRITEAOF 命令。

• auto-aof-rewrite-min-size 64mb
• auto-aof-rewrite-percentage 100

4. RDB vs AOF