Redis持久化之RDB與AOF 的區別

Redis 持久化

Redis絕大部分情況都是當做緩存來使用，因為它把后端數據庫中的數據存儲在內存中，再直接從內存中讀取數據，響應速度會非常快

但是有一個不可忽略的問題，一旦服務器宕機，內存中的數據將會全部丟失

我們很容易想到的解決方案是，從后端數據庫恢復這些數據，但是這種方式存在兩個問題

一個是，需要頻繁訪問數據庫，會給數據庫帶來巨大的壓力

另外，這些數據是從慢速數據庫中讀取出來的，性能肯定比不上從Redis中讀取，導致使用這些數據的應用程序響應也會隨之變慢

所以，對於Redis來說，實現數據的持久化，避免從后端數據庫中進行恢復是至關重要的

目前，Redis的持久化主要有兩大機制

• AOF日志

• RDB 快照

我們先來說說 AOF 日志

AOF日志是如何實現的

說到日志，我們比較熟悉的是數據庫的寫前日志，也就是說，在實際寫數據前，先把修改的數據記到日志文件中，以便故障時進行恢復。

不過，AOF日志正好相反，它是寫后日志，如下圖所示

Redis首先是先執行命令，把數據寫入內存，然后才記錄日志，AOF為什么要先執行命令再記日志呢？

要想知道這個問題的答案，我們要先知道AOF里記錄了什么內容。

AOF里記錄的是Redis收到的每一條命令，這些命令是以文本形式保存的。

我們以Redis收到 set testkey testvalue命令后記錄的日志為例，看看AOF日志的內容。

其中，“*3”表示當前命令有三個部分，每部分都是由“$+數字”開頭，后面緊跟着具體的命令、鍵或值。

這里，“數字”表示這部分中的命令、鍵或值一共有多少字節。例如，“$3 set”表示這部分有3個字節，也就是“set”命令。

但是，為了避免額外的檢查開銷，Redis在向AOF里面記錄日志的時候，並不會先去對這些命令進行語法檢查。

所以，如果先記日志再執行命令的話，日志中就有可能記錄了錯誤的命令，Redis在使用日志恢復數據時，就可能會出錯。

而寫后日志這種方式，就是先讓系統執行命令，只有命令能執行成功，才會被記錄到日志中，否則，系統就會直接向客戶端報錯。

所以，Redis使用寫后日志這一方式的一大好處是，可以避免出現記錄錯誤命令的情況。

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

不過，AOF也有兩個潛在的風險。

首先，如果剛執行完一個命令，還沒有來得及記錄日志就宕機了，那么這個命令和相應的數據就有丟失的風險。

如果此時Redis是用作緩存，還可以從后端數據庫重新讀入數據進行恢復，但是，如果Redis是直接用作數據庫的話，此時，因為命令沒有記入日志，所以就無法用日志進行恢復了。

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

仔細分析的話就會發現，這兩個風險都是和AOF寫回磁盤的時機相關的。

這也就意味着，如果我們能夠控制一個寫命令執行完后AOF日志寫回磁盤的時機，這兩個風險就解除了

三種寫回策略

其實，對於這個問題，AOF機制給我們提供了三個選擇，也就是AOF配置項 appendfsync 的三個可選值。

• Always，同步寫回：每個寫命令執行完，立馬同步地將日志寫回磁盤；
• Everysec，每秒寫回：每個寫命令執行完，只是先把日志寫到AOF文件的內存緩沖區，每隔一秒把緩沖區中的內容寫入磁盤；
• No，操作系統控制的寫回：每個寫命令執行完，只是先把日志寫到AOF文件的內存緩沖區，由操作系統決定何時將緩沖區內容寫回磁盤。

針對避免主線程阻塞和減少數據丟失的問題，這三種寫回策略都無法做到兩全其美。

我們來分析下其中的原因：

• “同步寫回”可以做到基本不丟數據，但是它在每一個寫命令后都有一個慢速的落盤操作，不可避免地會影響主線程性能；
• 雖然“操作系統控制的寫回”在寫完緩沖區后，就可以繼續執行后續的命令，但是落盤的時機已經不在Redis手中了，只要AOF記錄沒有寫回磁盤，一旦宕機對應的數據就丟失了；
• “每秒寫回”采用一秒寫回一次的頻率，避免了“同步寫回”的性能開銷，雖然減少了對系統性能的影響，但是如果發生宕機，上一秒內未落盤的命令操作仍然會丟失。所以，這只能算是，在避免影響主線程性能和避免數據丟失兩者間取了個折中。

