技術文章 » Redis 持久化機制

Redis 持久化機制

2022-08-10 21:02:13

概述

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>