在現(xiàn)今的數(shù)據(jù)驅(qū)動(dòng)世界中，數(shù)據(jù)持久化成為了一項(xiàng)至關(guān)重要的任務(wù)。它不僅需要保證數(shù)據(jù)的安全，還要提供快速讀寫的功能。

對于許多現(xiàn)代化應(yīng)用程序和服務(wù)來說，Redis被廣泛使用作為一個(gè)高性能的鍵值存儲系統(tǒng)。Redis以其卓越的性能和靈活性贏得了開發(fā)者們的青睞。然而，這些優(yōu)點(diǎn)都離不開它強(qiáng)大的持久化機(jī)制。

通過本文，我們將深入探討Redis的持久化策略，包括RDB（Redis DataBase）快照和AOF（Append Only File）日志，并解析如何根據(jù)自己的業(yè)務(wù)需求選擇合適的持久化方案。

一、Redis持久化介紹

你也許會問，為什么需要持久化呢？因?yàn)镽edis作為一款內(nèi)存數(shù)據(jù)庫，在進(jìn)程異常退出或服務(wù)器斷電之后，所有的數(shù)據(jù)都將消失。如果沒有持久化功能，無法保證數(shù)據(jù)的持久性，那么這樣的數(shù)據(jù)庫還有什么用呢？

Redis持久化分為兩種：「RDB（Redis DataBase）」和「AOF（Append Only File）」。

RDB是指將Redis內(nèi)存中的數(shù)據(jù)定期寫入磁盤上的一個(gè)快照文件中，而AOF則是以追加的方式記錄Redis執(zhí)行的每一條寫命令。

你也可以同時(shí)開啟兩種持久化方式，在這種情況下，當(dāng)Redis重啟的時(shí)候會優(yōu)先載入AOF文件來恢復(fù)原始的數(shù)據(jù)。

接下來，我們將分別介紹RDB和AOF的實(shí)現(xiàn)原理。

二、RDB原理

RDB是Redis默認(rèn)的持久化方式，它將Redis在內(nèi)存中的數(shù)據(jù)定期寫入到硬盤中，生成一個(gè)快照文件。快照文件是一個(gè)二進(jìn)制文件，包含了Redis在某個(gè)時(shí)間點(diǎn)的所有數(shù)據(jù)。

RDB的優(yōu)點(diǎn)是快速、簡單，適用于大規(guī)模數(shù)據(jù)備份和恢復(fù)。但是，RDB也有缺點(diǎn)，例如數(shù)據(jù)可能會丟失，因?yàn)镽edis只會在指定的時(shí)間點(diǎn)生成快照文件。如果在快照文件生成之后，但在下一次快照文件生成之前服務(wù)器宕機(jī)，那么這期間的數(shù)據(jù)就會丟失。

由于RDB文件是以二進(jìn)制格式保存的，因此它非常緊湊，并且在Redis重啟時(shí)可以迅速地加載數(shù)據(jù)。相比于AOF，RDB文件一般會更小。

RDB持久化有兩種方式：手動(dòng)和自動(dòng)。

手動(dòng)方式通過SAVE命令或BGSAVE命令進(jìn)行：

• SAVE命令會阻塞Redis服務(wù)器，直到快照文件生成完成。
• BGSAVE命令會Fork一個(gè)子進(jìn)程（注意是子進(jìn)程，不是子線程）在后臺生成快照文件，不會阻塞Redis服務(wù)器。

自動(dòng)方式則是在配置文件中設(shè)置， 讓它在“ N 秒內(nèi)數(shù)據(jù)集至少有 M 個(gè)改動(dòng)”這一條件被滿足時(shí)， 自動(dòng)保存一次數(shù)據(jù)集。

比如說，以下設(shè)置會讓 Redis 在滿足 “10秒內(nèi)有至少100 個(gè)鍵被改動(dòng)” 這一條件時(shí)， 自動(dòng)保存一次數(shù)據(jù)集。

