Redis 持久化機制

概述

Redis 官方提供了兩種不同的持久化方法來將數據存儲到硬碟，分別是：

• 快照（Snapshot）
• AOF（Append Only File）只追加日誌文件

預設開啟快照，同時啟用兩種持久化方式時，優先 AOF

快照（Snapshot）

這種方式可以將某一時刻的所有數據都寫入硬碟，保存的文件以 .rdb 形式結尾的文件，因此也稱 RDB 方式

1. 快照生成方式

1.1 客戶端方式

Redis 提供了兩個命令來生成 RDB 文件，分別是 save 和 bgsave，他們的區別就在於：save 在「主進程」執行，有可能阻塞「主進程」，而 bgsave 會創建一個「子進程」執行

1.2 伺服器配置

save 3600 1 300 100 60 10000

上述是 redis.conf 中的相關內容，需要註意的點有兩個：

• 如果配置 save "" 可以完全禁用快照
• redis 預設開啟快照，並且預設配置如下：save 3600 1 300 100 60 10000，它的意思是，只要滿足下麵條件的任意一個，就會執行 bgsave
  • 3600 秒（1 小時）之內，對資料庫進行了至少 1 次修改
  • 300 秒（5 分鐘）之內，對資料庫進行了至少 100 次修改
  • 60 秒之內，對資料庫進行了至少 10000 次修改

如果我們要自定義快照生成頻率，只需要按照模板修改就好了

2. 保存快照

# rdb快照文件名
dbfilename dump.rdb
# rdb快照文件存放目錄,請確保有寫許可權
dir ./

3. 其他相關配置

# 預設使用bgsave持久化時,如果發生錯誤,將停止寫RDB快照文件,用戶有時很難意識到數據並沒有正確的被持久化
# 如果你已經設置了對Redis服務的正確監控,可以考慮關閉該特性,允許忽略錯誤,繼續寫RDB快照文件
# yes:開啟 no:關閉
stop-writes-on-bgsave-error yes
# 是否使用LZF壓縮字元串對象,一般建議開啟
# yes:開啟 no:關閉
rdbcompression yes
# 在寫入和讀取RDB文件時是否檢查有無損壞
# yes:開啟 no:關閉
rdbchecksum yes
# 載入RDB或還原負載時,啟用或禁用ziplist和listpack等完全消毒檢查
# yes:檢查 no:不檢查 clients:只對用戶連接執行檢查
sanitize-dump-payload no
# 在未啟用持久性的實例中刪除複製使用的RDB文件,預設情況下此選項處於禁用狀態
# 此項僅適用於同時禁用AOF和RDB持久性的實例,否則將完全忽略
rdb-del-sync-files no

4. bgsave 執行原理

當接收到 bgsave 命令時，redis 會調用 fork 創建一個子進程，子進程負責將快照寫入磁碟，父進程則繼續處理命令

父進程可以繼續執行命令，也就是數據能被修改，關鍵在於使用了「寫時複製技術」，通過 fork 創建的子進程，和父進程共用同一片記憶體數據，子進程會複製父進程的頁表，但是頁表指向的物理記憶體還是同一個，這是為了加快創建子進程的速度，所以，子進程可以直接讀取主進程的記憶體數據，並寫入 RDB 文件

當主進程對共用數據只是只讀操作，那麼子進程和父進程互不影響，但如果主進程要修改共用數據的某一項，就會發生寫時複製，這塊數據會被覆制一份，然後主進程在該副本進行修改，子進程繼續把原來的數據寫入 RDB 文件，也就是說，主進程剛修改的數據，是沒辦法在這一時間寫入 RDB 文件的，只能交由下一次的 bgsave 快照

5. 自動觸發

除了上述的方式以外，以下情況也會自動生成快照：

• 主從複製時，從節點從主節點進行全量複製時會觸發 bgsave 操作，生成當時的快照發送到從節點
• 執行 debug reload 命令重新載入 redis 時會觸發 bgsave 操作
• 執行 shutdown 命令時，如果沒有開啟 aof 持久化，會觸發 bgsave 操作

只追加日誌文件（Append Only File）

這種方式可以將所有客戶端執行的寫命令記錄到日誌文件中，以此記錄數據發生的變化。只要 Redis 從頭到尾執行一次 AOF 文件所包含的所有寫命令，就可以恢復 AOF 文件的記錄的數據集

1. 觸發 AOF 持久化

redis 預設配置沒有開啟 AOF 持久化機制，需要在 redis.conf 開啟

# yes:開啟AOF持久化 no:關閉AOF持久化
appendonly yes
# 指定生成AOF文件名稱
appendfilename "appendonly.aof"
# 指定存儲AOF文件的文件夾名稱
appenddirname "appendonlydir"
# AOF文件的保存位置和RDB文件的位置相同，都是通過dir參數設置
dir ./

從 Redis7 版本開始，使用一組 aof 文件記錄數據，分為兩種基本類型：

1. 基本文件，表示文件創建時的完整的數據，可以是 rdb 或 aof 內容格式
2. 增量文件，記錄前一個文件之後的新增命令
3. 清單文件，追蹤文件的創建和使用順序

文件名是以 appendfilename 首碼，後面跟著序號和類型，因此 aof 文件目錄里生成的文件大概有：

1. 基本文件 appendonly.aof.1.base.rdb
2. 增量文件 appendonly.aof.1.incr.aof，appendonly.aof.2.incr.aof......
3. 清單文件 appendonly.aof.manifest

2. 寫回策略

