一、AOF（Append Only File）

Redis 每執(zhí)行一條寫操作命令，就把該命令以追加的方式寫入到一個文件里，然后重啟 Redis 的時候，先去讀取這個文件里的命令，并且執(zhí)行它。
注意：只會記錄寫操作命令，讀操作命令是不會被記錄的，因為沒意義。

AOF 日志文件其實就是普通的文本，我們可以通過 cat 命令查看里面的內(nèi)容，不過里面的內(nèi)容如果不知道一定的規(guī)則的話，可能會看不懂。
我這里以「set name mogu」命令作為例子，Redis 執(zhí)行了這條命令后，記錄在 AOF 日志里的內(nèi)容如下:

*3
$3
set 
$4
name
$4
mogu

我這里給大家解釋下。
「*3」表示當(dāng)前命令有三個部分，每部分都是以「$+數(shù)字」開頭，后面緊跟著具體的命令、鍵或值。然后，這里的「數(shù)字」表示這部分中的命令、鍵或值一共有多少字節(jié)。例如，「$3 set」表示這部分有 3 個字節(jié)，也就是「set」命令這個字符串的長度。
不知道大家注意到?jīng)]有，Redis 是先執(zhí)行寫操作命令后，才將該命令記錄到 AOF 日志里的，這么做其實有兩個好處。

• 避免額外的檢查開銷。
• 不會阻塞當(dāng)前寫操作命令的執(zhí)行，因為當(dāng)寫操作命令執(zhí)行成功后，才會將命令記錄到 AOF 日志。

當(dāng)然，AOF 持久化功能也不是沒有潛在風(fēng)險。

1. 執(zhí)行寫操作命令和記錄日志是兩個過程，那當(dāng) Redis 在還沒來得及將命令寫入到硬盤時，服務(wù)器發(fā)生宕機了，這個數(shù)據(jù)就會有丟失的風(fēng)險。
2. 前面說道，由于寫操作命令執(zhí)行成功后才記錄到 AOF 日志，所以不會阻塞當(dāng)前寫操作命令的執(zhí)行，但是可能會給「下一個」命令帶來阻塞風(fēng)險。因為將命令寫入到日志的這個操作也是在主進(jìn)程完成的（執(zhí)行命令也是在主進(jìn)程），也就是說這兩個操作是同步的。

認(rèn)真分析一下，其實這兩個風(fēng)險都有一個共性，都跟「 AOF 日志寫回硬盤的時機」有關(guān)。

1.1 過程分析

Redis 寫入 AOF 日志的過程，

1. Redis 執(zhí)行完寫操作命令后，會將命令追加到 server.aof_buf 緩沖區(qū)；
2. 然后通過 write() 系統(tǒng)調(diào)用，將 aof_buf 緩沖區(qū)的數(shù)據(jù)寫入到 AOF 文件，此時數(shù)據(jù)并沒有寫入到硬盤，而是拷貝到了內(nèi)核緩沖區(qū) page cache，等待內(nèi)核將數(shù)據(jù)寫入硬盤；
3. 具體內(nèi)核緩沖區(qū)的數(shù)據(jù)什么時候?qū)懭氲接脖P，由內(nèi)核決定。
   如下圖所示。
   

1.2 三種寫回硬盤的策略

在 redis.conf 配置文件中的 appendfsync 配置項可以有以下 3 種參數(shù)可填：

• Always，這個單詞的意思是「總是」，所以它的意思是每次寫操作命令執(zhí)行完后，同步將 AOF 日志數(shù)據(jù)寫回硬盤；可以最大程度保證數(shù)據(jù)不丟失，但不可避免會影響主進(jìn)程的性能。
• Everysec，這個單詞的意思是「每秒」，所以它的意思是每次寫操作命令執(zhí)行完后，先將命令寫入到 AOF 文件的內(nèi)核緩沖區(qū)，然后每隔一秒將緩沖區(qū)里的內(nèi)容寫回到硬盤；如果上一秒的寫操作命令日志沒有寫回到硬盤，發(fā)生了宕機，這一秒內(nèi)的數(shù)據(jù)會丟失。
• No，意味著不由 Redis 控制寫回硬盤的時機，轉(zhuǎn)交給操作系統(tǒng)控制寫回的時機，也就是每次寫操作命令執(zhí)行完后，先將命令寫入到 AOF 文件的內(nèi)核緩沖區(qū)，再由操作系統(tǒng)決定何時將緩沖區(qū)內(nèi)容寫回硬盤。相比于 Always 策略性能較好，但是操作系統(tǒng)寫回硬盤的時機是不可預(yù)知的，如果 AOF 日志內(nèi)容沒有寫回硬盤，一旦服務(wù)器宕機，就會丟失不定數(shù)量的數(shù)據(jù)。
  這 三種寫回策略都無法能完美解決「主進(jìn)程阻塞」和「減少數(shù)據(jù)丟失」的問題，只能根據(jù)自己的業(yè)務(wù)場景進(jìn)行選擇。