save 10 100

1.Fork函數(shù)與寫時(shí)復(fù)制

在 Redis 中，F(xiàn)ork 函數(shù)被用于創(chuàng)建子進(jìn)程。Redis 的使用場景中通常有大量的讀操作和較少的寫操作，而 Fork 函數(shù)可以利用 Linux 操作系統(tǒng)的寫時(shí)復(fù)制（Copy On Write，即 COW）機(jī)制，讓父子進(jìn)程共享內(nèi)存，從而減少內(nèi)存占用，并且避免了沒有必要的數(shù)據(jù)復(fù)制。

我們可以使用 Linux下的 man fork  命令來查看下Fork函數(shù)的說明文檔。

翻譯如下：

在Linux下，fork()是使用寫時(shí)復(fù)制的頁實(shí)現(xiàn)的，所以它唯一的代價(jià)是復(fù)制父進(jìn)程的頁表以及為子進(jìn)程創(chuàng)建獨(dú)特的任務(wù)結(jié)構(gòu)所需的時(shí)間和內(nèi)存。

簡單來說就是 fork()函數(shù)會復(fù)制父進(jìn)程的地址空間到子進(jìn)程中，復(fù)制的是指針，而不是數(shù)據(jù)，所以速度很快。

在 Redis 中，當(dāng)執(zhí)行 RDB 持久化操作時(shí)，Redis 會調(diào)用 fork 函數(shù)創(chuàng)建子進(jìn)程，然后由子進(jìn)程負(fù)責(zé)將數(shù)據(jù)寫入到磁盤中。為了避免父子進(jìn)程同時(shí)對內(nèi)存中的數(shù)據(jù)進(jìn)行修改導(dǎo)致數(shù)據(jù)不一致。Redis 會啟用寫時(shí)復(fù)制機(jī)制。

這樣，當(dāng)父進(jìn)程修改內(nèi)存中的數(shù)據(jù)時(shí)， Linux 內(nèi)核會將該部分內(nèi)存復(fù)制一份給子進(jìn)程使用，從而保證父子進(jìn)程間的數(shù)據(jù)互相獨(dú)立。

示意圖如下：

當(dāng)沒有發(fā)生寫的時(shí)候，子進(jìn)程和父進(jìn)程指向地址是一樣的，發(fā)生寫的時(shí)候，就會拷貝出一塊新的內(nèi)存區(qū)域，實(shí)現(xiàn)父子進(jìn)程隔離。

通過使用 fork 函數(shù)和寫時(shí)復(fù)制機(jī)制，Redis 可以高效地執(zhí)行 RDB 持久化操作，并且不會對 Redis 運(yùn)行過程中的性能造成太大的影響。同時(shí)，這種方式也提供了一種簡單有效的機(jī)制來保護(hù) Redis 數(shù)據(jù)的一致性和可靠性。

不過，需要注意的是：

fork的這個(gè)過程主進(jìn)程是阻塞的，fork完之后不阻塞。RDB 需要經(jīng)常fork子進(jìn)程來保存數(shù)據(jù)集到硬盤上，當(dāng)數(shù)據(jù)集比較大的時(shí)候，fork的過程是非常耗時(shí)的，可能會導(dǎo)致Redis在一些毫秒級內(nèi)不能響應(yīng)客戶端的請求，數(shù)據(jù)集很大的時(shí)候，fork過程可能會持續(xù)數(shù)秒。

可能會因?yàn)閿?shù)據(jù)量大而導(dǎo)致主進(jìn)程長時(shí)間被掛起，造成Redis服務(wù)不可用。因此，在設(shè)計(jì)時(shí)應(yīng)盡可能減少數(shù)據(jù)量或者優(yōu)化fork的調(diào)用頻率。

2.關(guān)于寫時(shí)復(fù)制的思考

上述寫時(shí)復(fù)制流程貌似有個(gè)問題：

