持久化的功能：Redis是內(nèi)存數(shù)據(jù)庫，數(shù)據(jù)都是存儲在內(nèi)存中,，為了避免進程退出導致數(shù)據(jù)的永久丟失,，需要定期將Redis中的數(shù)據(jù)以某種形式(數(shù)據(jù)或命令)從內(nèi)存保存到硬盤；當下次Redis重啟時,，利用持久化文件實現(xiàn)數(shù)據(jù)恢復,。

除此之外，為了進行災(zāi)難備份,，可以將持久化文件拷貝到一個遠程位置。

Redis持久化分為RDB持久化和AOF持久化：前者將當前數(shù)據(jù)保存到硬盤,，后者則是將每次執(zhí)行的寫命令保存到硬盤,；由于AOF持久化的實時性更好，即當進程意外退出時丟失的數(shù)據(jù)更少,，因此AOF是目前主流的持久化方式,，不過RDB持久化仍然有其用武之地。

下面依次介紹RDB持久化和AOF持久化,；由于Redis各個版本之間存在差異,，以Redis3.0為準。

RDB持久化是將當前進程中的數(shù)據(jù)生成快照保存到硬盤(因此也稱作快照持久化),，保存的文件后綴是rdb,；當Redis重新啟動時，可以讀取快照文件恢復數(shù)據(jù),。

1. 觸發(fā)條件

RDB持久化的觸發(fā)分為手動觸發(fā)和自動觸發(fā)兩種,。

1) 手動觸發(fā)

save命令和bgsave命令都可以生成RDB文件。

save命令會阻塞Redis服務(wù)器進程,，直到RDB文件創(chuàng)建完畢為止,，在Redis服務(wù)器阻塞期間，服務(wù)器不能處理任何命令請求,。

而bgsave命令會創(chuàng)建一個子進程,，由子進程來負責創(chuàng)建RDB文件，父進程(即Redis主進程)則繼續(xù)處理請求,。

此時服務(wù)器執(zhí)行日志如下：

bgsave命令執(zhí)行過程中,，只有fork子進程時會阻塞服務(wù)器，而對于save命令,，整個過程都會阻塞服務(wù)器,，因此save已基本被廢棄，線上環(huán)境要杜絕save的使用,；后文中也將只介紹bgsave命令,。此外,，在自動觸發(fā)RDB持久化時，Redis也會選擇bgsave而不是save來進行持久化,；下面介紹自動觸發(fā)RDB持久化的條件,。

2) 自動觸發(fā)

save m n

自動觸發(fā)最常見的情況是在配置文件中通過save m n，指定當m秒內(nèi)發(fā)生n次變化時,，會觸發(fā)bgsave,。

例如，查看redis的默認配置文件(Linux下為redis根目錄下的redis.conf),，可以看到如下配置信息：

其中save 900 1的含義是：當時間到900秒時,，如果redis數(shù)據(jù)發(fā)生了至少1次變化，則執(zhí)行bgsave,；save 300 10和save 60 10000同理,。當三個save條件滿足任意一個時，都會引起bgsave的調(diào)用,。

save m n的實現(xiàn)原理

Redis的save m n,，是通過serverCron函數(shù)、dirty計數(shù)器,、和lastsave時間戳來實現(xiàn)的,。

serverCron是Redis服務(wù)器的周期性操作函數(shù)，默認每隔100ms執(zhí)行一次,；該函數(shù)對服務(wù)器的狀態(tài)進行維護,，其中一項工作就是檢查 save m n 配置的條件是否滿足，如果滿足就執(zhí)行bgsave,。

dirty計數(shù)器是Redis服務(wù)器維持的一個狀態(tài),，記錄了上一次執(zhí)行bgsave/save命令后，服務(wù)器狀態(tài)進行了多少次修改(包括增刪改),；而當save/bgsave執(zhí)行完成后,，會將dirty重新置為0。

例如,，如果Redis執(zhí)行了set mykey helloworld,，則dirty值會 1；

