Redis 持久化機制_ZenDei技術網路在線

概述 Redis 官方提供了兩種不同的持久化方法來將數據存儲到硬碟，分別是：快照（Snapshot） AOF（Append Only File）只追加日誌文件預設開啟快照，同時啟用兩種持久化方式時，優先 AOF 快照（Snapshot）這種方式可以將某一時刻的所有數據都寫入硬碟，保存的文件以 ...

概述

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 文件記錄數據，分為兩種基本類型：

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

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

基本文件 appendonly.aof.1.base.rdb
增量文件 appendonly.aof.1.incr.aof，appendonly.aof.2.incr.aof......
清單文件 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 重寫流程

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