由于redis是基于內(nèi)存的數(shù)據(jù)庫，一旦宕機(jī)，數(shù)據(jù)就會丟失?如何解決？

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

AOF日志
是寫后日志，"寫后"的意思是 Redis 是先執(zhí)行命令，把數(shù)據(jù)寫入內(nèi)存，然后才記錄日志。

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

寫后日志的優(yōu)勢與風(fēng)險(xiǎn)
為了避免額外的檢查開銷，Redis 在向 AOF 里面記錄日志的時(shí)候，并不會先去對這些命令進(jìn)行語法檢查。如果先記日志再執(zhí)行命令的話，日志中就有可能記錄了錯(cuò)誤的命令，Redis 在使用日志恢復(fù)數(shù)據(jù)時(shí)，就可能會出錯(cuò)。而寫后日志這種方式，就是先讓系統(tǒng)執(zhí)行命令，只有命令能執(zhí)行成功，才會被記錄到日志中，否則，系統(tǒng)就會直接向客戶端報(bào)錯(cuò)。
除此之外，寫后日志一個(gè)好處：它是在命令執(zhí)行后才記錄日志，不會阻塞當(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 雖然避免了對當(dāng)前命令的阻塞，但可能會給下一個(gè)操作帶來阻塞風(fēng)險(xiǎn)。
AOF 日志也是在主線程中執(zhí)行(寫回策略為 always 時(shí))，如果在把日志文件寫入磁盤時(shí)，磁盤寫壓力大，就會導(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)就解除了。

寫回策略
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)容寫回磁盤。

AOF重寫
AOF 是以文件的形式在記錄接收到的所有寫命令。隨著接收的寫命令越來越多，AOF 文件會越來越大。這也就意味著，我們一定要小心 AOF 文件過大帶來的性能問題，主要在于以下三個(gè)方面：
一是，文件系統(tǒng)本身對文件大小有限制，無法保存過大的文件；
二是，如果文件太大，之后再往里面追加命令記錄的話，效率也會變低；
三是，如果發(fā)生宕機(jī)，AOF 中記錄的命令要一個(gè)個(gè)被重新執(zhí)行，用于故障恢復(fù)，如果日志文件太大，整個(gè)恢復(fù)過程就會非常緩慢，這就會影響到 Redis 的正常使用。
AOF 重寫機(jī)制就是在重寫時(shí)，Redis 根據(jù)數(shù)據(jù)庫的現(xiàn)狀創(chuàng)建一個(gè)新的 AOF 文件，也就是說，讀取數(shù)據(jù)庫中的所有鍵值對，然后對每一個(gè)鍵值對用一條命令記錄它的寫入。重寫機(jī)制具有“多變一”功能。所謂的“多變一”，也就是說，舊日志文件中的多條命令，在重寫后的新日志中變成了一條命令。

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

我把重寫的過程總結(jié)為“一個(gè)拷貝，兩處日志”。
“一個(gè)拷貝”就是指，每次執(zhí)行重寫時(shí)，主線程 fork 出后臺的 bgrewriteaof 子進(jìn)程。此時(shí)，fork 會把主線程的內(nèi)存拷貝一份給 bgrewriteaof 子進(jìn)程，這里面就包含了數(shù)據(jù)庫的最新數(shù)據(jù)。然后，bgrewriteaof 子進(jìn)程就可以在不影響主線程的情況下，逐一把拷貝的數(shù)據(jù)寫成操作，記入重寫日志。
第一處日志，指的是因?yàn)橹骶€程未阻塞，仍然可以處理新來的操作，Redis 會把這個(gè)操作寫到它的緩沖區(qū)。這樣一來，即使宕機(jī)了，這個(gè) AOF 日志的操作仍然是齊全的，可以用于恢復(fù)。
第二處日志，就是指新的 AOF 重寫日志。這個(gè)操作也會被寫到重寫日志的緩沖區(qū)。這樣，重寫日志也不會丟失最新的操作。等到拷貝數(shù)據(jù)的所有操作記錄重寫完成后，重寫日志記錄的這些最新操作也會寫入新的 AOF 文件，以保證數(shù)據(jù)庫最新狀態(tài)的記錄。

