Redis RDB與AOF持久化方式詳細講解

2022-11-23 14:00:03

1.RDB持久化

首先，RDB持久化方式會產生一個經過壓縮的二進位制檔案，Redis伺服器在啟動之初，通過這個檔案可以還原資料庫的狀態。那麼我們接下來看下RDB檔案是如何實現儲存和載入的。

1.1 RDB檔案的儲存

RDB檔案的儲存有兩個命令可以實現，分別是save和bgsave,執行後都會生成新的RDB檔案，區別是save會阻塞伺服器的程序，直到RDB檔案建立完成為止，期間伺服器不能處理任何使用者端的命令請求。而bgsave通過派生出一個子程序，由子程序來完成RDB檔案的建立，期間伺服器正常處理使用者端的命令請求。其實這兩個命令的底層實現方式都一樣，只不過一個是主程序來做，另一個是通過子程序來完成。

在redis.conf檔案中，有兩個引數是和rdb的檔案儲存相關：

// 這個是rdb檔案的名稱
dbfilename dump.rdb
// 這個是rdb檔案的儲存路徑，這是相對路徑，相對於redis-server的啟動路徑
dir ./

1.2 RDB檔案的載入

在redis伺服器啟動之初，會去查詢有沒有rdb的持久化檔案存在，如果有就會自動載入，當然前提是沒有開啟aof持久化的功能。在rdb載入期間會，伺服器處於阻塞裝填，直到載入工作完全結束。

1.3 RDB持久化時伺服器的狀態

save命令執行期間，所有使用者端命令都會被拒絕執行。

bgsave命令執行期間，使用者端傳送的save和bgsave命令會被拒絕執行，但是使用者端傳送的bgrewriteaof不會拒絕但會被阻塞，直到當前的bgsave命令執行完畢。但是值得說明的是，如果伺服器在執行bgrewriteaof命令期間，使用者端傳送的bgsave命令會被伺服器拒絕。當然這是站在效能角度考慮，否則fock出兩個子程序，大量的進行磁碟的讀寫，會影響整個伺服器的效能。

1.4 RDB持久化策略

使用者可以通過組態檔給RDB的持久化設定儲存策略，看一下redis.conf檔案中的設定：

save 900 1
save 300 10
save 60 10000

以上的預設設定可以表示為：伺服器在900秒之內，至少進行了1次的修改，在300秒之內至少進行了10次修改，在60秒之內至少進行了10000次修改。這三種策略只要滿足一個，即可觸發RDB的持久化。

這裡需要了解一下，Redis是怎麼基於這些設定策略實現自動化間歇性儲存RDB檔案的，還是回到RedisServer這個這個結構體的原始碼中看一下：

struct redisServer {
    // 陣列，用於儲存redis.conf設定的持久化策略
    struct saveparam *saveparams;   /* Save points array for RDB */
    // 上面這個陣列的長度
    int saveparamslen;              /* Number of saving points */
    // 記錄上一次持久化到現在伺服器修改了多少鍵值對
    long long dirty;                /* Changes to DB from the last save */
    // 記錄上一次RDB持久化的UNIX時間戳
    time_t lastsave;                /* Unix time of last successful save */
}

在redisServer中，有saveparams陣列專門儲存我們設定的持久化策略，這裡使用到了saveparam這個結構體，看一下原始碼：

struct saveparam {
	// 這裡是組態檔save的第1個引數
    time_t seconds;
    // 這裡是組態檔save的第2個引數
    int changes;
};

這樣，組態檔中的持久化策略就記錄到了redisServer.saveparam屬性中，還是會基於serverCron這個時間事件函數，100ms執行一次，每次會檢查 dirty 和 lastsave 記錄的修改鍵值對數量和時間差，是否匹配到了saveparam中設定的持久化策略，如果命中就進行新一輪的RDB持久化。

2.AOF持久化

和RDB不同，AOF是通過記錄Redis伺服器中執行的寫命令來記錄資料庫狀態的，類似於mysql的binlog，當然儲存的內容是經過協定轉換的命令。在伺服器啟動之初，通過載入和執行AOF檔案中的命令來還原資料庫的狀態。

2.1 持久化的實現

在伺服器執行命令之後，並不是立刻寫入aof檔案中，而是先寫入 aof_buf緩衝區裡面，這也是redisServer的一個屬性結構：

struct redisServer {
    // aop緩衝區，記錄伺服器寫入的命令
    sds aof_buf;      /* AOF buffer, written before entering the event loop */
}

我們再看一下redis.conf關於aof持久化的一個設定：

// 這個表示每次執行都會寫入
# appendfsync always
// 這個表示每秒寫入一次
appendfsync everysec
// 這個由作業系統決定，無法控制
# appendfsync no

AOF實現持久化的原理是這樣的，使用者端執行的命令會先記錄到 redisServer.aof_buf 中，然後基於組態檔的appendfsync策略決定什麼時候同步到AOF檔案中。這裡的同步也會經過兩個步驟：

aof_buf 內容寫入到作業系統檔案快取 pagecache；
pagecache 落盤寫入到屋裡磁碟裝置中；

我們知道Redis是基於Reactor網路模型，不斷進行事件迴圈，每進行一輪的事件迴圈，都會執行步驟1，所以從aof_buf 到 pagecache總是會發生。但是步驟2就跟appendfsync有關係了：

always表示只要步驟1發生，步驟2也會發生，所以是最安全，但是效率最慢的一個。
everysec表示步驟1發生後，步驟2每秒執行一次落盤，是效率和資料安全折中的方案，停機故障時有丟失1秒鐘資料的風險。
no表示步驟1發生後，何時落盤由作業系統決定，資料丟失風險大，效率也一般，因為資料量過大，單次落盤的時間也最長。

預設設定是everysec，即每秒執行一次資料落盤儲存。

2.2 檔案的載入與資料還原

因為AOF檔案中包含了重建資料庫狀態的所有寫命令，所以伺服器只要讀入並全部執行一遍就可以完成資料庫狀態的還原。伺服器在啟動之初，會建立一個不帶網路連線的偽使用者端來做這件事，在載入命令完成後，這個使用者端的使命就結束了。

2.3 AOF檔案的重寫

隨著寫入到AOF檔案的命令越來越多，這個檔案體積會越來大，會對宿主機或檔案還原造成一定的影響，所以需要通過AOF檔案的重寫來解決檔案體積膨脹的問題。

AOF檔案重寫並不是對現有AOF檔案進行處理，而是基於資料庫當前的狀態來實現的。伺服器會從資料庫中讀取鍵對應的值，然後用一條命令去記錄鍵值對，代替之前可能存在的多條命令，寫入到一個新的AOF檔案中，這就是AOF重寫功能實現的原理。需要注意的是，對於某些元素比較多的集合或者列表(預設設定是64個)，這個一條命令可能拆分成多條實現，避免造成使用者端輸入緩衝區溢位的情況。

和bgsave一樣，AOF重寫的動作也是放到子程序去執行，這樣可以保證父程序可以繼續處理名請求。但是這裡會有一個問題，就是AOF檔案重寫期間，父程序處理命令請求之後，會和重寫AOF檔案時的資料庫狀態不一致。Redis解決這個問題的方法是設定一個AOF重寫緩衝區，子程序一單建立並且開始重寫命令之後，父程序處理的所有寫命令請求都會記錄到AOF重寫緩衝區。當子程序重寫工作完成之後，會生成一個新的AOF檔案，向父程序傳送一個訊號，父程序在接受此訊號，開始執行以下工作：