1.3 三種策略實現(xiàn)原理

看了源碼后，你就會發(fā)現(xiàn)這三種策略只是在控制 fsync() 函數(shù)的調(diào)用時機。
當(dāng)應(yīng)用程序向文件寫入數(shù)據(jù)時，內(nèi)核通常先將數(shù)據(jù)復(fù)制到內(nèi)核緩沖區(qū)中，然后排入隊列，然后由內(nèi)核決定何時寫入硬盤。

如果想要應(yīng)用程序向文件寫入數(shù)據(jù)后，能立馬將數(shù)據(jù)同步到硬盤，就可以調(diào)用 fsync() 函數(shù)，這樣內(nèi)核就會將內(nèi)核緩沖區(qū)的數(shù)據(jù)直接寫入到硬盤，等到硬盤寫操作完成后，該函數(shù)才會返回。

• Always 策略就是每次寫入 AOF 文件數(shù)據(jù)后，就執(zhí)行 fsync() 函數(shù)；
• Everysec 策略就會創(chuàng)建一個異步任務(wù)來執(zhí)行 fsync() 函數(shù)；
• No 策略就是永不執(zhí)行 fsync() 函數(shù);

1.4 重寫機制

例子：如果我們執(zhí)行了1W遍的set name #隨機值#。按照日志記錄，是不是有記錄1W條命令記錄到AOF文件中。如果寫1百萬次呢，就記錄1百萬條記錄，AOF會越來越大，效率會越來越低。當(dāng) AOF 日志文件過大就會帶來性能問題，比如重啟 Redis 后，需要讀 AOF 文件的內(nèi)容以恢復(fù)數(shù)據(jù)，如果文件過大，整個恢復(fù)的過程就會很慢。

所以Redis 為了避免 AOF 文件越寫越大，提供了 AOF 重寫機制，當(dāng) AOF 文件的大小超過所設(shè)定的閾值后，Redis 就會啟用 AOF 重寫機制，來壓縮 AOF 文件。

在使用重寫機制后，就會讀取 name 最新的 value（鍵值對） ，然后用一條 set name xxx 命令記錄到新的 AOF 文件，之前的第一個命令就沒有必要記錄了，因為它屬于「歷史」命令，沒有作用了。這樣一來，一個鍵值對在重寫日志中只用一條命令就行了。

重寫工作完成后，就會將新的 AOF 文件覆蓋現(xiàn)有的 AOF 文件，這就相當(dāng)于壓縮了 AOF 文件，使得 AOF 文件體積變小了。

然后，在通過 AOF 日志恢復(fù)數(shù)據(jù)時，只用執(zhí)行這條命令，就可以直接完成這個鍵值對的寫入了。
所以，重寫機制的妙處在于，盡管某個鍵值對被多條寫命令反復(fù)修改，最終也只需要根據(jù)這個「鍵值對」當(dāng)前的最新狀態(tài)，然后用一條命令去記錄鍵值對，代替之前記錄這個鍵值對的多條命令，這樣就減少了 AOF 文件中的命令數(shù)量。

總結(jié)：AOF 重寫機制是在重寫時，讀取當(dāng)前數(shù)據(jù)庫中的所有鍵值對，然后將每一個鍵值對用一條命令記錄到「新的 AOF 文件」，等到全部記錄完后，就將新的 AOF 文件替換掉現(xiàn)有的 AOF 文件。
為什么重寫 AOF 的時候，不直接復(fù)用現(xiàn)有的 AOF 文件，而是先寫到新的 AOF 文件再覆蓋過去。
因為如果 AOF 重寫過程中失敗了，現(xiàn)有的 AOF 文件就會造成污染，可能無法用于恢復(fù)使用。