比如，有個(gè)鍵值對 k1 a 。此時(shí)Redis正在bgsave。這時(shí)客戶端發(fā)來一個(gè)請求，主進(jìn)程發(fā)生寫操作set k1 b，由于寫時(shí)復(fù)制，此時(shí)子進(jìn)程里k1的值還是a。最終持久化的也是a。

為什么不直接持久化新值而持久化舊值？寫時(shí)復(fù)制的意義是什么？

基于上面的問題，可以給出的解釋主要有兩點(diǎn)：

• 其實(shí)Redis為了性能考慮，內(nèi)存的持久化是一個(gè)順序?qū)懙牟僮?。子進(jìn)程備份RDB是一個(gè)順序?qū)懙倪^程，如果主進(jìn)程的所有寫入請求都隨時(shí)記錄到RDB文件中，那么理論更新的key可能在任何位置出現(xiàn)，就會變?yōu)殡S機(jī)寫，性能低。
• 其次如果主進(jìn)程一直在寫入更新key的話，那么這次RDB備份一直都在寫主進(jìn)程寫入的新值，永遠(yuǎn)不會停止。

3.RDB相關(guān)配置

以下是一些RDB的相關(guān)參數(shù)配置：

• save：指定 RDB 持久化操作的條件。當(dāng) Redis 的數(shù)據(jù)發(fā)生變化，并且經(jīng)過指定的時(shí)間（seconds）和變化次數(shù)（changes）后，Redis 會自動(dòng)執(zhí)行一次 RDB 操作。例如，save 3600 10000 表示如果 Redis 的數(shù)據(jù)在一個(gè)小時(shí)內(nèi)發(fā)生了至少 10000 次修改，那么 Redis 將執(zhí)行一次 RDB 操作。
• stop-writes-on-bgsave-error：指定在 RDB 持久化過程中如果出現(xiàn)錯(cuò)誤是否停止寫入操作。如果設(shè)置為 yes，當(dāng) Redis 在執(zhí)行 RDB 操作時(shí)遇到錯(cuò)誤時(shí)，Redis 將停止接受寫入操作；如果設(shè)置為 no，Redis 將繼續(xù)接受寫入操作。
• rdbcompression：指定是否對 RDB 文件進(jìn)行壓縮。如果設(shè)置為 yes，Redis 會在生成 RDB 文件時(shí)對其進(jìn)行壓縮，從而減少磁盤占用空間；如果設(shè)置為 no，Redis 不會對生成的 RDB 文件進(jìn)行壓縮。
• rdbchecksum：指定是否對 RDB 文件進(jìn)行校驗(yàn)和計(jì)算。如果設(shè)置為 yes，在保存 RDB 文件時(shí)，Redis 會計(jì)算一個(gè) CRC64 校驗(yàn)和并將其追加到 RDB 文件的末尾；在加載 RDB 文件時(shí)，Redis 會對文件進(jìn)行校驗(yàn)和驗(yàn)證，以確保文件沒有受到損壞或篡改。
• replica-serve-stale-data：這是 Redis 4.0 中新增的一個(gè)配置項(xiàng)，用于指定復(fù)制節(jié)點(diǎn)在與主節(jié)點(diǎn)斷開連接后是否繼續(xù)向客戶端提舊數(shù)據(jù)。當(dāng)設(shè)置為 yes 時(shí)，在復(fù)制節(jié)點(diǎn)與主節(jié)點(diǎn)斷開連接后，該節(jié)點(diǎn)將繼續(xù)向客戶端提供舊數(shù)據(jù)，直到重新連接上主節(jié)點(diǎn)并且同步完全新的數(shù)據(jù)為止；當(dāng)設(shè)置為 no 時(shí)，復(fù)制節(jié)點(diǎn)會立即停止向客戶端提供數(shù)據(jù)，并且等待重新連接上主節(jié)點(diǎn)并同步數(shù)據(jù)。需要注意的是，當(dāng) replica-serve-stale-data 設(shè)置為 yes 時(shí)，可能會存在一定的數(shù)據(jù)不一致性問題，因此建議僅在特定場景下使用。
• repl-diskless-sync：這是 Redis 2.8 中引入的一個(gè)配置項(xiàng)，用于指定復(fù)制節(jié)點(diǎn)在進(jìn)行初次全量同步（即從主節(jié)點(diǎn)獲取全部數(shù)據(jù)）時(shí)是否采用無盤同步方式。當(dāng)設(shè)置為 yes 時(shí)，復(fù)制節(jié)點(diǎn)將通過網(wǎng)絡(luò)直接獲取主節(jié)點(diǎn)的數(shù)據(jù)，并且不會將數(shù)據(jù)存儲到本地磁盤中；當(dāng)設(shè)置為 no 時(shí)，復(fù)制節(jié)點(diǎn)將先將主節(jié)點(diǎn)的數(shù)據(jù)保存到本地磁盤中，然后再進(jìn)行同步操作。采用無盤同步方式可以避免磁盤 IO 操作對系統(tǒng)性能的影響，但同時(shí)也會增加網(wǎng)絡(luò)負(fù)載和內(nèi)存占用。因此，應(yīng)該根據(jù)具體的場景和需求選擇合適的同步方式。

