前言

如果有人問你："你會把 Redis 用在什么業(yè)務場景下？"

我想你大概率會說："我會把它當作緩存使用，因為它把后端數(shù)據(jù)庫中的數(shù)據(jù)存儲在內(nèi)存中，然后直接從內(nèi)存中讀取數(shù)據(jù)，響應速度會非常快。"

沒錯，這確實是 Redis 的一個普遍使用場景，但是，這里也有一個絕對不能忽略的問題：「一旦服務器宕機，內(nèi)存中的數(shù)據(jù)將全部丟失」 。

目前，Redis 的持久化主要有兩大機制，即 「AOF（Append Only File）日志和 RDB（Redis DataBase） 快照」 。

AOF

日志是如何實現(xiàn)的

說到日志，我們比較熟悉的是數(shù)據(jù)庫的寫前日志（Write Ahead Log, WAL），在實際寫數(shù)據(jù)前，先把修改的數(shù)據(jù)記到日志文件中，以便故障時進行恢復。不過，AOF 日志正好相反，它是寫后日志，"寫后"的意思是 Redis 是先執(zhí)行命令，把數(shù)據(jù)寫入內(nèi)存，然后才記錄日志。

AOF日志是如何實現(xiàn)的

AOF 里記錄的是 Redis 收到的每一條命令，這些命令是以文本形式保存的。

我們以 Redis 收到“set testkey testvalue”命令后記錄的日志為例，看看 AOF 日志的內(nèi)容。其中，“*3”表示當前命令有三個部分，每部分都是由“數(shù)字開頭，后面緊跟著具體的命令、鍵或值。這里，數(shù)字表示這部分中的命令、鍵或值一共有多少字節(jié)。例如，3 set”表示這部分有 3 個字節(jié)，也就是“set”命令。

AOF日志是如何實現(xiàn)的

寫后日志的優(yōu)勢與風險

「為了避免額外的檢查開銷，Redis 在向 AOF 里面記錄日志的時候，并不會先去對這些命令進行語法檢查」 。

如果先記日志再執(zhí)行命令的話，日志中就有可能記錄了錯誤的命令，Redis 在使用日志恢復數(shù)據(jù)時，就可能會出錯。而寫后日志這種方式，就是先讓系統(tǒng)執(zhí)行命令，只有命令能執(zhí)行成功，才會被記錄到日志中，否則，系統(tǒng)就會直接向客戶端報錯。

所以，Redis 使用寫后日志這一方式的一大好處是，可以避免出現(xiàn)記錄錯誤命令的情況。

除此之外，寫后日志一個好處：它是在命令執(zhí)行后才記錄日志，「不會阻塞當前的寫操作」 。

AOF 也有兩個潛在的風險：

風險一：如果剛執(zhí)行完一個命令，還沒有來得及記日志就宕機了，那么這個命令和相應的數(shù)據(jù)就有丟失的風險。

如果此時 Redis 是用作緩存，還可以從后端數(shù)據(jù)庫重新讀入數(shù)據(jù)進行恢復。

如果 Redis 是直接用作數(shù)據(jù)庫的話，此時，因為命令沒有記入日志，所以就無法用日志進行恢復了。

風險二：AOF 雖然避免了對當前命令的阻塞，但可能會給下一個操作帶來阻塞風險。

AOF 日志也是在主線程中執(zhí)行(寫回策略為 always 時)，如果在把日志文件寫入磁盤時，磁盤寫壓力大，就會導致寫盤很慢，進而導致后續(xù)的操作也無法執(zhí)行了。

這兩個風險都是和 AOF 寫回磁盤的時機相關(guān)的。這也就意味著，如果我們能夠控制一個寫命令執(zhí)行完后 AOF 日志寫回磁盤的時機，這兩個風險就解除了。

日志的寫回策略

AOF 機制一共有三種寫回策略，也就是 AOF 配置項 appendfsync 的三個可選值。

「Always 同步寫回」 ：每個寫命令執(zhí)行完，立馬同步地將日志寫回磁盤；

「Everysec 每秒寫回」 ：每個寫命令執(zhí)行完，只是先把日志寫到 AOF 文件的內(nèi)存緩沖區(qū)，每隔一秒把緩沖區(qū)中的內(nèi)容寫入磁盤；

「No 操作系統(tǒng)控制的寫回」 ：每個寫命令執(zhí)行完，只是先把日志寫到 AOF 文件的內(nèi)存緩沖區(qū)，由操作系統(tǒng)決定何時將緩沖區(qū)內(nèi)容寫回磁盤。

針對避免主線程阻塞和減少數(shù)據(jù)丟失問題，這三種寫回策略都無法做到兩全其美。

日志的寫回策略

我們就可以根據(jù)系統(tǒng)對高性能和高可靠性的要求，來選擇使用哪種寫回策略了。

想要獲得高性能，就選擇 No 策略；

想要得到高可靠性保證，就選擇 Always 策略；

允許數(shù)據(jù)有一點丟失，又希望性能別受太大影響的話，那么就選擇 Everysec 策略。

日志的重寫

重寫的作用

AOF 是以文件的形式在記錄接收到的所有寫命令。「隨著接收的寫命令越來越多，AOF 文件會越來越大」 。這也就意味著，我們一定要小心 AOF 文件過大帶來的性能問題，主要在于以下三個方面：

一是，文件系統(tǒng)本身對文件大小有限制，無法保存過大的文件；

二是，如果文件太大，之后再往里面追加命令記錄的話，效率也會變低；

三是，如果發(fā)生宕機，AOF 中記錄的命令要一個個被重新執(zhí)行，用于故障恢復，如果日志文件太大，整個恢復過程就會非常緩慢，這就會影響到 Redis 的正常使用。

AOF 重寫機制就是在重寫時，Redis 根據(jù)數(shù)據(jù)庫的現(xiàn)狀創(chuàng)建一個新的 AOF 文件，也就是說，「讀取數(shù)據(jù)庫中的所有鍵值對，然后對每一個鍵值對用一條命令記錄它的寫入」 。重寫機制具有“多變一”功能。所謂的“多變一”，也就是說，舊日志文件中的多條命令，在重寫后的新日志中變成了一條命令。

重寫的作用

重寫的過程

AOF 日志由主線程寫回不同，重寫過程是由「后臺子進程 bgrewriteaof 來完成的，這也是為了避免阻塞主線程」 ，導致數(shù)據(jù)庫性能下降。

我把重寫的過程總結(jié)為“「一個拷貝，兩處日志」 ”。

“一個拷貝”就是指，每次執(zhí)行重寫時，主線程 fork 出后臺的 bgrewriteaof 子進程。此時，fork 會把主線程的內(nèi)存拷貝一份給 bgrewriteaof 子進程，這里面就包含了數(shù)據(jù)庫的最新數(shù)據(jù)。然后，bgrewriteaof 子進程就可以在不影響主線程的情況下，逐一把拷貝的數(shù)據(jù)寫成操作，記入重寫日志。

第一處日志，指的是因為主線程未阻塞，仍然可以處理新來的操作，Redis 會把這個操作寫到它的緩沖區(qū)。這樣一來，即使宕機了，這個 AOF 日志的操作仍然是齊全的，可以用于恢復。

第二處日志，就是指新的 AOF 重寫日志。這個操作也會被寫到重寫日志的緩沖區(qū)。這樣，重寫日志也不會丟失最新的操作。等到拷貝數(shù)據(jù)的所有操作記錄重寫完成后，重寫日志記錄的這些最新操作也會寫入新的 AOF 文件，以保證數(shù)據(jù)庫最新狀態(tài)的記錄。

此時，我們就可以用新的 AOF 文件替代舊文件了。

重寫的過程

總結(jié)來說，每次 AOF 重寫時，Redis 會先執(zhí)行一個內(nèi)存拷貝，用于重寫；然后，使用兩個日志保證在重寫過程中，新寫入的數(shù)據(jù)不會丟失。而且，「因為 Redis 采用子進程進行日志重寫，所以，這個過程并不會阻塞主線程」 。

正因為記錄的是操作命令，而不是實際的數(shù)據(jù)，所以，用 AOF 方法進行故障恢復的時候，需要逐一把操作日志都執(zhí)行一遍。如果操作日志非常多，Redis 就會恢復得很緩慢，影響到正常使用。這當然不是理想的結(jié)果。那么，還有沒有既可以保證可靠性，還能在宕機時實現(xiàn)快速恢復的其他方法呢？

RDB

對 Redis 來說，它實現(xiàn)類似照片記錄效果的方式，把某一時刻的狀態(tài)以文件的形式寫到磁盤上，也就是快照（RDB 文件）。這樣一來，即使宕機，快照文件也不會丟失，數(shù)據(jù)的可靠性也就得到了保證。

和 AOF 相比，RDB 記錄的是某一時刻的數(shù)據(jù)，并不是操作，所以，在做數(shù)據(jù)恢復時，我們可以直接把 RDB 文件讀入內(nèi)存，很快地完成恢復。

快照的原理

Redis 提供了兩個命令來生成 RDB 文件，分別是 save 和 bgsave。

「save」 ：在主線程中執(zhí)行，會導致阻塞；

「bgsave」 ：創(chuàng)建一個子進程，專門用于寫入 RDB 文件，避免了主線程的阻塞，這也是 Redis RDB 文件生成的默認配置。

我們可以通過 bgsave 命令來執(zhí)行全量快照，這既提供了數(shù)據(jù)的可靠性保證，也避免了對 Redis 的性能影響。

在執(zhí)行快照的同時，Redis 就會借助操作系統(tǒng)提供的寫時復制技術(shù)（Copy-On-Write, COW），正常處理寫操作。bgsave 子進程是由主線程 fork 生成的，可以共享主線程的所有內(nèi)存數(shù)據(jù)。bgsave 子進程運行后，開始讀取主線程的內(nèi)存數(shù)據(jù)，并把它們寫入 RDB 文件。

如果主線程對這些數(shù)據(jù)也都是讀操作（例如圖中的鍵值對 A），那么，主線程和 bgsave 子進程相互不影響。但是，如果主線程要修改一塊數(shù)據(jù)（例如圖中的鍵值對 C），那么，這塊數(shù)據(jù)就會被復制一份，生成該數(shù)據(jù)的副本（鍵值對 C’）。然后，主線程在這個數(shù)據(jù)副本上進行修改。同時，bgsave 子進程可以繼續(xù)把原來的數(shù)據(jù)（鍵值對 C）寫入 RDB 文件。

快照的原理

這樣既保證了快照的完整性，也允許主線程同時對數(shù)據(jù)進行修改，避免了對正常業(yè)務的影響。

混合 AOF/RDB

雖然 bgsave 執(zhí)行時不阻塞主線程，但是，如果頻繁地執(zhí)行全量快照，也會帶來兩方面的開銷。

一方面，頻繁將全量數(shù)據(jù)寫入磁盤，會給磁盤帶來很大壓力，多個快照競爭有限的磁盤帶寬，前一個快照還沒有做完，后一個又開始做了，容易造成惡性循環(huán)（所以，在 Redis 中如果有一個 bgsave 在運行，就不會再啟動第二個 bgsave 子進程）。

另一方面，bgsave 子進程需要通過 fork 操作從主線程創(chuàng)建出來。雖然，子進程在創(chuàng)建后不會再阻塞主線程，但是，「fork 這個創(chuàng)建過程本身會阻塞主線程」 ，而且主線程的內(nèi)存越大，阻塞時間越長。

Redis 4.0 中提出了一個混合使用 AOF 日志和內(nèi)存快照的方法。簡單來說，「內(nèi)存快照以一定的頻率執(zhí)行，在兩次快照之間，使用 AOF 日志記錄這期間的所有命令操作」 。這樣一來，快照不用很頻繁地執(zhí)行，這就避免了頻繁 fork 對主線程的影響。而且，AOF 日志也只用記錄兩次快照間的操作，也就是說，不需要記錄所有操作了，因此，就不會出現(xiàn)文件過大的情況了，也可以避免重寫開銷。

混合 AOF/RDB

總結(jié)

最后，關(guān)于 AOF 和 RDB 的選擇問題，我想再給你提三點建議：

數(shù)據(jù)不能丟失時，內(nèi)存快照和 AOF 的混合使用是一個很好的選擇；

如果允許分鐘級別的數(shù)據(jù)丟失，可以只使用 RDB；

如果只用 AOF，優(yōu)先使用 everysec 的配置選項，因為它在可靠性和性能之間取了一個平衡。

審核編輯：劉清