1.5 后臺重寫

寫入 AOF 日志的操作雖然是在主進(jìn)程完成的，因為它寫入的內(nèi)容不多，所以一般不太影響命令的操作。但是在觸發(fā) AOF 重寫時，比如當(dāng) AOF 文件大于 64M 時，就會對 AOF 文件進(jìn)行重寫，這時是需要讀取所有緩存的鍵值對數(shù)據(jù)，并為每個鍵值對生成一條命令，然后將其寫入到新的 AOF 文件，重寫完后，就把現(xiàn)在的 AOF 文件替換掉。這個過程其實是很耗時的，所以重寫的操作不能放在主進(jìn)程里。因此Redis 的重寫 AOF 過程是由后臺子進(jìn)程 bgrewriteaof 來完成的，

好處：

• 子進(jìn)程進(jìn)行 AOF 重寫期間，主進(jìn)程可以繼續(xù)處理命令請求，從而避免阻塞主進(jìn)程；
• 子進(jìn)程帶有主進(jìn)程的數(shù)據(jù)副本（數(shù)據(jù)副本怎么產(chǎn)生的后面會說），這里使用子進(jìn)程而不是線程，因為如果是使用線程，多線程之間會共享內(nèi)存，那么在修改共享內(nèi)存數(shù)據(jù)的時候，需要通過加鎖來保證數(shù)據(jù)的安全，而這樣就會降低性能。而使用子進(jìn)程，創(chuàng)建子進(jìn)程時，父子進(jìn)程是共享內(nèi)存數(shù)據(jù)的，不過這個共享的內(nèi)存只能以只讀的方式，而當(dāng)父子進(jìn)程任意一方修改了該共享內(nèi)存，就會發(fā)生「寫時復(fù)制」，于是父子進(jìn)程就有了獨立的數(shù)據(jù)副本，就不用加鎖來保證數(shù)據(jù)安全。

子進(jìn)程是怎么擁有主進(jìn)程一樣的數(shù)據(jù)副本的呢？
主進(jìn)程在通過 fork 系統(tǒng)調(diào)用生成 bgrewriteaof 子進(jìn)程時，操作系統(tǒng)會把主進(jìn)程的「頁表」復(fù)制一份給子進(jìn)程，這個頁表記錄著虛擬地址和物理地址映射關(guān)系，而不會復(fù)制物理內(nèi)存，也就是說，兩者的虛擬空間不同，但其對應(yīng)的物理空間是同一個。

這樣一來，子進(jìn)程就共享了父進(jìn)程的物理內(nèi)存數(shù)據(jù)了，這樣能夠節(jié)約物理內(nèi)存資源，頁表對應(yīng)的頁表項的屬性會標(biāo)記該物理內(nèi)存的權(quán)限為只讀。
不過，當(dāng)父進(jìn)程或者子進(jìn)程在向這個內(nèi)存發(fā)起寫操作時，CPU 就會觸發(fā)寫保護(hù)中斷，這個寫保護(hù)中斷是由于違反權(quán)限導(dǎo)致的，然后操作系統(tǒng)會在「寫保護(hù)中斷處理函數(shù)」里進(jìn)行物理內(nèi)存的復(fù)制，并重新設(shè)置其內(nèi)存映射關(guān)系，將父子進(jìn)程的內(nèi)存讀寫權(quán)限設(shè)置為可讀寫，最后才會對內(nèi)存進(jìn)行寫操作，這個過程被稱為「寫時復(fù)制(Copy On Write)」在發(fā)生寫操作的時候，操作系統(tǒng)才會去復(fù)制物理內(nèi)存。

這樣是為了防止 fork 創(chuàng)建子進(jìn)程時，**由于物理內(nèi)存數(shù)據(jù)的復(fù)制時間過長而導(dǎo)致父進(jìn)程長時間阻塞的問題。如果父進(jìn)程的內(nèi)存數(shù)據(jù)非常大，那自然頁表也會很大，這時父進(jìn)程在通過 fork 創(chuàng)建子進(jìn)程的時候，阻塞的時間也越久。
所以，有兩個階段會導(dǎo)致阻塞父進(jìn)程：