到這里，我們就可以根據系統對高性能和高可靠性的要求，來選擇使用哪種寫回策略了。

總結一下：想要獲得高性能，就選擇No策略；如果想要得到高可靠性的保證，就選擇Always策略；如果允許數據有一點丟失，又希望性能別受太大影響的話，那么就選擇Everysec策略。

但是，按照系統的性能需求選定了寫回策略，並不是“高枕無憂”了。畢竟，AOF是以文件的形式在記錄接收到的所有寫命令。隨着接收的寫命令越來越多，AOF文件會越來越大。這也就意味着，我們一定要小心AOF文件過大帶來的性能問題。

這里的“性能問題”，主要在於以下三個方面

• 文件系統本身對文件大小有限制，無法保存過大的文件

• 如果文件太大，之后再往里面追加命令記錄的話，效率也會變低

• 如果發生宕機，AOF中記錄的命令要一個個被重新執行，用於故障恢復，如果日志文件太大，整個恢復過程就會非常緩慢，這就會影響到Redis的正常使用。

所以，我們就要采取一定的控制手段，這個時候，AOF重寫機制就登場了。

日志文件太大了怎么辦

簡單來說，AOF重寫機制就是在重寫時，Redis根據數據庫的現狀，創建一個新的AOF文件，也就是說，讀取數據庫中的所有鍵值對，然后對每一個鍵值對用一條命令記錄它的寫入。

比如說，當讀取了鍵值對testkey: testvalue之后，重寫機制會記錄set testkey testvalue這條命令。這樣，當需要恢復時，可以重新執行該命令，實現testkey: testvalue的寫入。

為什么重寫機制可以把日志文件變小呢?

實際上，重寫機制具有“多變一”功能。所謂的“多變一”，也就是說，舊日志文件中的多條命令，在重寫后的新日志中變成了一條命令。我們知道，AOF文件是以追加的方式，逐一記錄接收到的寫命令的。當一個鍵值對被多條寫命令反復修改時，AOF文件會記錄相應的多條命令。但是，在重寫的時候，是根據這個鍵值對當前的最新狀態為它生成對應的寫入命令。

這樣一來，一個鍵值對在重寫日志中只用一條命令就行了，而且，在日志恢復時，只用執行這條命令，就可以直接完成這個鍵值對的寫入了。如下圖所示

當我們對一個列表先后做了6次修改操作后，列表的最后狀態是[“D”, “C”, “N”]，此時，只用LPUSH u:list “N”, “C”, "D"這一條命令，就能實現該數據的恢復，這就節省了五條命令的空間。

對於被修改過成百上千次的鍵值對來說，重寫能節省的空間當然就更大了。不過，雖然AOF重寫后，日志文件會縮小，但是，要把整個數據庫的最新數據的操作日志都寫回磁盤，仍然是一個非常耗時的過程。

這時，我們就要繼續關注另一個問題了：重寫會不會阻塞主線程？

AOF 重寫會阻塞嗎？

和AOF日志由主線程寫回不同，重寫過程是由后台線程 bgrewriteaof 來完成的，這也是為了避免阻塞主線程，導致數據庫性能下降。

我把重寫的過程總結為“一個拷貝，兩處日志”。如下圖所示

一個拷貝 就是指，每次執行重寫時，主線程 fork 出后台的 bgrewriteaof 子進程。

此時，fork會把主線程的內存拷貝一份，給 bgrewriteaof 子進程，這里面就包含了數據庫的最新數據。然后，bgrewriteaof 子進程就可以在不影響主線程的情況下，逐一把拷貝的數據寫成操作，記入重寫日志。

兩處日志 是指 因為主線程未阻塞，仍然可以處理新來的操作。

此時，如果有寫操作，第一處日志就是指正在使用的AOF日志，Redis會把這個操作寫到它的緩沖區。這樣一來，即使宕機了，這個AOF日志的操作仍然是齊全的，可以用於恢復。

而第二處日志，就是指新的AOF重寫日志。這個操作也會被寫到重寫日志的緩沖區。這樣，重寫日志也不會丟失最新的操作。等到拷貝數據的所有操作記錄重寫完成以后，重寫日志記錄的這些最新操作，也會寫入新的AOF文件以保證數據庫最新狀態的記錄。此時，我們就可以用新的AOF文件替代舊文件了。

總結來說，每次AOF重寫時，Redis會先執行一個內存拷貝，用於重寫；然后，使用兩個日志保證在重寫過程中，新寫入的數據不會丟失。而且，因為Redis采用額外的線程進行數據重寫，所以，這個過程並不會阻塞主線程。所以說，AOF這個方法的好處，是每次執行只需要記錄操作命令，需要持久化的數據量不大。一般而言，只要采用的不是always的持久化策略，就不會對性能造成太大影響。

但是，也正因為記錄的是操作命令，而不是實際的數據，所以，用AOF方法進行故障恢復的時候，需要逐一把操作日志都執行一遍。

如果操作日志非常多，Redis就會恢復得很緩慢，影響到正常使用。這當然不是理想的結果。

那么，還有沒有既可以保證可靠性，還能在宕機時實現快速恢復的其他方法呢？

當然有了，這就是接下來要學習的另一種持久化方法：內存快照。

RDB 內存快照

所謂內存快照，就是指內存中的數據在某一個時刻的狀態記錄。這就類似於照片，當你給朋友拍照時，一張照片就能把朋友一瞬間的形象完全記下來。

對於Redis來說，它實現類似照片記錄效果的方式，就是把某一時刻的狀態以文件的形式寫到磁盤上，也就是快照。這樣一來，即使宕機，快照文件也不會丟失，數據的可靠性也就得到了保證。

這個快照文件就稱為RDB文件，其中，RDB就是Redis DataBase的縮寫。和AOF相比，RDB記錄的是某一時刻的數據，並不是操作，所以，在做數據恢復時，我們可以直接把RDB文件讀入內存，很快地完成恢復。

聽起來好像很不錯，但內存快照也並不是最優選項。為什么這么說呢？

我們還要考慮兩個關鍵問題：

• 對哪些數據做快照？這關系到快照的執行效率問題；
• 做快照時，數據還能被增刪改嗎？這關系到Redis是否被阻塞，能否同時正常處理請求。

這么說可能你還不太好理解，我還是拿拍照片來舉例子。

我們在拍照時，通常要關注兩個問題：

• 如何取景？也就是說，我們打算把哪些人、哪些物拍到照片中；
• 在按快門前，要記着提醒朋友不要亂動，否則拍出來的照片就模糊了。

你看，這兩個問題是不是非常重要呢？

那么，接下來，我們就來具體地聊一聊。

先說“取景”問題，也就是我們對哪些數據做快照。

給哪些數據做快照

Redis的數據都在內存中，為了提供所有數據的可靠性保證，它執行的是全量快照，也就是說，把內存中的所有數據都記錄到磁盤中，這就類似於給100個人拍合影，把每一個人都要拍進照片里。這樣做的好處是，一次性記錄了所有數據，一個都不少。

當你給一個人拍照時，只用協調一個人就夠了，但是，拍100人的大合影，卻需要協調100個人的位置、狀態等等，這當然會更費時費力。同樣，給內存的全量數據做快照，把它們全部寫入磁盤也會花費很多時間。而且，全量數據越多，RDB文件就越大，往磁盤上寫數據的時間開銷就越大。

對於Redis而言，它的單線程模型就決定了，我們要盡量避免所有會阻塞主線程的操作。所以，針對任何操作，我們都會提一個靈魂之問：“它會阻塞主線程嗎?”

RDB文件的生成是否會阻塞主線程，這就關系到是否會降低Redis的性能。Redis提供了兩個命令來生成RDB文件，分別是 save 和 bgsave 。

• save：是在主線程中執行，會導致阻塞；
• bgsave：創建一個子進程，專門用於寫入RDB文件，避免了主線程的阻塞，這也是Redis RDB文件生成的默認配置。

那么這個時候，我們就可以通過 bgsave 命令來執行全量快照，這既提供了數據的可靠性保證，也避免了對Redis的性能影響。

接下來，我們要關注的問題就是，在對內存數據做快照時，這些數據還能“動”嗎?

也就是說，這些數據還能被修改嗎？ 這個問題非常重要，這是因為，如果數據能被修改，那就意味着Redis還能正常處理寫操作。否則，所有寫操作都得等到快照完了才能執行，性能一下子就降低了。

快照時數據能修改嗎?

在給別人拍照時，一旦對方動了，那么這張照片就拍糊了，我們就需要重拍，所以我們當然希望對方保持不動。對於內存快照而言，我們也不希望數據“動”。

舉個例子。我們在時刻 t 給內存做快照，假設內存數據量是4GB，磁盤的寫入帶寬是0.2GB/s，簡單來說，至少需要20s（4/0.2 = 20）才能做完。如果在時刻t+5s時，一個還沒有被寫入磁盤的內存數據A，被修改成了A1，那么就會破壞快照的完整性，因為A1不是時刻 t 時的狀態。因此，和拍照類似，我們在做快照時也不希望數據“動”，也就是不能被修改。但是，如果快照執行期間數據不能被修改，是會有潛在問題的。

對於剛剛的例子來說，在做快照的20s時間里，如果這4GB的數據都不能被修改，Redis就不能處理對這些數據的寫操作，那無疑就會給業務服務造成巨大的影響。可能有人會想到可以用 bgsave 避免阻塞啊。

這里我就要說到一個常見的誤區了，避免阻塞和正常處理寫操作並不是一回事。

此時，主線程的確沒有阻塞，可以正常接收請求，但是，為了保證快照完整性，它只能處理讀操作，因為不能修改正在執行快照的數據。為了快照而暫停寫操作，肯定是不能接受的。

所以這個時候，Redis就會借助操作系統提供的寫時復制技術（Copy-On-Write, COW），在執行快照的同時，正常處理寫操作。簡單來說，bgsave子進程是由主線程 fork 生成的，可以共享主線程的所有內存數據。bgsave子進程運行后，開始讀取主線程的內存數據，並把它們寫入RDB文件。如下圖所示

此時，如果主線程對這些數據也都是讀操作，就是這個鍵值對A，那么，主線程和bgsave子進程相互不影響。但是，如果主線程要修改一塊數據（鍵值對C），那么，這塊數據就會被復制一份，生成該數據的副本。然后，bgsave子進程會把這個副本數據寫入RDB文件，而在這個過程中，主線程仍然可以直接修改原來的數據。這既保證了快照的完整性，也允許主線程同時對數據進行修改，避免了對正常業務的影響。

到這里，我們就解決了對“哪些數據做快照”以及“做快照時數據能否修改”這兩大問題。

Redis會使用 bgsave 對當前內存中的所有數據做快照，這個操作是子進程在后台完成的，這就允許主線程同時可以修改數據。

現在，我們再來看另一個問題，多久做一次快照？我們在拍照的時候，還有項技術叫“連拍”，可以記錄人或物連續多個瞬間的狀態。

那么，快照也適合“連拍”嗎？

可以每秒做一次快照嗎？

對於快照來說，所謂“連拍”就是指連續地做快照。這樣一來，快照的間隔時間變得很短，即使某一時刻發生宕機了，因為上一時刻快照剛執行，丟失的數據也不會太多。但是，這其中的快照間隔時間就很關鍵了。如下圖所示

我們先在T0時刻做了一次快照，然后又在 T0+t 時刻做了一次快照，在這期間，數據塊5和9被修改了。如果在 t 這段時間內，機器宕機了，那么，只能按照T0時刻的快照進行恢復。此時，數據塊5和9的修改值因為沒有快照記錄，就無法恢復了。

所以，要想盡可能恢復數據，t 值就要盡可能小，t越小，就越像“連拍”。那么，t值可以小到什么程度呢，比如說是不是可以每秒做一次快照？畢竟，每次快照都是由 bgsave 子進程在后台執行，也不會阻塞主線程。這種想法其實是錯誤的。

雖然bgsave執行時不阻塞主線程，但是，如果頻繁地執行全量快照，也會帶來兩方面的開銷。

一方面，頻繁將全量數據寫入磁盤，會給磁盤帶來很大壓力，多個快照競爭有限的磁盤帶寬，前一個快照還沒有做完，后一個又開始做了，容易造成惡性循環。

另一方面，bgsave 子進程需要通過fork操作，從主線程創建出來。

雖然，子進程在創建后，不會再阻塞主線程，但是，fork這個創建過程，本身會阻塞主線程，而且主線程的內存越大，阻塞時間越長。如果頻繁 fork 出 bgsave 子進程，這就會頻繁阻塞主線程了。那么，有什么其他好方法嗎？

此時，我們可以做增量快照，所謂增量快照，就是指，做了一次全量快照后，后續的快照只對修改的數據進行快照記錄，這樣可以避免每次全量快照的開銷。也就是說，在第一次做完全量快照后，T1和T2時刻如果再做快照，我們只需要將被修改的數據，寫入快照文件就可以了。但是，這么做的前提是，我們需要記住哪些數據被修改了。你可不要小瞧這個“記住”功能，它需要我們使用額外的元數據信息，去記錄哪些數據被修改了，這會帶來額外的空間開銷問題，如圖所示

如果我們對每一個鍵值對的修改，都做個記錄，那么，如果有1萬個被修改的鍵值對，我們就需要有1萬條額外的記錄。而且，有的時候鍵值對非常小，比如只有32字節，而記錄它被修改的元數據信息，可能就需要8字節。

這樣的話，為了“記住”修改，引入的額外空間開銷就會比較大。這對於內存資源寶貴的Redis來說，有些得不償失。

到這里，你可以發現，雖然跟AOF相比，快照的恢復速度快，但是，快照的頻率不好把握，如果頻率太低，兩次快照間一旦宕機，就可能有比較多的數據丟失。

如果頻率太高，又會產生額外開銷，那么，還有什么方法既能利用RDB的快速恢復，又能以較小的開銷做到盡量少丟數據呢？

Redis 4.0中提出了一個混合使用AOF日志和內存快照的方法。簡單來說，內存快照以一定的頻率執行，在兩次快照之間，使用AOF日志記錄這期間的所有命令操作。這樣一來，快照不用很頻繁地執行，這就避免了頻繁 fork 對主線程的影響。而且，AOF日志也只用記錄兩次快照間的操作，也就是說，不需要記錄所有操作了，因此，就不會出現文件過大的情況了，也可以避免重寫開銷。如圖所示

T1和T2時刻的修改，用AOF日志記錄，等到第二次做全量快照時，就可以清空AOF日志，因為此時的修改都已經記錄到快照中了，恢復時就不再用日志了。這個方法既能享受到RDB文件快速恢復的好處，又能享受到AOF只記錄操作命令的簡單優勢

持久化的具體操作

光說理論沒有用，接下來具體操作。先來看看快照的。

打開 redis.conf 配置文件，我們要找 SNAPSHOTTING ，這個單詞就是快照的意思

它的格式就是這樣的 save <senconds> <changes>

第一參數表示的是 指定時間間隔，第二個參數表示的是 執行指定次數的更新操作。滿足這兩個兩個條件，會把內存中的數據同步到硬盤中。

Redis中 默認 1個小時，也就是 3600 秒內有1個更改；或者 5分鍾，300百秒內，有100個更改；又或者 60 秒內 1萬次的更改。

也就是說 默認滿足這三個條件中的其中一個，就會將內存中的數據快照寫入磁盤中，如果不想用Redis 默認的，可以把注釋打開，自行修改。還有就是指定本地數據庫的文件名是什么，叫這個名字(dbfilename )，一般采用默認的。我們重新配置 save ，配置成 150 秒 3次

可以看到 3次 操作生成了 快照文件

接下來通過 RDB 恢復數據

• 首先備份 dump.rdb為 dump_bak.rdb(模擬線上環境)
• 接下來使用一個命令 flushall 清空數據(模擬數據丟失，這個地方要注意一下：flushall 也會觸發 rdb 持久化)
• 然后 將 dump_bak.rdb 替換 dump.rdb
• 重啟 redis 服務，恢復數據

[root@localhost bin]# cp dump.rdb dump_bak.rdb 
[root@localhost bin]# ./redis-cli
127.0.0.1:6379> flushall
48991:M 01 Nov 2021 01:01:55.827 * DB saved on disk
OK
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> shutdown
not connected> exit
[root@localhost bin]# cp dump_bak.rdb dump.rdb
cp: overwrite ‘dump.rdb’? y
[root@localhost bin]# ./redis-server redis.conf &
[root@localhost bin]# ./redis-cli 
127.0.0.1:6379> keys *
1) "testkey"
2) "hello"
127.0.0.1:6379> exit

這就是 RDB快照 的操作

接下來再來看下 AOF 是如何操作的

首先是在配置文件中，找到有關於 appendonly 有關的內容，AOF 默認是關閉的，我們需要把它打開，把 no 改為 yes，文件名就用默認的不改了，指定更新的日志的條件， 叫這個名字 appendfsync ，這三個配置剛才已經講過了，我們就用 always

還有一個是 配置重寫觸發機制是下面這兩個配置

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

這兩個配置的意思是，當AOF 文件的大小是上次 rewrite 后大小的一倍，且文件大於 64M時觸發。一般都是設置為 3G，因為64M太小了

接下來具體來操作，如何恢復數據的

• 首先執行 flushall，模擬數據丟失
• 重啟 redis 服務，恢復數據
• 緊接着 修改 appendonly.aof ，模擬文件異常
• 然后再重啟 redis ，服務啟動不起來，失敗了。同時也說明，RDB 和 AOF 可以同時存在，且優先加載 AOF 文件
• 這時候使用 redis-check-aof 校驗 appendonly.aof 文件
• 再重啟 Redis ，服務正常

根據這個流程來操作一下

創建模擬數據

[root@localhost bin]# ./redis-cli
127.0.0.1:6379> set hello codeman
OK
127.0.0.1:6379> exit

127.0.0.1:6379> shutdown
not connected> exit
[root@localhost bin]# cp dump_bak.rdb dump.rdb
cp: overwrite ‘dump.rdb’? y
[root@localhost bin]# ./redis-server redis.conf &
[root@localhost bin]# ./redis-cli 
127.0.0.1:6379> keys *
1) "testkey"
2) "hello"
127.0.0.1:6379> exit

模擬數據丟失

[root@localhost bin]# ./redis-cli
127.0.0.1:6379> flushall
127.0.0.1:6379> keys *
127.0.0.1:6379> shutdown
not connected> exit
[root@localhost bin]# ./redis-server redis.conf &
[root@localhost bin]# ./redis-cli 
127.0.0.1:6379> keys *
1) "testkey"
2) "hello"
127.0.0.1:6379> exit

這時候發現數據沒有恢復是個什么情況?

這里有一點要注意，當你使用 flushall 清空數據的時候，重啟 redis 服務，數據沒有恢復的話，是因為 flushall 命令，也被寫入到了 AOF 文件中，導致數據恢復失敗，這時候只需要刪除 aof 文件中的 flushall 就行了。

接下來我們再來模擬一下 AOF 文件異常，隨便在 AOF 文件中輸入一些數據，保存

啟動 Redis 服務，再連接 Redis

[root@localhost bin]# ./redis-server redis.conf &
[root@localhost bin]# ./redis-cli 

發現連接不上，這時候要去修復 AOF 文件，通過下面這個命令修復 AOF 文件

[root@localhost bin]# redis-check-aof --fix appendonly.aof

恢復了之后，再重新啟動Redis 服務，連接Redis ，查看數據是否恢復。

我們接下來再來看下 混合模式

當我們開啟了混合持久化時，啟動redis依然優先加載aof文件。

aof文件加載可能有兩種情況：

• aof文件開頭是rdb的格式, 先加載 rdb內容再加載剩余的 aof。

• aof文件開頭不是rdb的格式，直接以aof格式加載整個文件。

我們通過命令操作一下，通過bgrwriteaof完成

127.0.0.1:6379> set key1 value1
OK
127.0.0.1:6379> set key2 value2
OK
127.0.0.1:6379> bgrewriteaof
127.0.0.1:6379> set key3 value3
OK
127.0.0.1:6379> exit

此時的aof文件已經和只開啟AOF持久化文件不一樣了，一部分數據來自RDB文件，一部分來自Redis運行過程時的增量數據

這就是 混合模式

了解更多可掃碼關注公眾號