如果執(zhí)行了sadd myset v1 v2 v3,，則dirty值會 3,；注意dirty記錄的是服務(wù)器進行了多少次修改，而不是客戶端執(zhí)行了多少修改數(shù)據(jù)的命令,。

lastsave時間戳也是Redis服務(wù)器維持的一個狀態(tài),，記錄的是上一次成功執(zhí)行save/bgsave的時間。

save m n的原理如下：每隔100ms,，執(zhí)行serverCron函數(shù),；在serverCron函數(shù)中,，遍歷save m n配置的保存條件，只要有一個條件滿足,，就進行bgsave,。對于每一個save m n條件，只有下面兩條同時滿足時才算滿足：

（1）當前時間-lastsave > m

（2）dirty >= n

save m n 執(zhí)行日志

下圖是save m n觸發(fā)bgsave執(zhí)行時,，服務(wù)器打印日志的情況：

其他自動觸發(fā)機制

除了save m n 以外,，還有一些其他情況會觸發(fā)bgsave：

在主從復制場景下，如果從節(jié)點執(zhí)行全量復制操作,，則主節(jié)點會執(zhí)行bgsave命令,，并將rdb文件發(fā)送給從節(jié)點。

執(zhí)行shutdown命令時,，自動執(zhí)行rdb持久化,，如下圖所示：

2. 執(zhí)行流程

前面介紹了觸發(fā)bgsave的條件，下面將說明bgsave命令的執(zhí)行流程,，如下圖所示

圖片中的5個步驟所進行的操作如下：

1)  Redis父進程首先判斷：當前是否在執(zhí)行save，或bgsave/bgrewriteaof（后面會詳細介紹該命令）的子進程,，如果在執(zhí)行則bgsave命令直接返回,。bgsave/bgrewriteaof 的子進程不能同時執(zhí)行，主要是基于性能方面的考慮：兩個并發(fā)的子進程同時執(zhí)行大量的磁盤寫操作,，可能引起嚴重的性能問題,。

2)  父進程執(zhí)行fork操作創(chuàng)建子進程，這個過程中父進程是阻塞的,，Redis不能執(zhí)行來自客戶端的任何命令

3)  父進程fork后,，bgsave命令返回”Background saving started”信息并不再阻塞父進程，并可以響應(yīng)其他命令

4)  子進程創(chuàng)建RDB文件,，根據(jù)父進程內(nèi)存快照生成臨時快照文件,，完成后對原有文件進行原子替換

5)  子進程發(fā)送信號給父進程表示完成，父進程更新統(tǒng)計信息

3. RDB文件

RDB文件是經(jīng)過壓縮的二進制文件,，下面介紹關(guān)于RDB文件的一些細節(jié),。

存儲路徑

RDB文件的存儲路徑既可以在啟動前配置，也可以通過命令動態(tài)設(shè)定,。

配置：dir配置指定目錄,，dbfilename指定文件名。默認是Redis根目錄下的dump.rdb文件,。

動態(tài)設(shè)定：Redis啟動后也可以動態(tài)修改RDB存儲路徑,，在磁盤損害或空間不足時非常有用；執(zhí)行命令為config set dir {newdir}和config set dbfilename {newFileName},。如下所示(Windows環(huán)境)：

RDB文件格式

RDB文件格式如下圖所示（圖片來源：《Redis設(shè)計與實現(xiàn)》）：

其中各個字段的含義說明如下：

1)  REDIS：常量,，保存著”REDIS”5個字符,。

2)  db_version：RDB文件的版本號,，注意不是Redis的版本號,。

3)  SELECTDB 0 pairs：表示一個完整的數(shù)據(jù)庫(0號數(shù)據(jù)庫),，同理SELECTDB 3 pairs表示完整的3號數(shù)據(jù)庫,；只有當數(shù)據(jù)庫中有鍵值對時,，RDB文件中才會有該數(shù)據(jù)庫的信息(上圖所示的Redis中只有0號和3號數(shù)據(jù)庫有鍵值對),；如果Redis中所有的數(shù)據(jù)庫都沒有鍵值對，則這一部分直接省略,。其中：SELECTDB是一個常量，代表后面跟著的是數(shù)據(jù)庫號碼,；0和3是數(shù)據(jù)庫號碼,；pairs則存儲了具體的鍵值對信息，包括key,、value值,，及其數(shù)據(jù)類型、內(nèi)部編碼,、過期時間,、壓縮信息等等,。

