Redis 持久化機制

概述

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

  • 快照(Snapshot)
  • AOF(Append Only File)只追加日誌文件

默認開啟快照,同時啟用兩種持久化方式時,優先 AOF

快照(Snapshot)

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

1. 快照生成方式

1.1 客戶端方式

Redis 提供了兩個命令來生成 RDB 文件,分別是 savebgsave,他們的區別就在於: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>

Tags: