原創(chuàng)不易，注重版權(quán)。轉(zhuǎn)載請(qǐng)注明原作者和原文鏈接

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

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

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

Redis持久化介紹

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

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

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

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

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

RDB原理

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

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

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

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

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

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

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

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

save 10 100

Fork函數(shù)與寫(xiě)時(shí)復(fù)制

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

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

翻譯如下：

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

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

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

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

示意圖如下：

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

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

不過(guò)，需要注意的是：

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

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

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

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

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

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

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

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

RDB相關(guān)配置

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

• save：指定 RDB 持久化操作的條件。當(dāng) Redis 的數(shù)據(jù)發(fā)生變化，并且經(jīng)過(guò)指定的時(shí)間（seconds）和變化次數(shù)（changes）后，Redis 會(huì)自動(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 持久化過(guò)程中如果出現(xiàn)錯(cuò)誤是否停止寫(xiě)入操作。如果設(shè)置為 yes，當(dāng) Redis 在執(zhí)行 RDB 操作時(shí)遇到錯(cuò)誤時(shí)，Redis 將停止接受寫(xiě)入操作；如果設(shè)置為 no，Redis 將繼續(xù)接受寫(xiě)入操作。

• rdbcompression：指定是否對(duì) RDB 文件進(jìn)行壓縮。如果設(shè)置為 yes，Redis 會(huì)在生成 RDB 文件時(shí)對(duì)其進(jìn)行壓縮，從而減少磁盤(pán)占用空間；如果設(shè)置為 no，Redis 不會(huì)對(duì)生成的 RDB 文件進(jìn)行壓縮。

• rdbchecksum：指定是否對(duì) RDB 文件進(jìn)行校驗(yàn)和計(jì)算。如果設(shè)置為 yes，在保存 RDB 文件時(shí)，Redis 會(huì)計(jì)算一個(gè) CRC64 校驗(yàn)和并將其追加到 RDB 文件的末尾；在加載 RDB 文件時(shí)，Redis 會(huì)對(duì)文件進(jìn)行校驗(yàn)和驗(yàn)證，以確保文件沒(méi)有受到損壞或篡改。

• replica-serve-stale-data：這是 Redis 4.0 中新增的一個(gè)配置項(xiàng)，用于指定復(fù)制節(jié)點(diǎn)在與主節(jié)點(diǎn)斷開(kāi)連接后是否繼續(xù)向客戶端提舊數(shù)據(jù)。當(dāng)設(shè)置為 yes 時(shí)，在復(fù)制節(jié)點(diǎn)與主節(jié)點(diǎn)斷開(kāi)連接后，該節(jié)點(diǎn)將繼續(xù)向客戶端提供舊數(shù)據(jù)，直到重新連接上主節(jié)點(diǎn)并且同步完全新的數(shù)據(jù)為止；當(dāng)設(shè)置為 no 時(shí)，復(fù)制節(jié)點(diǎn)會(huì)立即停止向客戶端提供數(shù)據(jù)，并且等待重新連接上主節(jié)點(diǎn)并同步數(shù)據(jù)。需要注意的是，當(dāng) replica-serve-stale-data 設(shè)置為 yes 時(shí)，可能會(huì)存在一定的數(shù)據(jù)不一致性問(wèn)題，因此建議僅在特定場(chǎng)景下使用。

• repl-diskless-sync：這是 Redis 2.8 中引入的一個(gè)配置項(xiàng)，用于指定復(fù)制節(jié)點(diǎn)在進(jìn)行初次全量同步（即從主節(jié)點(diǎn)獲取全部數(shù)據(jù)）時(shí)是否采用無(wú)盤(pán)同步方式。當(dāng)設(shè)置為 yes 時(shí)，復(fù)制節(jié)點(diǎn)將通過(guò)網(wǎng)絡(luò)直接獲取主節(jié)點(diǎn)的數(shù)據(jù)，并且不會(huì)將數(shù)據(jù)存儲(chǔ)到本地磁盤(pán)中；當(dāng)設(shè)置為 no 時(shí)，復(fù)制節(jié)點(diǎn)將先將主節(jié)點(diǎn)的數(shù)據(jù)保存到本地磁盤(pán)中，然后再進(jìn)行同步操作。采用無(wú)盤(pán)同步方式可以避免磁盤(pán) IO 操作對(duì)系統(tǒng)性能的影響，但同時(shí)也會(huì)增加網(wǎng)絡(luò)負(fù)載和內(nèi)存占用。因此，應(yīng)該根據(jù)具體的場(chǎng)景和需求選擇合適的同步方式。

AOF原理

AOF持久化是按照Redis的寫(xiě)命令順序?qū)?xiě)命令追加到磁盤(pán)文件的末尾。AOF是一種基于日志的持久化方式，它保存了Redis服務(wù)器所有寫(xiě)入操作的日志記錄，以保證數(shù)據(jù)的持久性、可靠性和完整性。

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

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

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