Redis 是先執行寫操作命令，再將該命令記錄到 AOF 日誌，只有寫操作命令執行成功，才會進行記錄，這兩個操作都在主線程進行，都會占用磁碟 I/O，因此 AOF 日誌寫回磁碟的時機很重要

寫回策略分為三種：

• always（謹慎使用）：每條 Redis 操作命令都會寫入磁碟，最多丟失一條數據
• everysec（預設）：每秒鐘寫入一次磁碟，最多丟失一秒的數據
• no（不推薦）：由操作系統決定何時寫入磁碟，Linux 預設 30s 寫入一次數據至磁碟

配置項如下：

appendfsync everysec

至於這三種策略是如何實現的，其實只是在控制 fsync() 函數的調用時機

當應用程式向文件寫入數據時，內核通常先將數據複製到內核緩衝區中，然後排入隊列，然後由內核決定何時寫入硬碟

如果想要應用程式向文件寫入數據後，能立馬將數據同步到硬碟，就可以調用 fsync() 函數，這樣內核就會將內核緩衝區的數據直接寫入到硬碟，等到硬碟寫操作完成後，該函數才會返回

• Always 策略就是每次寫入 AOF 文件數據後，就執行 fsync() 函數
• Everysec 策略就會創建一個非同步任務來執行 fsync() 函數
• No 策略就是永不執行 fsync() 函數

3. 重寫 AOF 文件

AOF 持久化機制會記錄每個寫命令，因此 AOF 文件會越來越大，會影響數據恢復的效率。AOF 文件重寫會將記憶體中的資料庫內容用命令的方式重寫一個新的 aof 文件，替換原有文件，減小 aof 文件體積

3.1 觸發重寫的方式

第一種方式：客戶端執行 BGREWRITEAOF 命令觸發重寫，不會阻塞 redis 服務

第二種方式：在伺服器配置自動觸發

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

如上配置，啟用 AOF 持久化後，當 AOF 文件體積大於 64 M，並且 AOF 文件體積比上次重寫之後體積大了至少一倍時，會自動觸發重寫

指定百分比為 0 可以禁用自動 AOF 重寫

auto-aof-rewrite-percentage 0

3.2 重寫流程

1. bgrewriteaof 觸發重寫，判斷是否當前有 bgsave 或 bgrewriteaof 在運行，如果有，則等待該命令結束後再繼續執行
2. 主進程 fork 出子進程執行重寫操作，保證主進程不會阻塞
3. 子進程遍歷 redis 記憶體中數據到臨時文件，客戶端的寫請求同時寫入 aof_buf 緩衝區和 aof_rewrite_buf 重寫緩衝區，保證原 AOF 文件完整以及新 AOF 文件生成期間的新的數據修改動作不會丟失
4. 子進程寫完新的 AOF 文件後，向主進程發信號，父進程更新統計信息。主進程把 aof_rewrite_buf 中的數據寫入到新的 AOF 文件
5. 使用新的 AOF 文件覆蓋舊的 AOF 文件，完成 AOF 重寫

4. 其他配置

# 前面講過,AOF是調用fsync()函數將寫操作記錄寫回磁碟,這會占用一定的磁碟I/O
# 如果設為yes,相當於appendfsync no,不會執行寫磁碟操作,只是寫入緩衝區,緩解磁碟壓力
no-appendfsync-on-rewrite no
# 在Redis啟動過程中,當AOF數據重新載入回記憶體時,可能會發現AOF文件在最後被截斷
# 如果設置為yes,則載入一個截斷的AOF文件,並通過日誌告訴用戶該事件
# 如果設置為no,伺服器將因錯誤而中止並拒絕啟動,用戶需要使用“redis-check-aof”實用程式修複AOF文件
aof-load-truncated yes
# 開啟混合持久化,下麵會提到
aof-use-rdb-preamble yes
# 支持在aof中記錄時間戳,可以在特定時間恢複數據,但會改變aof格式,可能跟已經存在的aof文件不相容
aof-timestamp-enabled no

RDB 和 AOF 混合方式

Redis4.0 提出了一個混合使用 AOF 日誌和記憶體快照的方法，混合持久化同樣也是通過 bgrewriteaof 重寫命令完成的，不同的是，當開啟混合持久化後，fork 出的子進程先將共用的記憶體副本全量的以 RDB 方式寫入 aof 文件，然後在將重寫緩衝區的增量命令以 AOF 方式寫入到文件，寫入完成後通知主進程更新統計信息，並將新的含有 RDB 格式和 AOF 格式的 AOF 文件替換舊的的 AOF 文件

配置如下：

aof-use-rdb-preamble yes

備份數據

備份 RDB 文件只需將其拷貝到安全的地方，伺服器運行時複製 RDB 文件很安全，因為 RDB 文件一旦創建就不會修改了

備份 AOF 在 Redis7.0.0 之前也可直接拷貝，但 7.0.0 版本之後會在 aof 文件夾下有多個文件，在 aof 重寫時拷貝可能會得到無法使用的文件，所以在備份時需要關閉 aof 重寫，步驟：

• 關閉自動 aof 重寫：CONFIG SET auto-aof-rewrite-percentage 0
• 確保在此期間沒有手動 BGREWRITEAOF 啟動重寫
• 檢查是否正在重寫，查詢 INFO persistence，如果返回1，則要等待重寫完成
• 將 aof 文件夾拷貝到安全地方
• 重新打開自動 aof 重寫：CONFIG SET auto-aof-rewrite-percentage <prev-value>