1.RDB持久化

 首先，RDB持久化方式會產(chǎn)生一個經(jīng)過壓縮的二進制文件，Redis服務(wù)器在啟動之初，通過這個文件可以還原數(shù)據(jù)庫的狀態(tài)。那么我們接下來看下RDB文件是如何實現(xiàn)保存和載入的。

1.1 RDB文件的保存

 RDB文件的保存有兩個命令可以實現(xiàn)，分別是save和bgsave,執(zhí)行后都會生成新的RDB文件，區(qū)別是save會阻塞服務(wù)器的進程，直到RDB文件創(chuàng)建完成為止，期間服務(wù)器不能處理任何客戶端的命令請求。而bgsave通過派生出一個子進程，由子進程來完成RDB文件的創(chuàng)建，期間服務(wù)器正常處理客戶端的命令請求。其實這兩個命令的底層實現(xiàn)方式都一樣，只不過一個是主進程來做，另一個是通過子進程來完成。

 在redis.conf文件中，有兩個參數(shù)是和rdb的文件保存相關(guān)：

// 這個是rdb文件的名稱
dbfilename dump.rdb
// 這個是rdb文件的保存路徑，這是相對路徑，相對于redis-server的啟動路徑
dir ./

1.2 RDB文件的載入

 在redis服務(wù)器啟動之初，會去查找有沒有rdb的持久化文件存在，如果有就會自動載入，當(dāng)然前提是沒有開啟aof持久化的功能。在rdb載入期間會，服務(wù)器處于阻塞裝填，直到載入工作完全結(jié)束。

1.3 RDB持久化時服務(wù)器的狀態(tài)

save命令執(zhí)行期間，所有客戶端命令都會被拒絕執(zhí)行。

bgsave命令執(zhí)行期間，客戶端發(fā)送的save和bgsave命令會被拒絕執(zhí)行，但是客戶端發(fā)送的bgrewriteaof不會拒絕但會被阻塞，直到當(dāng)前的bgsave命令執(zhí)行完畢。但是值得說明的是，如果服務(wù)器在執(zhí)行bgrewriteaof命令期間，客戶端發(fā)送的bgsave命令會被服務(wù)器拒絕。當(dāng)然這是站在性能角度考慮，否則fock出兩個子進程，大量的進行磁盤的讀寫，會影響整個服務(wù)器的性能。

1.4 RDB持久化策略

 用戶可以通過配置文件給RDB的持久化設(shè)置保存策略，看一下redis.conf文件中的配置：

save 900 1
save 300 10
save 60 10000

 以上的默認(rèn)配置可以表示為：服務(wù)器在900秒之內(nèi)，至少進行了1次的修改，在300秒之內(nèi)至少進行了10次修改，在60秒之內(nèi)至少進行了10000次修改。這三種策略只要滿足一個，即可觸發(fā)RDB的持久化。

 這里需要了解一下，Redis是怎么基于這些配置策略實現(xiàn)自動化間歇性保存RDB文件的，還是回到RedisServer這個這個結(jié)構(gòu)體的源碼中看一下：

struct redisServer {
    // 數(shù)組，用于保存redis.conf配置的持久化策略
    struct saveparam *saveparams;   /* Save points array for RDB */
    // 上面這個數(shù)組的長度
    int saveparamslen;              /* Number of saving points */
    // 記錄上一次持久化到現(xiàn)在服務(wù)器修改了多少鍵值對
    long long dirty;                /* Changes to DB from the last save */
    // 記錄上一次RDB持久化的UNIX時間戳
    time_t lastsave;                /* Unix time of last successful save */
}

 在redisServer中，有saveparams數(shù)組專門保存我們配置的持久化策略，這里使用到了saveparam這個結(jié)構(gòu)體，看一下源碼：

struct saveparam {
	// 這里是配置文件save的第1個參數(shù)
    time_t seconds;
    // 這里是配置文件save的第2個參數(shù)
    int changes;
};

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

2.AOF持久化

 和RDB不同，AOF是通過記錄Redis服務(wù)器中執(zhí)行的寫命令來記錄數(shù)據(jù)庫狀態(tài)的，類似于mysql的binlog，當(dāng)然保存的內(nèi)容是經(jīng)過協(xié)議轉(zhuǎn)換的命令。在服務(wù)器啟動之初，通過載入和執(zhí)行AOF文件中的命令來還原數(shù)據(jù)庫的狀態(tài)。

2.1 持久化的實現(xiàn)

 在服務(wù)器執(zhí)行命令之后，并不是立刻寫入aof文件中，而是先寫入 aof_buf緩沖區(qū)里面，這也是redisServer的一個屬性結(jié)構(gòu)：