• 創(chuàng)建子進(jìn)程的過程中，阻塞的時間跟頁表的大小有關(guān)，頁表越大，阻塞的時間也越長；
• 創(chuàng)建完子進(jìn)程后，如果子進(jìn)程或者父進(jìn)程修改了共享數(shù)據(jù)，就會發(fā)生寫時復(fù)制，這期間會拷貝物理內(nèi)存，如果內(nèi)存越大，自然阻塞的時間也越長；

還有個問題，重寫 AOF 日志過程中，如果主進(jìn)程修改了已經(jīng)存在 key-value，此時這個 key-value 數(shù)據(jù)在子進(jìn)程的內(nèi)存數(shù)據(jù)就跟主進(jìn)程的內(nèi)存數(shù)據(jù)不一致了，這時要怎么辦呢？
為了解決這種數(shù)據(jù)不一致問題，Redis 設(shè)置了一個 AOF 重寫緩沖區(qū)，這個緩沖區(qū)在創(chuàng)建 bgrewriteaof 子進(jìn)程之后開始使用。
在重寫 AOF 期間，當(dāng) Redis 執(zhí)行完一個寫命令之后，它會同時將這個寫命令寫入到 「AOF 緩沖區(qū)」和 「AOF 重寫緩沖區(qū)」。
也就是說，在 bgrewriteaof 子進(jìn)程執(zhí)行 AOF 重寫期間，主進(jìn)程需要執(zhí)行以下三個工作:

• 執(zhí)行客戶端發(fā)來的命令；
• 將執(zhí)行后的寫命令追加到 「AOF 緩沖區(qū)」；
• 將執(zhí)行后的寫命令追加到 「AOF 重寫緩沖區(qū)」；

當(dāng)子進(jìn)程完成 AOF 重寫工作（掃描數(shù)據(jù)庫中所有數(shù)據(jù)，逐一把內(nèi)存數(shù)據(jù)的鍵值對轉(zhuǎn)換成一條命令，再將命令記錄到重寫日志）后，會向主進(jìn)程發(fā)送一條信號，信號是進(jìn)程間通訊的一種方式，且是異步的。主進(jìn)程收到該信號后，會調(diào)用一個信號處理函數(shù)，該函數(shù)主要做以下工作：

• 將 AOF 重寫緩沖區(qū)中的所有內(nèi)容追加到新的 AOF 的文件中，使得新舊兩個 AOF 文件所保存的數(shù)據(jù)庫狀態(tài)一致；
• 新的 AOF 的文件進(jìn)行改名，覆蓋現(xiàn)有的 AOF 文件。
  信號函數(shù)執(zhí)行完后，主進(jìn)程就可以繼續(xù)像往常一樣處理命令了。
  在整個 AOF 后臺重寫過程中，除了發(fā)生寫時復(fù)制會對主進(jìn)程造成阻塞，還有信號處理函數(shù)執(zhí)行時也會對主進(jìn)程造成阻塞，在其他時候，AOF 后臺重寫都不會阻塞主進(jìn)程。

二、RDB快照

所謂的快照，就是記錄某一個瞬間東西，比如當(dāng)我們給風(fēng)景拍照時，那一個瞬間的畫面和信息就記錄到了一張照片。
所以，RDB 快照就是記錄某一個瞬間的內(nèi)存數(shù)據(jù)，記錄的是實際數(shù)據(jù)，而 AOF 文件記錄的是命令操作的日志，而不是實際的數(shù)據(jù)。
因此在 Redis 恢復(fù)數(shù)據(jù)時， RDB 恢復(fù)數(shù)據(jù)的效率會比 AOF 高些，因為直接將 RDB 文件讀入內(nèi)存就可以，不需要像 AOF 那樣還需要額外執(zhí)行操作命令的步驟才能恢復(fù)數(shù)據(jù)。

Redis 提供了兩個命令來生成 RDB 文件，分別是 save 和 bgsave，他們的區(qū)別就在于是否在「主線程」里執(zhí)行：
● 執(zhí)行了 save 命令，就會在主線程生成 RDB 文件，由于和執(zhí)行操作命令在同一個線程，所以如果寫入 RDB 文件的時間太長，會阻塞主線程；
● 執(zhí)行了 bgsave 命令，會創(chuàng)建一個子進(jìn)程來生成 RDB 文件，這樣可以避免主線程的阻塞；