4)  EOF：常量，標志RDB文件正文內(nèi)容結(jié)束。

5)  check_sum：前面所有內(nèi)容的校驗和；Redis在載入RBD文件時，會計算前面的校驗和并與check_sum值比較，判斷文件是否損壞。

壓縮

Redis默認采用LZF算法對RDB文件進行壓縮。雖然壓縮耗時,，但是可以大大減小RDB文件的體積，因此壓縮默認開啟；可以通過命令關(guān)閉：

需要注意的是,，RDB文件的壓縮并不是針對整個文件進行的,，而是對數(shù)據(jù)庫中的字符串進行的,，且只有在字符串達到一定長度(20字節(jié))時才會進行。

4. 啟動時加載

RDB文件的載入工作是在服務(wù)器啟動時自動執(zhí)行的,，并沒有專門的命令,。但是由于AOF的優(yōu)先級更高，因此當AOF開啟時,，Redis會優(yōu)先載入AOF文件來恢復數(shù)據(jù),；

只有當AOF關(guān)閉時，才會在Redis服務(wù)器啟動時檢測RDB文件,，并自動載入,。服務(wù)器載入RDB文件期間處于阻塞狀態(tài)，直到載入完成為止。

Redis啟動日志中可以看到自動載入的執(zhí)行：

Redis載入RDB文件時,，會對RDB文件進行校驗,，如果文件損壞,，則日志中會打印錯誤,，Redis啟動失敗,。

5. RDB常用配置總結(jié)

下面是RDB常用的配置項，以及默認值；前面介紹過的這里不再詳細介紹,。

save m n：bgsave自動觸發(fā)的條件,；如果沒有save m n配置,，相當于自動的RDB持久化關(guān)閉,，不過此時仍可以通過其他方式觸發(fā),。

stop-writes-on-bgsave-error yes：當bgsave出現(xiàn)錯誤時，Redis是否停止執(zhí)行寫命令,；設(shè)置為yes,，則當硬盤出現(xiàn)問題時，可以及時發(fā)現(xiàn),，避免數(shù)據(jù)的大量丟失,；設(shè)置為no，則Redis無視bgsave的錯誤繼續(xù)執(zhí)行寫命令,，當對Redis服務(wù)器的系統(tǒng)(尤其是硬盤)使用了監(jiān)控時,，該選項考慮設(shè)置為no。

rdbcompression yes：是否開啟RDB文件壓縮

rdbchecksum yes：是否開啟RDB文件的校驗,，在寫入文件和讀取文件時都起作用,；關(guān)閉checksum在寫入文件和啟動文件時大約能帶來10%的性能提升，但是數(shù)據(jù)損壞時無法發(fā)現(xiàn)

dbfilename dump.rdb：RDB文件名

dir ./：RDB文件和AOF文件所在目錄

RDB持久化是將進程數(shù)據(jù)寫入文件,，而AOF持久化(即Append Only File持久化),，則是將Redis執(zhí)行的每次寫命令記錄到單獨的日志文件中（有點像MySQL的binlog）；當Redis重啟時再次執(zhí)行AOF文件中的命令來恢復數(shù)據(jù),。

與RDB相比,，AOF的實時性更好,，因此已成為主流的持久化方案。

1. 開啟AOF

Redis服務(wù)器默認開啟RDB,，關(guān)閉AOF,；要開啟AOF，需要在配置文件中配置：

appendonly yes

2. 執(zhí)行流程

由于需要記錄Redis的每條寫命令,，因此AOF不需要觸發(fā),，下面介紹AOF的執(zhí)行流程。

AOF的執(zhí)行流程包括：

命令追加(append)：將Redis的寫命令追加到緩沖區(qū)aof_buf,；

