Redis持久化深度解析

作者：碼農(nóng)BookSea 2023-10-12 13:01:29

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

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

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

一、Redis持久化介紹

你也許會(huì)問，為什么需要持久化呢？因?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í)候會(huì)優(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ù)可能會(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ù)集。

比如說，以下設(shè)置會(huì)讓 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ù)會(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ù)寫入到磁盤中。為了避免父子進(jìn)程同時(shí)對內(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ú)立。

示意圖如下：

當(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ì)對 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í)的，可能會(huì)導(dǎo)致Redis在一些毫秒級(jí)內(nèi)不能響應(yīng)客戶端的請求，數(shù)據(jù)集很大的時(shí)候，fork過程可能會(huì)持續(xù)數(shù)秒。

可能會(huì)因?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ū)懙牟僮鳌Ｗ舆M(jìn)程備份RDB是一個(gè)順序?qū)懙倪^程，如果主進(jìn)程的所有寫入請求都隨時(shí)記錄到RDB文件中，那么理論更新的key可能在任何位置出現(xiàn)，就會(huì)變?yōu)殡S機(jī)寫，性能低。
其次如果主進(jìn)程一直在寫入更新key的話，那么這次RDB備份一直都在寫主進(jìn)程寫入的新值，永遠(yuǎn)不會(huì)停止。

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

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

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 操作。
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 會(huì)在生成 RDB 文件時(shí)對其進(jìn)行壓縮，從而減少磁盤占用空間；如果設(shè)置為 no，Redis 不會(huì)對生成的 RDB 文件進(jìn)行壓縮。
rdbchecksum：指定是否對 RDB 文件進(jìn)行校驗(yàn)和計(jì)算。如果設(shè)置為 yes，在保存 RDB 文件時(shí)，Redis 會(huì)計(jì)算一個(gè) CRC64 校驗(yàn)和并將其追加到 RDB 文件的末尾；在加載 RDB 文件時(shí)，Redis 會(huì)對文件進(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)會(huì)立即停止向客戶端提供數(shù)據(jù)，并且等待重新連接上主節(jié)點(diǎn)并同步數(shù)據(jù)。需要注意的是，當(dāng) replica-serve-stale-data 設(shè)置為 yes 時(shí)，可能會(huì)存在一定的數(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ù)，并且不會(huì)將數(shù)據(jù)存儲(chǔ)到本地磁盤中；當(dāng)設(shè)置為 no 時(shí)，復(fù)制節(jié)點(diǎn)將先將主節(jié)點(diǎn)的數(shù)據(jù)保存到本地磁盤中，然后再進(jìn)行同步操作。采用無盤同步方式可以避免磁盤 IO 操作對系統(tǒng)性能的影響，但同時(shí)也會(huì)增加網(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可能會(huì)導(dǎo)致數(shù)據(jù)丟失的風(fēng)險(xiǎn)，建議在應(yīng)用場景允許的情況下謹(jǐn)慎使用。

2.AOF文件解讀

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

其中：

*號(hào)：表示參數(shù)個(gè)數(shù)，后面緊跟著參數(shù)的長度和值。
$號(hào)：表示參數(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 。可以在Redis的客戶端中執(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會(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 。反過來說，在 BGREWRITEAOF 執(zhí)行的過程中，也不可以執(zhí)行 BGSAVE。目的是防止兩個(gè) Redis 后臺(tái)進(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í)行完寫命令之后，會(huì)同時(shí)將這個(gè)寫命令追加到AOF緩沖區(qū)和AOF重寫緩沖區(qū)。

示意圖如下：

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

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

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

AOF緩沖區(qū)主要是Redis用來解決主進(jìn)程執(zhí)行命令速度與磁盤寫入速度不同步所設(shè)置的，通過AOF緩沖區(qū)可以有效地避免頻繁對硬盤進(jìn)行讀寫，進(jìn)而提升性能。Redis在AOF持久化的時(shí)候，會(huì)先把命令寫入到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 會(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 文件增長率達(dá)到 auto-aof-rewrite-percentage 所定義的百分比時(shí)，Redis 會(huì)啟動(dòng) AOF 重寫操作。

auto-aof-rewrite-percentage默認(rèn)值為100，以及`auto-aof-rewrite-min-size默認(rèn)值為64mb，也就是說默認(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ù)。

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í)候，并不會(huì)先去對這些命令進(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ò)誤命令的情況。

除此之外，AOF 寫后日志還有一個(gè)好處：它是在命令執(zhí)行后才記錄日志，所以并不會(huì)阻塞當(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)前命令的阻塞，但可能會(huì)給下一個(gè)操作帶來阻塞風(fēng)險(xiǎn)。這是因?yàn)椋珹OF 日志也是在主線程中執(zhí)行的，如果在把日志文件寫入磁盤時(shí)，磁盤寫壓力大，就會(huì)導(dǎo)致寫盤很慢，進(jìn)而導(dǎo)致后續(xù)的操作也無法執(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ù)庫狀態(tài)。至于那些在重寫操作執(zhí)行之后執(zhí)行的 Redis 命令，則會(huì)繼續(xù)以 AOF 格式追加到 AOF 文件的末尾，也即是 RDB 數(shù)據(jù)之后。

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

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

（二進(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)槌志没δ芸赡軙?huì)影響Redis的性能，但是一般不建議這么做。

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

我們要意識(shí)到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ù)需求。

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

責(zé)任編輯：趙寧寧來源： Java隨想錄