三、AOF原理

AOF持久化是按照Redis的寫命令順序?qū)懨钭芳拥酱疟P文件的末尾。AOF是一種基于日志的持久化方式，它保存了Redis服務(wù)器所有寫入操作的日志記錄，以保證數(shù)據(jù)的持久性、可靠性和完整性。

AOF持久化技術(shù)的核心思想是將Redis服務(wù)器執(zhí)行的所有寫命令追加到一個(gè)文件中。當(dāng)Redis服務(wù)器重新啟動(dòng)時(shí)，可以通過重新執(zhí)行AOF文件來恢復(fù)服務(wù)器的狀態(tài)。

AOF有個(gè)比較好的優(yōu)勢是可以恢復(fù)誤操作。

舉個(gè)例子，如果你不小心執(zhí)行了 FLUSHALL 命令，導(dǎo)致數(shù)據(jù)被誤刪了 ，但只要 AOF 文件未被重寫，那么只要停止服務(wù)器，移除 AOF 文件末尾的 FLUSHALL 命令，并重啟 Redis ，就可以將數(shù)據(jù)集恢復(fù)到 FLUSHALL 執(zhí)行之前的狀態(tài)。

1.AOF持久化配置

Redis的AOF持久化配置頻率可通過appendfsync 參數(shù)進(jìn)行控制。該參數(shù)有以下三個(gè)選項(xiàng)：

• always：每次有數(shù)據(jù)修改都立即寫入磁盤，是最安全的選項(xiàng)。
• everysec：每秒鐘寫入一次，性能和安全之間做了一個(gè)平衡。
• no：從不主動(dòng)寫入，完全依靠操作系統(tǒng)自身的緩存機(jī)制來決定何時(shí)將數(shù)據(jù)寫入磁盤。

默認(rèn)情況下，Redis的appendfsync參數(shù)設(shè)置為everysec。如果需要提高持久化安全性，可以將其改為always，如果更關(guān)注性能，則可以將其改為no。但是需要注意的是，使用no可能會導(dǎo)致數(shù)據(jù)丟失的風(fēng)險(xiǎn)，建議在應(yīng)用場景允許的情況下謹(jǐn)慎使用。

2.AOF文件解讀

一個(gè)簡單的AOF文件示例如下：

其中：

• *號：表示參數(shù)個(gè)數(shù)，后面緊跟著參數(shù)的長度和值。
• $號：表示參數(shù)長度，后面緊跟著參數(shù)的值。