文件寫入(write)和文件同步(sync)：根據(jù)不同的同步策略將aof_buf中的內(nèi)容同步到硬盤,；

文件重寫(rewrite)：定期重寫AOF文件，達到壓縮的目的,。

1) 命令追加(append)

Redis先將寫命令追加到緩沖區(qū),，而不是直接寫入文件，主要是為了避免每次有寫命令都直接寫入硬盤,，導致硬盤IO成為Redis負載的瓶頸,。

命令追加的格式是Redis命令請求的協(xié)議格式，它是一種純文本格式,，具有兼容性好,、可讀性強、容易處理,、操作簡單避免二次開銷等優(yōu)點,；具體格式略。在AOF文件中,，除了用于指定數(shù)據(jù)庫的select命令（如select 0 為選中0號數(shù)據(jù)庫）是由Redis添加的,，其他都是客戶端發(fā)送來的寫命令。

2) 文件寫入(write)和文件同步(sync)

Redis提供了多種AOF緩存區(qū)的同步文件策略,，策略涉及到操作系統(tǒng)的write函數(shù)和fsync函數(shù),，說明如下：

為了提高文件寫入效率，在現(xiàn)代操作系統(tǒng)中,，當用戶調(diào)用write函數(shù)將數(shù)據(jù)寫入文件時,，操作系統(tǒng)通常會將數(shù)據(jù)暫存到一個內(nèi)存緩沖區(qū)里，當緩沖區(qū)被填滿或超過了指定時限后,，才真正將緩沖區(qū)的數(shù)據(jù)寫入到硬盤里,。

這樣的操作雖然提高了效率，但也帶來了安全問題：如果計算機停機,，內(nèi)存緩沖區(qū)中的數(shù)據(jù)會丟失,；因此系統(tǒng)同時提供了fsync、fdatasync等同步函數(shù),，可以強制操作系統(tǒng)立刻將緩沖區(qū)中的數(shù)據(jù)寫入到硬盤里,，從而確保數(shù)據(jù)的安全性,。

AOF緩存區(qū)的同步文件策略由參數(shù)appendfsync控制，各個值的含義如下：

always：命令寫入aof_buf后立即調(diào)用系統(tǒng)fsync操作同步到AOF文件,，fsync完成后線程返回,。

這種情況下,，每次有寫命令都要同步到AOF文件,，硬盤IO成為性能瓶頸，Redis只能支持大約幾百TPS寫入,，嚴重降低了Redis的性能,；即便是使用固態(tài)硬盤（SSD），每秒大約也只能處理幾萬個命令,，而且會大大降低SSD的壽命,。

no：命令寫入aof_buf后調(diào)用系統(tǒng)write操作，不對AOF文件做fsync同步,；同步由操作系統(tǒng)負責,，通常同步周期為30秒。這種情況下,，文件同步的時間不可控,，且緩沖區(qū)中堆積的數(shù)據(jù)會很多，數(shù)據(jù)安全性無法保證,。

everysec：命令寫入aof_buf后調(diào)用系統(tǒng)write操作,，write完成后線程返回,；fsync同步文件操作由專門的線程每秒調(diào)用一次,。everysec是前述兩種策略的折中,，是性能和數(shù)據(jù)安全性的平衡,，因此是Redis的默認配置,，也是我們推薦的配置,。

3) 文件重寫(rewrite)

隨著時間流逝，Redis服務(wù)器執(zhí)行的寫命令越來越多,，AOF文件也會越來越大,；過大的AOF文件不僅會影響服務(wù)器的正常運行,，也會導致數(shù)據(jù)恢復需要的時間過長。

文件重寫是指定期重寫AOF文件,，減小AOF文件的體積,。需要注意的是，AOF重寫是把Redis進程內(nèi)的數(shù)據(jù)轉(zhuǎn)化為寫命令,，同步到新的AOF文件,；不會對舊的AOF文件進行任何讀取、寫入操作!

