Redis在服務(wù)器宕機(jī)時(shí)如何避免數(shù)據(jù)丟失呢？

前言

如果有人問你："你會(huì)把 Redis 用在什么業(yè)務(wù)場(chǎng)景下？"

我想你大概率會(huì)說："我會(huì)把它當(dāng)作緩存使用，因?yàn)樗押蠖藬?shù)據(jù)庫中的數(shù)據(jù)存儲(chǔ)在內(nèi)存中，然后直接從內(nèi)存中讀取數(shù)據(jù)，響應(yīng)速度會(huì)非?？?。"

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

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

AOF

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

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

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

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

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

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

寫后日志的優(yōu)勢(shì)與風(fēng)險(xiǎn)

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

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

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

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

AOF 也有兩個(gè)潛在的風(fēng)險(xiǎn)：

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

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

如果 Redis 是直接用作數(shù)據(jù)庫的話，此時(shí)，因?yàn)槊顩]有記入日志，所以就無法用日志進(jìn)行恢復(fù)了。

風(fēng)險(xiǎn)二：AOF 雖然避免了對(duì)當(dāng)前命令的阻塞，但可能會(huì)給下一個(gè)操作帶來阻塞風(fēng)險(xiǎn)。

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

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

日志的寫回策略

AOF 機(jī)制一共有三種寫回策略，也就是 AOF 配置項(xiàng) appendfsync 的三個(gè)可選值。

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

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

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

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

日志的寫回策略

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

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

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

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

日志的重寫

重寫的作用

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

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

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

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

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

重寫的作用

重寫的過程

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

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

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

第一處日志，指的是因?yàn)橹骶€程未阻塞，仍然可以處理新來的操作，Redis 會(huì)把這個(gè)操作寫到它的緩沖區(qū)。這樣一來，即使宕機(jī)了，這個(gè) AOF 日志的操作仍然是齊全的，可以用于恢復(fù)。

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

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

重寫的過程

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

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

RDB

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

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

快照的原理

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

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

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

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

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

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

快照的原理

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

混合 AOF/RDB

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

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

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

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

混合 AOF/RDB

總結(jié)

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

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

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

如果只用 AOF，優(yōu)先使用 everysec 的配置選項(xiàng)，因?yàn)樗诳煽啃院托阅苤g取了一個(gè)平衡。

審核編輯：劉清