實(shí)際上AOF文件中保存的所有命令都遵循相同的格式，即以*開頭表示參數(shù)個(gè)數(shù)，$開頭表示參數(shù)長度，其后緊跟著參數(shù)的值。

3.AOF文件修復(fù)

服務(wù)器可能在程序正在對 AOF 文件進(jìn)行寫入時(shí)停機(jī)，造成AOF 文件損壞。

發(fā)生這種情況時(shí)，可以使用 Redis 自帶的 redis-check-aof 程序，對 AOF 文件進(jìn)行修復(fù)，命令如下：

$ redis-check-aof –fix

4.AOF重寫

Redis的AOF重寫機(jī)制指的是將AOF文件中的冗余命令刪除，以減小AOF文件的大小并提高讀寫性能的過程。

Redis的AOF重寫機(jī)制采用了類似于復(fù)制的方式，首先將內(nèi)存中的數(shù)據(jù)快照保存到一個(gè)臨時(shí)文件中，然后遍歷這個(gè)臨時(shí)文件，只保留最終狀態(tài)的命令，生成新的AOF文件。

具體來說，Redis執(zhí)行AOF重寫可以分為以下幾個(gè)步驟：

• 開始AOF重寫過程，向客戶端返回一個(gè)提示信息。
• 創(chuàng)建一個(gè)臨時(shí)文件，并將當(dāng)前數(shù)據(jù)庫中的鍵值對寫入到臨時(shí)文件中。
• 在創(chuàng)建的臨時(shí)文件中將所有的寫命令都轉(zhuǎn)換成Redis內(nèi)部的表示格式，即使用一系列的Redis命令來表示一個(gè)操作，例如使用SET命令來表示對某個(gè)鍵進(jìn)行賦值操作。
• 對臨時(shí)文件進(jìn)行壓縮，去掉多余的空格和換行符等，減小文件體積。
• 將壓縮后的內(nèi)容寫入到新的AOF文件中。
• 停止寫入命令到舊的AOF文件，并將新的AOF文件的文件名替換為舊的AOF文件的文件名。
• 結(jié)束AOF重寫過程，并向客戶端發(fā)送完成提示信息。

通過AOF重寫機(jī)制，Redis可以在不停止服務(wù)的情況下減小AOF文件的大小，提高讀寫性能，同時(shí)也可以保證數(shù)據(jù)的一致性。

Redis提供了手動(dòng)觸發(fā)AOF重寫的命令 BGREWRITEAOF ?？梢栽赗edis的客戶端中執(zhí)行該命令來啟動(dòng)AOF重寫過程。Redis 2.2 需要自己手動(dòng)執(zhí)行 BGREWRITEAOF 命令，到了 Redis 2.4 則可以自動(dòng)觸發(fā) AOF 重寫。

具體操作步驟如下：

(1)打開redis-cli命令行工具，連接到Redis服務(wù)。

(2)執(zhí)行BGREWRITEAOF命令，啟動(dòng)AOF重寫過程。

$ redis-cli
127.0.0.1:6379> BGREWRITEAOF

(3) Redis會返回一個(gè)后臺任務(wù)的ID，表示AOF重寫任務(wù)已經(jīng)開始。

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started by pid 1234

(4)可以使用INFO PERSISTENCE命令查看當(dāng)前AOF文件的大小和重寫過程的狀態(tài)，等待重寫完成即可。

127.0.0.1:6379> INFO PERSISTENCE
# Persistence
aof_enabled:1
aof_rewrite_in_progress:1
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:0
aof_current_rewrite_time_sec:14
aof_last_bgrewrite_status:ok
aof_last_write_status:ok

需要注意的是，執(zhí)行BGREWRITEAOF命令可能會占用較多的CPU和內(nèi)存資源，因此在生產(chǎn)環(huán)境中需要謹(jǐn)慎使用，并確保有足夠的系統(tǒng)資源支持。