關(guān)于文件重寫需要注意的另一點是：對于AOF持久化來說,，文件重寫雖然是強烈推薦的,，但并不是必須的；即使沒有文件重寫,，數(shù)據(jù)也可以被持久化并在Redis啟動的時候?qū)?；因此在一些實現(xiàn)中，會關(guān)閉自動的文件重寫,，然后通過定時任務(wù)在每天的某一時刻定時執(zhí)行,。

文件重寫之所以能夠壓縮AOF文件，原因在于：

過期的數(shù)據(jù)不再寫入文件

無效的命令不再寫入文件：如有些數(shù)據(jù)被重復設(shè)值(set mykey v1, set mykey v2),、有些數(shù)據(jù)被刪除了(sadd myset v1, del myset)等等

多條命令可以合并為一個：如sadd myset v1, sadd myset v2, sadd myset v3可以合并為sadd myset v1 v2 v3,。不過為了防止單條命令過大造成客戶端緩沖區(qū)溢出，對于list,、set,、hash、zset類型的key,，并不一定只使用一條命令,；而是以某個常量為界將命令拆分為多條。這個常量在redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD中定義,，不可更改,，3.0版本中值是64。

通過上述內(nèi)容可以看出,，由于重寫后AOF執(zhí)行的命令減少了,，文件重寫既可以減少文件占用的空間,，也可以加快恢復速度。

文件重寫的觸發(fā)

文件重寫的觸發(fā),，分為手動觸發(fā)和自動觸發(fā)：

手動觸發(fā)：直接調(diào)用bgrewriteaof命令,，該命令的執(zhí)行與bgsave有些類似：都是fork子進程進行具體的工作，且都只有在fork時阻塞,。

此時服務(wù)器執(zhí)行日志如下：

自動觸發(fā)：根據(jù)auto-aof-rewrite-min-size和auto-aof-rewrite-percentage參數(shù),，以及aof_current_size和aof_base_size狀態(tài)確定觸發(fā)時機。

auto-aof-rewrite-min-size：執(zhí)行AOF重寫時,，文件的最小體積,，默認值為64MB,。

auto-aof-rewrite-percentage：執(zhí)行AOF重寫時,，當前AOF大小(即aof_current_size)和上一次重寫時AOF大小(aof_base_size)的比值。

其中,，參數(shù)可以通過config get命令查看：

狀態(tài)可以通過info persistence查看：

只有當auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個參數(shù)同時滿足時,，才會自動觸發(fā)AOF重寫，即bgrewriteaof操作,。

自動觸發(fā)bgrewriteaof時,，可以看到服務(wù)器日志如下：

文件重寫的流程

文件重寫流程如下圖所示

關(guān)于文件重寫的流程，有兩點需要特別注意：(1)重寫由父進程fork子進程進行,；(2)重寫期間Redis執(zhí)行的寫命令,，需要追加到新的AOF文件中，為此Redis引入了aof_rewrite_buf緩存,。

對照上圖,，文件重寫的流程如下：

1) Redis父進程首先判斷當前是否存在正在執(zhí)行 bgsave/bgrewriteaof的子進程，如果存在則bgrewriteaof命令直接返回,，如果存在bgsave命令則等bgsave執(zhí)行完成后再執(zhí)行,。前面曾介紹過，這個主要是基于性能方面的考慮,。

2) 父進程執(zhí)行fork操作創(chuàng)建子進程,，這個過程中父進程是阻塞的。

3.1) 父進程fork后,，bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父進程,，并可以響應(yīng)其他命令。Redis的所有寫命令依然寫入AOF緩沖區(qū),，并根據(jù)appendfsync策略同步到硬盤,，保證原有AOF機制的正確。

3.2) 由于fork操作使用寫時復制技術(shù),，子進程只能共享fork操作時的內(nèi)存數(shù)據(jù),。由于父進程依然在響應(yīng)命令,，因此Redis使用AOF重寫緩沖區(qū)(圖中的aof_rewrite_buf)保存這部分數(shù)據(jù)，防止新AOF文件生成期間丟失這部分數(shù)據(jù),。也就是說,，bgrewriteaof執(zhí)行期間，Redis的寫命令同時追加到aof_buf和aof_rewirte_buf兩個緩沖區(qū),。

