寫在前面

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

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

Redis持久化介紹

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

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

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

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

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

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

因此，Redis提供了持久化功能，以確保數(shù)據(jù)的可靠性和持久性。接下來，我們將分別介紹RDB和AOF的實現(xiàn)原理。

RDB原理

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

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

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

RDB持久化有兩種方式：

• 手動
• 自動

手動方式通過SAVE命令或BGSAVE命令進(jìn)行。

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

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

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

save 10 100

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

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

我們可以使用 man fork 來查看下說明文檔。

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

簡單來說就是 fork()函數(shù)復(fù)制的是指針，不會復(fù)制數(shù)據(jù)，所以速度很快。

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

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

簡單畫了個示意圖：

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

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

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

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

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

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

主要有2點原因：

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

RDB相關(guān)配置

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

AOF原理

AOF持久化是按照Redis的寫命令順序?qū)懨钭芳拥酱疟P文件的末尾。AOF是一種基于日志的持久化方式，它保存了Redis服務(wù)器所有寫入操作的日志記錄，以保證數(shù)據(jù)的持久性、可靠性和完整性。AOF持久化技術(shù)的核心思想是將Redis服務(wù)器執(zhí)行的所有寫命令追加到一個文件中。當(dāng)Redis服務(wù)器重新啟動時，可以通過重新執(zhí)行AOF文件來恢復(fù)服務(wù)器的狀態(tài)。

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

AOF持久化配置

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

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

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

AOF文件解讀

這是一個簡單的AOF文件示例。

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

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

AOF文件修復(fù)

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

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

$ redis-check-aof –fix

AOF重寫

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

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

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

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

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

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

可以在Redis的客戶端中執(zhí)行該命令來啟動AOF重寫過程。

Redis 2.2 需要自己手動執(zhí)行 BGREWRITEAOF 命令；

Redis 2.4 則可以自動觸發(fā) AOF 重寫。

具體操作步驟如下：

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

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

$ redis-cli
127.0.0.1:6379> BGREWRITEAOF

3.Redis會返回一個后臺任務(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)資源支持。同時，即使手動觸發(fā)AOF重寫，Redis也會在滿足一定條件時自動觸發(fā)AOF重寫，以保證AOF文件的大小和性能。

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

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

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

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

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

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

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持久化的時候，會先把命令寫入到AOF緩沖區(qū)，然后通過回寫策略來寫入硬盤AOF文件。

AOF相關(guān)配置

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

1. appendonly：該配置項用于開啟或關(guān)閉 AOF，默認(rèn)為關(guān)閉。若開啟了 AOF，Redis 會在每次執(zhí)行寫命令時，將命令追加到 AOF 文件末尾。
2. appendfilename：用于設(shè)置 AOF 文件名，默認(rèn)為 appendonly.aof。
3. appendfsync：該配置項用于設(shè)置 AOF 的同步機制。有三種可選值： always：表示每個寫命令都要同步到磁盤，安全性最高，但是性能較差。everysec：表示每秒同步一次，是默認(rèn)選項，既能保證數(shù)據(jù)安全，又具有較好的性能。no：表示不進(jìn)行同步，而是由操作系統(tǒng)決定何時將緩沖區(qū)中的數(shù)據(jù)同步到磁盤上，性能最好，但是安全性較低。
4. auto-aof-rewrite-percentage和auto-aof-rewrite-min-size：這兩個配置項用于設(shè)置 AOF 重寫規(guī)則。當(dāng) AOF 文件大小超過 auto-aof-rewrite-min-size 設(shè)置的值，并且 AOF 文件增長率達(dá)到 auto-aof-rewrite-percentage 所定義的百分比時，Redis 會啟動 AOF 重寫操作。auto-aof-rewrite-percentage：默認(rèn)值為100，以及auto-aof-rewrite-min-size：64mb 配置，也就是說默認(rèn)Redis會記錄上次重寫時的AOF大小，默認(rèn)配置是當(dāng)AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發(fā)。
5. aof-use-rdb-preamble：Redis 4版本新特性，混合持久化。AOF重寫期間是否開啟增量式同步，該配置項在AOF重寫期間是否使用RDB文件內(nèi)容。默認(rèn)是no，如果設(shè)置為yes，在AOF文件頭加入一個RDB文件的內(nèi)容，可以盡可能的減小AOF文件大小，同時也方便恢復(fù)數(shù)據(jù)。

寫后日志

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

why？

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

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

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

不過，AOF 也有兩個潛在的風(fēng)險。

首先，如果剛執(zhí)行完一個命令，還沒有來得及記日志就宕機了，那么這個命令和相應(yīng)的數(shù)據(jù)就有丟失的風(fēng)險。如果此時 Redis 是用作緩存，還可以從后端數(shù)據(jù)庫重新讀入數(shù)據(jù)進(jìn)行恢復(fù)，但是，如果 Redis 是直接用作數(shù)據(jù)庫的話，此時，因為命令沒有記入日志，所以就無法用日志進(jìn)行恢復(fù)了。

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

混合持久化

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

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

為了讓用戶能夠同時擁有上述兩種持久化的優(yōu)點， Redis 4.0 推出了一個“魚和熊掌兼得”的持久化方案 —— RDB-AOF 混合持久化： 這種持久化能夠通過 AOF 重寫操作創(chuàng)建出一個同時包含 RDB 數(shù)據(jù)和 AOF 數(shù)據(jù)的 AOF 文件， 其中 RDB 數(shù)據(jù)位于 AOF 文件的開頭， 它們儲存了服務(wù)器開始執(zhí)行重寫操作時的數(shù)據(jù)庫狀態(tài)。至于那些在重寫操作執(zhí)行之后執(zhí)行的 Redis 命令， 則會繼續(xù)以 AOF 格式追加到 AOF 文件的末尾， 也即是 RDB 數(shù)據(jù)之后。

說就是說開啟混合持久化之后，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 選項的值設(shè)置為 true。

appendonly yes
aof-use-rdb-preamble yes

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

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

1. 數(shù)據(jù)的實時性和一致性：如果您對數(shù)據(jù)的實時性和一致性有很高的要求，則AOF可能是更好的選擇。
2. 如果您對數(shù)據(jù)的實時性和一致性要求不太高，并且希望能快速地加載數(shù)據(jù)并減少磁盤空間的使用，那么RDB就可能更適合您的應(yīng)用程序。因為RDB文件是二進(jìn)制格式的，所以它很緊湊，并且在Redis重啟時可以迅速地加載數(shù)據(jù)。
3. Redis的性能需求：如果您對Redis的性能有很高的要求，那么關(guān)閉持久化功能也是一個選擇。因為持久化功能可能會影響Redis的性能，但是一般不建議這么做。 總結(jié)

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

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

最新評論