同時(shí)，即使手動(dòng)觸發(fā)AOF重寫，Redis也會在滿足一定條件時(shí)自動(dòng)觸發(fā)AOF重寫，以保證AOF文件的大小和性能。

需要注意的是：

在版本號大于等于 2.4 的 Redis 中，BGSAVE 執(zhí)行的過程中，不可以執(zhí)行 BGREWRITEAOF 。反過來說，在 BGREWRITEAOF 執(zhí)行的過程中，也不可以執(zhí)行 BGSAVE。目的是防止兩個(gè) Redis 后臺進(jìn)程同時(shí)對磁盤進(jìn)行大量的 I/O 操作。

5.AOF緩沖區(qū)與AOF重寫緩存區(qū)

在Redis中，盡管「AOF緩沖區(qū)」和「AOF重寫緩沖區(qū)」的名稱相似，但它們實(shí)際上是兩個(gè)不同的概念。

AOF緩沖區(qū)是一個(gè)用于暫存需要寫入AOF文件的命令的緩沖區(qū)。在Redis處理客戶端發(fā)來的寫命令時(shí)，如果開啟了AOF持久化功能，則該命令將被先寫入到AOF緩沖區(qū)。AOF緩沖區(qū)中的內(nèi)容通過配置的規(guī)則持久化到磁盤上。持久化規(guī)則可以通過配置項(xiàng)appendfsync來調(diào)整。

AOF重寫緩沖區(qū)是一個(gè)用于執(zhí)行AOF文件的重寫操作的緩沖區(qū)。AOF重寫操作是一種將現(xiàn)有AOF文件重寫成最小化的新AOF文件的操作。AOF重寫操作的目的是減少AOF文件的大小，同時(shí)加快恢復(fù)速度。AOF重寫緩存區(qū)在AOF重寫時(shí)開始啟用，Redis服務(wù)器主進(jìn)程在執(zhí)行完寫命令之后，會同時(shí)將這個(gè)寫命令追加到AOF緩沖區(qū)和AOF重寫緩沖區(qū)。

示意圖如下：

6.AOF緩沖區(qū)可以替代AOF重寫緩沖區(qū)嗎

AOF緩沖區(qū)不可以替代AOF重寫緩沖區(qū)。

原因是AOF重寫緩沖區(qū)記錄的是從重寫開始后的所有需要重寫的命令，而AOF緩沖區(qū)可能只記錄了部分的命令（如果寫回的話，AOF緩存區(qū)的數(shù)據(jù)就會失效被丟失，因而只會保存一部分的命令，而AOF重寫緩存區(qū)不會）。

AOF緩沖區(qū)主要是Redis用來解決主進(jìn)程執(zhí)行命令速度與磁盤寫入速度不同步所設(shè)置的，通過AOF緩沖區(qū)可以有效地避免頻繁對硬盤進(jìn)行讀寫，進(jìn)而提升性能。Redis在AOF持久化的時(shí)候，會先把命令寫入到AOF緩沖區(qū)，然后通過寫回策略來寫入硬盤AOF文件。

7.AOF相關(guān)配置

在 Redis 的配置文件 redis.conf 中，可以通過以下配置項(xiàng)來設(shè)置 AOF 相關(guān)參數(shù)：

(1)appendonly：該配置項(xiàng)用于開啟或關(guān)閉 AOF，默認(rèn)為關(guān)閉。若開啟了 AOF，Redis 會在每次執(zhí)行寫命令時(shí)，將命令追加到 AOF 文件末尾。

(2)appendfilename：用于設(shè)置 AOF 文件名，默認(rèn)為 appendonly.aof。

(3)appendfsync：該配置項(xiàng)用于設(shè)置 AOF 的同步機(jī)制。有三種可選值：