總結(jié)來說，每次 AOF 重寫時(shí)，Redis 會先執(zhí)行一個(gè)內(nèi)存拷貝，用于重寫；然后，使用兩個(gè)日志保證在重寫過程中，新寫入的數(shù)據(jù)不會丟失。而且，因?yàn)?Redis 采用子進(jìn)程進(jìn)行日志重寫，所以，這個(gè)過程并不會阻塞主線程。
正因?yàn)橛涗浀氖遣僮髅?#xff0c;而不是實(shí)際的數(shù)據(jù)，所以，用 AOF 方法進(jìn)行故障恢復(fù)的時(shí)候，需要逐一把操作日志都執(zhí)行一遍。如果操作日志非常多，Redis 就會恢復(fù)得很緩慢，影響到正常使用。這當(dāng)然不是理想的結(jié)果。那么，還有沒有既可以保證可靠性，還能在宕機(jī)時(shí)實(shí)現(xiàn)快速恢復(fù)的其他方法呢？

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

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

save：在主線程中執(zhí)行，會導(dǎo)致阻塞；
bgsave：創(chuàng)建一個(gè)子進(jìn)程，專門用于寫入 RDB 文件，避免了主線程的阻塞，這也是 Redis RDB 文件生成的默認(rèn)配置。

我們可以通過 bgsave 命令來執(zhí)行全量快照，這既提供了數(shù)據(jù)的可靠性保證，也避免了對 Redis 的性能影響。
在執(zhí)行快照的同時(shí)，Redis 就會借助操作系統(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 文件。
如果主線程對這些數(shù)據(jù)也都是讀操作（例如圖中的鍵值對 A），那么，主線程和 bgsave 子進(jìn)程相互不影響。但是，如果主線程要修改一塊數(shù)據(jù)（例如圖中的鍵值對 C），那么，這塊數(shù)據(jù)就會被復(fù)制一份，生成該數(shù)據(jù)的副本（鍵值對 C’）。然后，主線程在這個(gè)數(shù)據(jù)副本上進(jìn)行修改。同時(shí)，bgsave 子進(jìn)程可以繼續(xù)把原來的數(shù)據(jù)（鍵值對 C）寫入 RDB 文件。

雖然 bgsave 執(zhí)行時(shí)不阻塞主線程，但是，如果頻繁地執(zhí)行全量快照，也會帶來兩方面的開銷。
一方面，頻繁將全量數(shù)據(jù)寫入磁盤，會給磁盤帶來很大壓力，多個(gè)快照競爭有限的磁盤帶寬，前一個(gè)快照還沒有做完，后一個(gè)又開始做了，容易造成惡性循環(huán)（所以，在 Redis 中如果有一個(gè) bgsave 在運(yùn)行，就不會再啟動第二個(gè) bgsave 子進(jìn)程）。
另一方面，bgsave 子進(jìn)程需要通過 fork 操作從主線程創(chuàng)建出來。雖然，子進(jìn)程在創(chuàng)建后不會再阻塞主線程，但是，fork 這個(gè)創(chuàng)建過程本身會阻塞主線程，而且主線程的內(nèi)存越大，阻塞時(shí)間越長。
Redis 4.0 中提出了一個(gè)混合使用 AOF 日志和內(nèi)存快照的方法。簡單來說，內(nèi)存快照以一定的頻率執(zhí)行，在兩次快照之間，使用 AOF 日志記錄這期間的所有命令操作。這樣一來，快照不用很頻繁地執(zhí)行，這就避免了頻繁 fork 對主線程的影響。而且，AOF 日志也只用記錄兩次快照間的操作，也就是說，不需要記錄所有操作了，因此，就不會出現(xiàn)文件過大的情況了，也可以避免重寫開銷。

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

數(shù)據(jù)不能丟失時(shí)，內(nèi)存快照和 AOF 的混合使用是一個(gè)很好的選擇；
如果允許分鐘級別的數(shù)據(jù)丟失，可以只使用 RDB；
如果只用 AOF，優(yōu)先使用 everysec 的配置選項(xiàng)，因?yàn)樗诳煽啃院托阅苤g取了一個(gè)平衡