寫在前面

Redis的持久化，這部分的知識(shí)點(diǎn)不僅求職面試的時(shí)候是重點(diǎn)，工作中也是經(jīng)常打交道。說(shuō)起持久化都會(huì)想到RDB和AOF，但是里面有些細(xì)節(jié)是可以展開去聊的。

比如：為什么 fork速度這么快？AOF是如何提高寫入性能的？等問題。對(duì)這些疑問本文都會(huì)有所解答。

Redis持久化介紹

Redis持久化分為兩種：RDB(Redis DataBase)和AOF(Append Only File)。

RDB是指將Redis內(nèi)存中的數(shù)據(jù)定期寫入磁盤上的一個(gè)快照文件中；

而AOF則是以追加的方式記錄Redis執(zhí)行的每一條寫命令。

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

你也許會(huì)問，為什么需要持久化呢？因?yàn)镽edis作為一款內(nèi)存數(shù)據(jù)庫(kù)，在進(jìn)程異常退出或服務(wù)器斷電之后，所有的數(shù)據(jù)都將消失。

如果沒有持久化功能，無(wú)法保證數(shù)據(jù)的持久性，那么這樣的數(shù)據(jù)庫(kù)還有什么用呢？

因此，Redis提供了持久化功能，以確保數(shù)據(jù)的可靠性和持久性。接下來(lái)，我們將分別介紹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)是快速、簡(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)方式通過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ù)與寫時(shí)復(fù)制

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

我們可以使用 man fork 來(lái)查看下說(shuō)明文檔。

翻譯：在Linux下，fork()是使用寫時(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ù)復(fù)制的是指針，不會(huì)復(fù)制數(shù)據(jù)，所以速度很快。

需要注意的是，fork的這個(gè)過程主進(jìn)程是阻塞的，fork完之后不阻塞。

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

簡(jiǎn)單畫了個(gè)示意圖：

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

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

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

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

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

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

主要有2點(diǎn)原因：

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

RDB相關(guān)配置

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

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文件來(lái)恢復(fù)服務(wù)器的狀態(tài)。

AOF有個(gè)比較好的優(yōu)勢(shì)是可以恢復(fù)誤操作。舉個(gè)例子，如果你不小心執(zhí)行了 FLUSHALL 命令，但只要 AOF 文件未被重寫，那么只要停止服務(wù)器，移除 AOF 文件末尾的 FLUSHALL 命令，并重啟 Redis ，就可以將數(shù)據(jù)集恢復(fù)到 FLUSHALL 執(zhí)行之前的狀態(tài)，重寫了就沒辦法了。

AOF持久化配置

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

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