AOF持久化配置

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

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

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

AOF文件解讀

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

其中：

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

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

AOF文件修復(fù)

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

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

$ redis-check-aof –fix

AOF重寫(xiě)

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

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

具體來(lái)說(shuō)，Redis執(zhí)行AOF重寫(xiě)可以分為以下幾個(gè)步驟：

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

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

Redis提供了手動(dòng)觸發(fā)AOF重寫(xiě)的命令 BGREWRITEAOF 。可以在Redis的客戶端中執(zhí)行該命令來(lái)啟動(dòng)AOF重寫(xiě)過(guò)程。Redis 2.2 需要自己手動(dòng)執(zhí)行 BGREWRITEAOF 命令，到了 Redis 2.4 則可以自動(dòng)觸發(fā) AOF 重寫(xiě)。

具體操作步驟如下：

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

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

   $ redis-cli
   127.0.0.1:6379> BGREWRITEAOF
   

3. Redis會(huì)返回一個(gè)后臺(tái)任務(wù)的ID，表示AOF重寫(xiě)任務(wù)已經(jīng)開(kāi)始。

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

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

   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命令可能會(huì)占用較多的CPU和內(nèi)存資源，因此在生產(chǎn)環(huán)境中需要謹(jǐn)慎使用，并確保有足夠的系統(tǒng)資源支持。

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

需要注意的是：

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

AOF緩沖區(qū)與AOF重寫(xiě)緩存區(qū)

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

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

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

示意圖如下：

AOF緩沖區(qū)可以替代AOF重寫(xiě)緩沖區(qū)嗎

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

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

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

AOF相關(guān)配置

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

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

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

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

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

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

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

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

寫(xiě)后日志

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

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

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

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

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

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

不過(guò)，寫(xiě)后日志也有兩個(gè)潛在的風(fēng)險(xiǎn)：

• 首先，如果剛執(zhí)行完一個(gè)命令，還沒(méi)有來(lái)得及記日志就宕機(jī)了，那么這個(gè)命令和相應(yīng)的數(shù)據(jù)就有丟失的風(fēng)險(xiǎn)。如果此時(shí) Redis 是用作緩存，還可以從后端數(shù)據(jù)庫(kù)重新讀入數(shù)據(jù)進(jìn)行恢復(fù)，但是，如果 Redis 是直接用作數(shù)據(jù)庫(kù)的話，此時(shí)，因?yàn)槊顩](méi)有記入日志，所以就無(wú)法用日志進(jìn)行恢復(fù)了。
• 其次，AOF 雖然避免了對(duì)當(dāng)前命令的阻塞，但可能會(huì)給下一個(gè)操作帶來(lái)阻塞風(fēng)險(xiǎn)。這是因?yàn)?#xff0c;AOF 日志也是在主線程中執(zhí)行的，如果在把日志文件寫(xiě)入磁盤(pán)時(shí)，磁盤(pán)寫(xiě)壓力大，就會(huì)導(dǎo)致寫(xiě)盤(pán)很慢，進(jìn)而導(dǎo)致后續(xù)的操作也無(wú)法執(zhí)行了。

混合持久化

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

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

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

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

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

格式會(huì)類似下面這樣：

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

在目前版本中， RDB-AOF 混合持久化功能默認(rèn)是處于關(guān)閉狀態(tài)的， 為了啟用該功能， 用戶不僅需要開(kā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í)性和一致性：如果對(duì)數(shù)據(jù)的實(shí)時(shí)性和一致性有很高的要求，則AOF可能是更好的選擇。

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

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

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

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

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

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

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