• always：表示每個(gè)寫命令都要同步到磁盤，安全性最高，但是性能較差。
• everysec：表示每秒同步一次，是默認(rèn)選項(xiàng)，既能保證數(shù)據(jù)安全，又具有較好的性能。
• no：表示不進(jìn)行同步，而是由操作系統(tǒng)決定何時(shí)將緩沖區(qū)中的數(shù)據(jù)同步到磁盤上，性能最好，但是安全性較低。

(4)auto-aof-rewrite-percentage和auto-aof-rewrite-min-size：這兩個(gè)配置項(xiàng)用于設(shè)置 AOF 重寫規(guī)則。當(dāng) AOF 文件大小超過 auto-aof-rewrite-min-size 設(shè)置的值，并且 AOF 文件增長率達(dá)到 auto-aof-rewrite-percentage 所定義的百分比時(shí)，Redis 會啟動(dòng) AOF 重寫操作。

auto-aof-rewrite-percentage默認(rèn)值為100，以及`auto-aof-rewrite-min-size默認(rèn)值為64mb，也就是說默認(rèn)Redis會記錄上次重寫時(shí)的AOF大小，默認(rèn)配置是當(dāng)AOF文件大小是上次rewrite后大小的一倍且文件大于64M時(shí)觸發(fā)。

(5)aof-use-rdb-preamble：Redis 4版本新特性，混合持久化。AOF重寫期間是否開啟增量式同步，該配置項(xiàng)在AOF重寫期間是否使用RDB文件內(nèi)容。默認(rèn)是no，如果設(shè)置為yes，在AOF文件頭加入一個(gè)RDB文件的內(nèi)容，可以盡可能的減小AOF文件大小，同時(shí)也方便恢復(fù)數(shù)據(jù)。

8.寫后日志

我們比較熟悉的是數(shù)據(jù)庫的寫前日志（Write Ahead Log，WAL），也就是說，在實(shí)際寫數(shù)據(jù)前，先把修改的數(shù)據(jù)記到日志文件中，以便故障時(shí)進(jìn)行恢復(fù)。

不過，AOF 日志卻正好相反，它是寫后日志，“寫后”的意思是 Redis 是先執(zhí)行命令，把數(shù)據(jù)寫入內(nèi)存，然后才記錄日志。

為什么要這樣設(shè)計(jì)？

其實(shí)為了避免額外的檢查開銷，Redis 在向 AOF 里面記錄日志的時(shí)候，并不會先去對這些命令進(jìn)行語法檢查。所以，如果先記日志再執(zhí)行命令的話，日志中就有可能記錄了錯(cuò)誤的命令，Redis 在使用日志恢復(fù)數(shù)據(jù)時(shí)，就可能會出錯(cuò)。

而寫后日志這種方式，就是先讓系統(tǒng)執(zhí)行命令，只有命令能執(zhí)行成功，才會被記錄到日志中，否則，系統(tǒng)就會直接向客戶端報(bào)錯(cuò)。所以，Redis 使用寫后日志這一方式的一大好處是，可以避免出現(xiàn)記錄錯(cuò)誤命令的情況。

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

不過，寫后日志也有兩個(gè)潛在的風(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ù)了。
• 其次，AOF 雖然避免了對當(dāng)前命令的阻塞，但可能會給下一個(gè)操作帶來阻塞風(fēng)險(xiǎn)。這是因?yàn)椋珹OF 日志也是在主線程中執(zhí)行的，如果在把日志文件寫入磁盤時(shí)，磁盤寫壓力大，就會導(dǎo)致寫盤很慢，進(jìn)而導(dǎo)致后續(xù)的操作也無法執(zhí)行了。

四、混合持久化

在過去， Redis 用戶通常會因?yàn)?RDB 持久化和 AOF 持久化之間不同的優(yōu)缺點(diǎn)而陷入兩難的選擇當(dāng)中：

• RDB 持久化能夠快速地儲存和恢復(fù)數(shù)據(jù)，但是在服務(wù)器停機(jī)時(shí)可能會丟失大量數(shù)據(jù)。
• AOF 持久化能夠有效地提高數(shù)據(jù)的安全性，但是在儲存和恢復(fù)數(shù)據(jù)方面卻要耗費(fèi)大量的時(shí)間。

為了讓用戶能夠同時(shí)擁有上述兩種持久化的優(yōu)點(diǎn)， Redis 4.0 推出了一個(gè)“魚和熊掌兼得”的持久化方案 —— RDB-AOF 混合持久化。

這種持久化能夠通過 AOF 重寫操作創(chuàng)建出一個(gè)同時(shí)包含 RDB 數(shù)據(jù)和 AOF 數(shù)據(jù)的 AOF 文件， 其中 RDB 數(shù)據(jù)位于 AOF 文件的開頭， 它們儲存了服務(wù)器開始執(zhí)行重寫操作時(shí)的數(shù)據(jù)庫狀態(tài)。至于那些在重寫操作執(zhí)行之后執(zhí)行的 Redis 命令， 則會繼續(xù)以 AOF 格式追加到 AOF 文件的末尾， 也即是 RDB 數(shù)據(jù)之后。

也就是說當(dāng)開啟混合持久化之后，AOF文件中的內(nèi)容：前半部分是二進(jìn)制的RDB內(nèi)容，后面跟著AOF增加的數(shù)據(jù)，AOF位于兩次RDB之間。

格式會類似下面這樣：

（二進(jìn)制）RDB
 AOF
（二進(jìn)制）RDB

在目前版本中， RDB-AOF 混合持久化功能默認(rèn)是處于關(guān)閉狀態(tài)的， 為了啟用該功能， 用戶不僅需要開啟 AOF 持久化功能， 還需要將 aof-use-rdb-preamble 選項(xiàng)的值設(shè)置為 true。

appendonly yes
aof-use-rdb-preamble yes

五、如何選擇合適的持久化方式

當(dāng)你想選擇適合你的應(yīng)用程序的持久化方式時(shí)，你需要考慮以下兩個(gè)因素：

(1)數(shù)據(jù)的實(shí)時(shí)性和一致性：如果對數(shù)據(jù)的實(shí)時(shí)性和一致性有很高的要求，則AOF可能是更好的選擇。

如果對數(shù)據(jù)的實(shí)時(shí)性和一致性要求不太高，并且希望能快速地加載數(shù)據(jù)并減少磁盤空間的使用，那么RDB可能更適合你的應(yīng)用程序。因?yàn)镽DB文件是二進(jìn)制格式的，結(jié)構(gòu)非常緊湊，所以在Redis重啟時(shí)可以迅速地加載數(shù)據(jù)。

(2)Redis的性能需求：如果對Redis的性能有很高的要求，那么關(guān)閉持久化功能也是一個(gè)選擇。因?yàn)槌志没δ芸赡軙绊慠edis的性能，但是一般不建議這么做。

本篇文章到這就結(jié)束了，最后我們來做個(gè)小總結(jié)：

我們要意識到Redis的持久化機(jī)制扮演著至關(guān)重要的角色。RDB和AOF兩種主要的持久化方式各有其優(yōu)勢和使用場景。

RDB通過提供特定時(shí)間點(diǎn)的數(shù)據(jù)快照，對于災(zāi)難恢復(fù)是非常有效的；而AOF則通過記錄每個(gè)寫入操作，提供了更好的數(shù)據(jù)持久性保證。然而，它們也有各自的局限性，這就需要根據(jù)實(shí)際需求來權(quán)衡選用哪種持久化方式。

最后，不可忽視的是，在選擇合適的持久化策略時(shí)，我們還應(yīng)考慮如何平衡內(nèi)存使用、磁盤使用、性能與持久性等多個(gè)因素。只有對Redis持久化的深入理解，我們才能充分利用其強(qiáng)大的功能，以滿足各種業(yè)務(wù)需求。

希望這篇文章能夠給你帶來收獲和思考，謝謝。