struct redisServer {
    // aop緩沖區(qū)，記錄服務(wù)器寫入的命令
    sds aof_buf;      /* AOF buffer, written before entering the event loop */
}

 我們再看一下redis.conf關(guān)于aof持久化的一個配置：

// 這個表示每次執(zhí)行都會寫入
# appendfsync always
// 這個表示每秒寫入一次
appendfsync everysec
// 這個由操作系統(tǒng)決定，無法控制
# appendfsync no

 AOF實現(xiàn)持久化的原理是這樣的，客戶端執(zhí)行的命令會先記錄到 redisServer.aof_buf 中，然后基于配置文件的appendfsync策略決定什么時候同步到AOF文件中。這里的同步也會經(jīng)過兩個步驟：

• aof_buf 內(nèi)容寫入到操作系統(tǒng)文件緩存 pagecache；
• pagecache 落盤寫入到屋里磁盤設(shè)備中；

 我們知道Redis是基于Reactor網(wǎng)絡(luò)模型，不斷進行事件循環(huán)，每進行一輪的事件循環(huán)，都會執(zhí)行步驟1，所以從aof_buf 到 pagecache總是會發(fā)生。但是步驟2就跟appendfsync有關(guān)系了：

• always表示只要步驟1發(fā)生，步驟2也會發(fā)生，所以是最安全，但是效率最慢的一個。
• everysec表示步驟1發(fā)生后，步驟2每秒執(zhí)行一次落盤，是效率和數(shù)據(jù)安全折中的方案，停機故障時有丟失1秒鐘數(shù)據(jù)的風(fēng)險。
• no表示步驟1發(fā)生后，何時落盤由操作系統(tǒng)決定，數(shù)據(jù)丟失風(fēng)險大，效率也一般，因為數(shù)據(jù)量過大，單次落盤的時間也最長。

 默認(rèn)配置是everysec，即每秒執(zhí)行一次數(shù)據(jù)落盤保存。

2.2 文件的載入與數(shù)據(jù)還原

 因為AOF文件中包含了重建數(shù)據(jù)庫狀態(tài)的所有寫命令，所以服務(wù)器只要讀入并全部執(zhí)行一遍就可以完成數(shù)據(jù)庫狀態(tài)的還原。服務(wù)器在啟動之初，會創(chuàng)建一個不帶網(wǎng)絡(luò)連接的偽客戶端來做這件事，在載入命令完成后，這個客戶端的使命就結(jié)束了。

2.3 AOF文件的重寫

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

 AOF文件重寫并不是對現(xiàn)有AOF文件進行處理，而是基于數(shù)據(jù)庫當(dāng)前的狀態(tài)來實現(xiàn)的。服務(wù)器會從數(shù)據(jù)庫中讀取鍵對應(yīng)的值，然后用一條命令去記錄鍵值對，代替之前可能存在的多條命令，寫入到一個新的AOF文件中，這就是AOF重寫功能實現(xiàn)的原理。需要注意的是，對于某些元素比較多的集合或者列表(默認(rèn)配置是64個)，這個一條命令可能拆分成多條實現(xiàn)，避免造成客戶端輸入緩沖區(qū)溢出的情況。

 和bgsave一樣，AOF重寫的動作也是放到子進程去執(zhí)行，這樣可以保證父進程可以繼續(xù)處理名請求。但是這里會有一個問題，就是AOF文件重寫期間，父進程處理命令請求之后，會和重寫AOF文件時的數(shù)據(jù)庫狀態(tài)不一致。Redis解決這個問題的方法是設(shè)置一個AOF重寫緩沖區(qū)，子進程一單創(chuàng)建并且開始重寫命令之后，父進程處理的所有寫命令請求都會記錄到AOF重寫緩沖區(qū)。當(dāng)子進程重寫工作完成之后，會生成一個新的AOF文件，向父進程發(fā)送一個信號，父進程在接受此信號，開始執(zhí)行以下工作：

• 將AOF重寫緩沖區(qū)的內(nèi)容寫入到新的AOF文件中，保證新文件和服務(wù)器當(dāng)前的狀態(tài)一致；
• 對新的AOF文件改名，并原子的替換現(xiàn)有的AOF文件，完成新舊文件的替換。

 以上兩步，父進程會造成服務(wù)器進程的阻塞，但其他時間，都不會阻塞，整個重寫動作對服務(wù)器性能的影響降到了最低，以上就是bgrewriteaof命令的實現(xiàn)原理。

到此這篇關(guān)于Redis RDB與AOF持久化方式詳細講解的文章就介紹到這了,更多相關(guān)Redis RDB與AOF內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論