RDB 文件的加載工作是在服務(wù)器啟動時自動執(zhí)行的，Redis 并沒有提供專門用于加載 RDB 文件的命令。
只要滿足上面條件的任意一個，就會執(zhí)行 bgsave，它們的意思分別是：
● 900 秒之內(nèi)，對數(shù)據(jù)庫進(jìn)行了至少 1 次修改；
● 300 秒之內(nèi)，對數(shù)據(jù)庫進(jìn)行了至少 10 次修改；
● 60 秒之內(nèi)，對數(shù)據(jù)庫進(jìn)行了至少 10000 次修改。

這里提一點，Redis 的快照是全量快照，也就是說每次執(zhí)行快照，都是把內(nèi)存中的「所有數(shù)據(jù)」都記錄到磁盤中。
所以可以認(rèn)為，執(zhí)行快照是一個比較重的操作，如果頻率太頻繁，可能會對 Redis 性能產(chǎn)生影響。如果頻率太低，服務(wù)器故障時，丟失的數(shù)據(jù)會更多。
通?？赡茉O(shè)置至少 5 分鐘才保存一次快照，這時如果 Redis 出現(xiàn)宕機等情況，則意味著最多可能丟失 5 分鐘數(shù)據(jù)。
這就是 RDB 快照的缺點，在服務(wù)器發(fā)生故障時，丟失的數(shù)據(jù)會比 AOF 持久化的方式更多，因為 RDB 快照是全量快照的方式，因此執(zhí)行的頻率不能太頻繁，否則會影響 Redis 性能，而 AOF 日志可以以秒級的方式記錄操作命令，所以丟失的數(shù)據(jù)就相對更少。

執(zhí)行快照時，數(shù)據(jù)能被修改了怎么辦

執(zhí)行 bgsave 過程中，由于是交給子進(jìn)程來構(gòu)建 RDB 文件，主線程還是可以繼續(xù)工作的，此時主線程可以修改數(shù)據(jù)嗎？
如果不可以修改數(shù)據(jù)的話，那這樣性能一下就降低了很多。如果可以修改數(shù)據(jù)，又是如何做到到呢？
那具體如何做到到呢？關(guān)鍵的技術(shù)就在于寫時復(fù)制技術(shù)（Copy-On-Write, COW）。
執(zhí)行 bgsave 命令的時候，會通過 fork() 創(chuàng)建子進(jìn)程，此時子進(jìn)程和父進(jìn)程是共享同一片內(nèi)存數(shù)據(jù)的，因為創(chuàng)建子進(jìn)程的時候，會復(fù)制父進(jìn)程的頁表，但是頁表指向的物理內(nèi)存還是一個。只有在發(fā)生修改內(nèi)存數(shù)據(jù)的情況時，物理內(nèi)存才會被復(fù)制一份。

這樣的目的是為了減少創(chuàng)建子進(jìn)程時的性能損耗，從而加快創(chuàng)建子進(jìn)程的速度，畢竟創(chuàng)建子進(jìn)程的過程中，是會阻塞主線程的。
所以，創(chuàng)建 bgsave 子進(jìn)程后，由于共享父進(jìn)程的所有內(nèi)存數(shù)據(jù)，于是就可以直接讀取主線程（父進(jìn)程）里的內(nèi)存數(shù)據(jù)，并將數(shù)據(jù)寫入到 RDB 文件。

當(dāng)主線程（父進(jìn)程）對這些共享的內(nèi)存數(shù)據(jù)也都是只讀操作，那么，主線程（父進(jìn)程）和 bgsave 子進(jìn)程相互不影響。
但是，如果主線程（父進(jìn)程）要修改共享數(shù)據(jù)里的某一塊數(shù)據(jù)（比如鍵值對 A）時，就會發(fā)生寫時復(fù)制，于是這塊數(shù)據(jù)的物理內(nèi)存就會被復(fù)制一份（鍵值對 A’），然后主線程在這個數(shù)據(jù)副本（鍵值對 A’）進(jìn)行修改操作。與此同時，bgsave 子進(jìn)程可以繼續(xù)把原來的數(shù)據(jù)（鍵值對 A）寫入到 RDB 文件。
就是這樣，Redis 使用 bgsave 對當(dāng)前內(nèi)存中的所有數(shù)據(jù)做快照，這個操作是由 bgsave 子進(jìn)程在后臺完成的，執(zhí)行時不會阻塞主線程，這就使得主線程同時可以修改數(shù)據(jù)。