默認(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文件中保存的所有命令都遵循相同的格式，即以*開頭表示參數(shù)個(gè)數(shù)，$開頭表示參數(shù)長(zhǎng)度，其后緊跟著參數(shù)的值。

AOF文件修復(fù)

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

可以使用 Redis 自帶的 redis-check-aof 程序，對(duì)原來(lái)的 AOF 文件進(jìn)行修復(fù):

$ redis-check-aof –fix

AOF重寫

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

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

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

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

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

Redis提供了手動(dòng)觸發(fā)AOF重寫的命令BGREWRITEAOF。

可以在Redis的客戶端中執(zhí)行該命令來(lái)啟動(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會(huì)返回一個(gè)后臺(tái)任務(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命令可能會(huì)占用較多的CPU和內(nèi)存資源，因此在生產(chǎn)環(huán)境中需要謹(jǐn)慎使用，并確保有足夠的系統(tǒng)資源支持。同時(shí)，即使手動(dòng)觸發(fā)AOF重寫，Redis也會(huì)在滿足一定條件時(shí)自動(dòng)觸發(fā)AOF重寫，以保證AOF文件的大小和性能。

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

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

在Redis中，AOF緩沖區(qū)和AOF重寫緩沖區(qū)是兩個(gè)不同的概念。

AOF緩沖區(qū)是一個(gè)用于暫存需要寫入AOF文件的命令的緩沖區(qū)。在Redis處理客戶端發(fā)來(lái)的寫命令時(shí)，如果開啟了AOF持久化功能，則該命令將被先寫入到AOF緩沖區(qū)。AOF緩沖區(qū)中的內(nèi)容通過配置的規(guī)則持久化到磁盤上。持久化規(guī)則可以通過配置項(xiàng)appendfsync來(lái)調(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í)行完寫命令之后，會(huì)同時(shí)將這個(gè)寫命令追加到AOF緩沖區(qū)和AOF重寫緩沖區(qū)。

需要注意的是，AOF緩沖區(qū)和AOF重寫緩沖區(qū)是不同的概念，但它們都使用了Redis的內(nèi)存緩沖機(jī)制，并且都會(huì)影響Redis服務(wù)器的性能。因此，在實(shí)際使用中，應(yīng)該合理配置AOF緩沖區(qū)大小和AOF重寫規(guī)則，以確保Redis服務(wù)器的正常運(yùn)行和高性能。

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

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

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

AOF相關(guān)配置

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

1. appendonly：該配置項(xiàng)用于開啟或關(guān)閉 AOF，默認(rèn)為關(guān)閉。若開啟了 AOF，Redis 會(huì)在每次執(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 文件增長(zhǎng)率達(dá)到 auto-aof-rewrite-percentage 所定義的百分比時(shí)，Redis 會(huì)啟動(dòng) AOF 重寫操作。auto-aof-rewrite-percentage：默認(rèn)值為100，以及auto-aof-rewrite-min-size：64mb 配置，也就是說(shuō)默認(rèn)Redis會(huì)記錄上次重寫時(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ù)。

寫后日志

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

why？

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

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

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

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

首先，如果剛執(zhí)行完一個(gè)命令，還沒有來(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)槊顩]有記入日志，所以就無(wú)法用日志進(jìn)行恢復(fù)了。

其次，AOF 雖然避免了對(duì)當(dāng)前命令的阻塞，但可能會(huì)給下一個(gè)操作帶來(lái)阻塞風(fēng)險(xiǎn)。這是因?yàn)?，AOF 日志也是在主線程中執(zhí)行的，如果在把日志文件寫入磁盤時(shí)，磁盤寫壓力大，就會(huì)導(dǎo)致寫盤很慢，進(jìn)而導(dǎo)致后續(xù)的操作也無(wú)法執(zhí)行了。

混合持久化

在過去， 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è)“魚和熊掌兼得”的持久化方案 —— RDB-AOF 混合持久化： 這種持久化能夠通過 AOF 重寫操作創(chuàng)建出一個(gè)同時(shí)包含 RDB 數(shù)據(jù)和 AOF 數(shù)據(jù)的 AOF 文件， 其中 RDB 數(shù)據(jù)位于 AOF 文件的開頭， 它們儲(chǔ)存了服務(wù)器開始執(zhí)行重寫操作時(shí)的數(shù)據(jù)庫(kù)狀態(tài)。至于那些在重寫操作執(zhí)行之后執(zhí)行的 Redis 命令， 則會(huì)繼續(xù)以 AOF 格式追加到 AOF 文件的末尾， 也即是 RDB 數(shù)據(jù)之后。

說(shuō)就是說(shuō)開啟混合持久化之后，AOF文件中的內(nèi)容：前半部分是二進(jìn)制的RDB內(nèi)容，后面跟著AOF增加的數(shù)據(jù)，AOF位于2次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í)性和一致性：如果您對(duì)數(shù)據(jù)的實(shí)時(shí)性和一致性有很高的要求，則AOF可能是更好的選擇。
2. 如果您對(duì)數(shù)據(jù)的實(shí)時(shí)性和一致性要求不太高，并且希望能快速地加載數(shù)據(jù)并減少磁盤空間的使用，那么RDB就可能更適合您的應(yīng)用程序。因?yàn)镽DB文件是二進(jìn)制格式的，所以它很緊湊，并且在Redis重啟時(shí)可以迅速地加載數(shù)據(jù)。
3. Redis的性能需求：如果您對(duì)Redis的性能有很高的要求，那么關(guān)閉持久化功能也是一個(gè)選擇。因?yàn)槌志没δ芸赡軙?huì)影響Redis的性能，但是一般不建議這么做。 總結(jié)

通過本文的介紹，我們了解了Redis持久化的兩種方式，RDB和AOF，它們都有自己獨(dú)特的優(yōu)勢(shì)，我們應(yīng)該根據(jù)項(xiàng)目大小、數(shù)據(jù)量和業(yè)務(wù)需求制定不同的持久化策略。

到此這篇關(guān)于Redis的RDB持久化與AOF持久化詳解的文章就介紹到這了,更多相關(guān)Redis持久化內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！