4) 子進程根據(jù)內(nèi)存快照,，按照命令合并規(guī)則寫入到新的AOF文件。

5.1) 子進程寫完新的AOF文件后,，向父進程發(fā)信號,，父進程更新統(tǒng)計信息，具體可以通過info persistence查看,。

5.2) 父進程把AOF重寫緩沖區(qū)的數(shù)據(jù)寫入到新的AOF文件,，這樣就保證了新AOF文件所保存的數(shù)據(jù)庫狀態(tài)和服務(wù)器當前狀態(tài)一致。

5.3) 使用新的AOF文件替換老文件,，完成AOF重寫,。

3. 啟動時加載

前面提到過，當AOF開啟時,，Redis啟動時會優(yōu)先載入AOF文件來恢復數(shù)據(jù),；只有當AOF關(guān)閉時，才會載入RDB文件恢復數(shù)據(jù),。

當AOF開啟,，且AOF文件存在時，Redis啟動日志：

當AOF開啟,，但AOF文件不存在時,，即使RDB文件存在也不會加載(更早的一些版本可能會加載，但3.0不會),，Redis啟動日志如下：

文件校驗

與載入RDB文件類似,，Redis載入AOF文件時，會對AOF文件進行校驗,，如果文件損壞,，則日志中會打印錯誤，Redis啟動失敗,。但如果是AOF文件結(jié)尾不完整(機器突然宕機等容易導致文件尾部不完整),，且aof-load-truncated參數(shù)開啟，則日志中會輸出警告,，Redis忽略掉AOF文件的尾部,，啟動成功。aof-load-truncated參數(shù)默認是開啟的：

偽客戶端

因為Redis的命令只能在客戶端上下文中執(zhí)行，而載入AOF文件時命令是直接從文件中讀取的,，并不是由客戶端發(fā)送,；因此Redis服務(wù)器在載入AOF文件之前，會創(chuàng)建一個沒有網(wǎng)絡(luò)連接的客戶端,，之后用它來執(zhí)行AOF文件中的命令,，命令執(zhí)行的效果與帶網(wǎng)絡(luò)連接的客戶端完全一樣。

4. AOF常用配置總結(jié)

下面是AOF常用的配置項,，以及默認值,；前面介紹過的這里不再詳細介紹。

appendonly no：是否開啟AOF

appendfilename 'appendonly.aof'：AOF文件名

dir ./：RDB文件和AOF文件所在目錄

appendfsync everysec：fsync持久化策略

no-appendfsync-on-rewrite no：AOF重寫期間是否禁止fsync,；如果開啟該選項,，可以減輕文件重寫時CPU和硬盤的負載（尤其是硬盤），但是可能會丟失AOF重寫期間的數(shù)據(jù),；需要在負載和安全性之間進行平衡

auto-aof-rewrite-percentage 100：文件重寫觸發(fā)條件之一

auto-aof-rewrite-min-size 64mb：文件重寫觸發(fā)提交之一

aof-load-truncated yes：如果AOF文件結(jié)尾損壞,，Redis啟動時是否仍載入AOF文件

本文主要內(nèi)容可以總結(jié)如下：

1、持久化在Redis高可用中的作用：數(shù)據(jù)備份,，與主從復制相比強調(diào)的是由內(nèi)存到硬盤的備份,。

2,、RDB持久化：將數(shù)據(jù)快照備份到硬盤,；介紹了其觸發(fā)條件（包括手動出發(fā)和自動觸發(fā)）、執(zhí)行流程,、RDB文件等,，特別需要注意的是文件保存操作由fork出的子進程來進行。

3,、AOF持久化：將執(zhí)行的寫命令備份到硬盤（類似于MySQL的binlog）,，介紹了其開啟方法、執(zhí)行流程等,，特別需要注意的是文件同步策略的選擇（everysec）,、文件重寫的流程。

4,、一些現(xiàn)實的問題：包括如何選擇持久化策略,，以及需要注意的fork阻塞、AOF追加阻塞等,。