所以bgsave 快照過程中，如果主線程修改了共享數(shù)據(jù)，發(fā)生了寫時復(fù)制后，RDB 快照保存的是原本的內(nèi)存數(shù)據(jù)，而主線程剛修改的數(shù)據(jù)，是沒辦法在這一時間寫入 RDB 文件的，只能交由下一次的 bgsave 快照。因此如果主線程修改了內(nèi)存數(shù)據(jù)，不管是否是共享的內(nèi)存數(shù)據(jù)，RDB 快照都無法寫入主線程剛修改的數(shù)據(jù)，因為此時主線程（父進(jìn)程）的內(nèi)存數(shù)據(jù)和子進(jìn)程的內(nèi)存數(shù)據(jù)已經(jīng)分離了，子進(jìn)程寫入到 RDB 文件的內(nèi)存數(shù)據(jù)只能是原本的內(nèi)存數(shù)據(jù)。如果系統(tǒng)恰好在 RDB 快照文件創(chuàng)建完畢后崩潰了，那么 Redis 將會丟失主線程在快照期間修改的數(shù)據(jù)。
另外，寫時復(fù)制的時候會出現(xiàn)這么個極端的情況。
在 Redis 執(zhí)行 RDB 持久化期間，剛 fork 時，主進(jìn)程和子進(jìn)程共享同一物理內(nèi)存，但是途中主進(jìn)程處理了寫操作，修改了共享內(nèi)存，于是當(dāng)前被修改的數(shù)據(jù)的物理內(nèi)存就會被復(fù)制一份。
那么極端情況下，如果所有的共享內(nèi)存都被修改，則此時的內(nèi)存占用是原先的 2 倍。
所以，針對寫操作多的場景，我們要留意下快照過程中內(nèi)存的變化，防止內(nèi)存被占滿了。

三、RDB 和 AOF 合體

盡管 RDB 比 AOF 的數(shù)據(jù)恢復(fù)速度快，但是快照的頻率不好把握：
● 如果頻率太低，兩次快照間一旦服務(wù)器發(fā)生宕機，就可能會比較多的數(shù)據(jù)丟失；
● 如果頻率太高，頻繁寫入磁盤和創(chuàng)建子進(jìn)程會帶來額外的性能開銷。
那有沒有什么方法不僅有 RDB 恢復(fù)速度快的優(yōu)點和又有 AOF 丟失數(shù)據(jù)少的優(yōu)點呢？

當(dāng)然有，那就是將 RDB 和 AOF 合體使用，這個方法是在 Redis 4.0 提出的，該方法叫混合使用 AOF 日志和內(nèi)存快照，也叫混合持久化。
如果想要開啟混合持久化功能，可以在 Redis 配置文件將下面這個配置項設(shè)置成 yes：
aof-use-rdb-preamble yes

混合持久化工作在 AOF 日志重寫過程。
當(dāng)開啟了混合持久化時，在 AOF 重寫日志時，fork 出來的重寫子進(jìn)程會先將與主線程共享的內(nèi)存數(shù)據(jù)以 RDB 方式寫入到 AOF 文件，然后主線程處理的操作命令會被記錄在重寫緩沖區(qū)里，重寫緩沖區(qū)里的增量命令會以 AOF 方式寫入到 AOF 文件，寫入完成后通知主進(jìn)程將新的含有 RDB 格式和 AOF 格式的 AOF 文件替換舊的的 AOF 文件。
也就是說，使用了混合持久化，AOF 文件的前半部分是 RDB 格式的全量數(shù)據(jù)，后半部分是 AOF 格式的增量數(shù)據(jù)。

這樣的好處在于，重啟 Redis 加載數(shù)據(jù)的時候，由于前半部分是 RDB 內(nèi)容，這樣加載的時候速度會很快。
加載完 RDB 的內(nèi)容后，才會加載后半部分的 AOF 內(nèi)容，這里的內(nèi)容是 Redis 后臺子進(jìn)程重寫 AOF 期間，主線程處理的操作命令，可以使得數(shù)據(jù)更少的丟失。