一、Redis的持久化

Redis是一個基于內(nèi)存的數(shù)據(jù)庫，它的數(shù)據(jù)是存放在內(nèi)存中，內(nèi)存有個問題就是關(guān)閉服務(wù)或者斷電會丟失。Redis的數(shù)據(jù)也支持寫到硬盤中，這個過程就叫做持久化。

Redis提供了2種不同形式的持久化方式：

• RDB（Redis DataBase） ：簡而言之，就是在指定的時間間隔內(nèi)，定時的將 redis 存儲的數(shù)據(jù)生成Snapshot快照并存儲到磁盤等介質(zhì)上；
• AOF（Append Of File） ：將 redis 執(zhí)行過的所有寫指令記錄下來，在下次 redis 重新啟動時，只要把這些寫指令從前到后再重復(fù)執(zhí)行一遍，就可以實現(xiàn)數(shù)據(jù)恢復(fù)了。

RDB（Redis DataBase）：redis備份默認方式

同時允許使用兩種方式： 其實 RDB 和 AOF 兩種方式也可以同時使用，在這種情況下，如果 redis 重啟的話，則會優(yōu)先采用 AOF 方式來進行數(shù)據(jù)恢復(fù)，這是因為 AOF 方式的數(shù)據(jù)恢復(fù)完整度更高。

可以選擇關(guān)閉持久化： 如果你沒有數(shù)據(jù)持久化的需求，也完全可以關(guān)閉 RDB 和 AOF 方式，這樣的話，redis 將變成一個純內(nèi)存數(shù)據(jù)庫，就像 memcache 一樣。

官網(wǎng)介紹：

https://redis.com.cn/redis-persistence.html

https://redis.com.cn/topics/persistence.html#redis

二、RDB（Redis DataBase）

1、RDB快照原理

我們知道 Redis 是單線程程序，這個線程要同時負責多個客戶端套接字的并發(fā)讀寫操作和內(nèi)存數(shù)據(jù)結(jié)構(gòu)的邏輯讀寫。

在服務(wù)線上請求的同時，Redis 還需要進行內(nèi)存快照，內(nèi)存快照要求 Redis 必須進行文件 IO 操作，這意味著單線程同時在服務(wù)線上的請求還要進行文件 IO 操作，文件 IO 操作會嚴重拖垮服務(wù)器請求的性能。還有個重要的問題是為了不阻塞線上的業(yè)務(wù)，就需要邊持久化邊響應(yīng)客戶端請求。持久化的同時，內(nèi)存數(shù)據(jù)結(jié)構(gòu)還在改變，比如一個大型的 hash 字典正在持久化，結(jié)果一個請求過來把它給刪掉了，還沒持久化完呢，這要怎么搞？

Redis 使用操作系統(tǒng)的多進程 COW(Copy On Write) 機制來實現(xiàn)快照持久化，這個機制很有意思，也很少人知道。多進程 COW 也是鑒定程序員知識廣度的一個重要指標。

fork(多進程)

Redis 在持久化時會調(diào)用 glibc 的函數(shù) fork 產(chǎn)生一個子進程，快照持久化完全交給子進程來處理，父進程繼續(xù)處理客戶端請求。子進程剛剛產(chǎn)生時，它和父進程共享內(nèi)存里面的代碼段和數(shù)據(jù)段。這時你可以將父子進程想像成一個連體嬰兒，共享身體。這是 Linux 操作系統(tǒng)的機制，為了節(jié)約內(nèi)存資源，所以盡可能讓它們共享起來。在進程分離的一瞬間，內(nèi)存的增長幾乎沒有明顯變化。

子進程做數(shù)據(jù)持久化，它不會修改現(xiàn)有的內(nèi)存數(shù)據(jù)結(jié)構(gòu)，它只是對數(shù)據(jù)結(jié)構(gòu)進行遍歷讀取，然后序列化寫到磁盤中。但是父進程不一樣，它必須持續(xù)服務(wù)客戶端請求，然后對內(nèi)存數(shù)據(jù)結(jié)構(gòu)進行不間斷的修改。

這個時候就會使用操作系統(tǒng)的 COW 機制來進行數(shù)據(jù)段頁面的分離。數(shù)據(jù)段是由很多操作系統(tǒng)的頁面組合而成，當父進程對其中一個頁面的數(shù)據(jù)進行修改時，會將被共享的頁面復(fù)制一份分離出來，然后對這個復(fù)制的頁面進行修改。這時子進程相應(yīng)的頁面是沒有變化的，還是進程產(chǎn)生時那一瞬間的數(shù)據(jù)。

隨著父進程修改操作的持續(xù)進行，越來越多的共享頁面被分離出來，內(nèi)存就會持續(xù)增長。但是也不會超過原有數(shù)據(jù)內(nèi)存的 2 倍大小。另外一個 Redis 實例里冷數(shù)據(jù)占的比例往往是比較高的，所以很少會出現(xiàn)所有的頁面都會被分離，被分離的往往只有其中一部分頁面。每個頁面的大小只有 4K，一個 Redis 實例里面一般都會有成千上萬的頁面。

子進程因為數(shù)據(jù)沒有變化，它能看到的內(nèi)存里的數(shù)據(jù)在進程產(chǎn)生的一瞬間就凝固了，再也不會改變，這也是為什么 Redis 的持久化叫「快照」的原因。接下來子進程就可以非常安心的遍歷數(shù)據(jù)了進行序列化寫磁盤了。

這里之需要需要通知父線程，是因為父線程要做個記錄，保留最后一次持久化的時間。

2、RDB配置

（1）指定備份文件的名稱

在redis.conf中，可以修改rdb備份文件的名稱，默認為dump.rdb，如下：

（2）指定備份文件存放的目錄

在redis.conf中，rdb文件的保存的目錄是可以修改的，默認為Redis啟動命令所在的目錄，如下

（3）觸發(fā)RDB備份

方式1：自動備份，需配置備份規(guī)則

可在redis.conf中配置自動備份的規(guī)則，默認規(guī)則如下：

save用來配置備份的規(guī)則

save的格式： save 秒鐘 寫操作次數(shù)

默認是1分鐘內(nèi)修改了1萬次，或5分鐘內(nèi)需修改了10次，或30分鐘內(nèi)修改了1次。

示例：設(shè)置20秒內(nèi)有最少有3次key發(fā)生變化，則進行備份

save 20 3

方式2：手動執(zhí)行命令備份（save | bgsave）

有2個命令可以觸發(fā)備份。

save：save時只管保存，其他不管，全部阻塞，手動保存，不建議使用。bgsave：redis會在后臺異步進行快照操作，快照同時還可以響應(yīng)客戶端情況。

可以通過 lastsave 命令獲取最后一次成功生成快照的時間（獲取到的是時間戳）。

方式3：flushall命令

執(zhí)行flushall命令，也會產(chǎn)生dump.rdb文件，但里面是空的，無意義。

（4）動態(tài)停止RDB： redis-cli config set save "" #save后給空值，表示禁用保存策略。

3、redis.conf 其他一些配置

（1）stop-writes-on-bgsave-error：當磁盤滿時，是否關(guān)閉redis的寫操作

stop-writes-on-bgsave-error用來指定當redis無法寫入磁盤的話，是否直接關(guān)掉redis的寫操作，
推薦yes。

（2）rdbcompression：rdb備份是否開啟壓縮

對于存儲到磁盤中的rdb快照文件，可以設(shè)置是否進行壓縮，如果是的話，redis會采用LZF算法進行壓縮。如果你不想消耗CPU來進行壓縮的話，可以設(shè)置為關(guān)閉此功能，推薦yes。

（3）rdbchecksum：是否檢查rdb備份文件的完整性

存儲快照后，還可以讓redis使用CRC64算法來進行數(shù)據(jù)校驗，但是這樣做會增加大約10%的性能消耗，如果希望獲取最大的性能提升，可以關(guān)閉此功能。
推薦yes。

4、RDB的備份恢復(fù)

（1）先通過CONFIG GET dir查詢rdb文件的目錄，這其實就是查的redis.conf文件當中通過dir設(shè)置的目錄

（2）停止Redis
（3）拷貝遷移的redis備份文件（dump.rdb）到CONFIG GET dir查詢出來的指定目錄下。

cp dump.rdb dump.rdb

（4）重新啟動redis服務(wù)

5、RDB優(yōu)缺點

優(yōu)勢：

• 適合大規(guī)模數(shù)據(jù)恢復(fù)
• 對數(shù)據(jù)完整性和一致性要求不高更適合使用
• 節(jié)省磁盤空間
• 基于二進制存儲的，恢復(fù)速度快

劣勢：

• Fork的時候，內(nèi)存中的數(shù)據(jù)會被克隆一份，大致2倍的膨脹，需要考慮
• 雖然Redis在fork的時候使用了寫時拷貝技術(shù)，但是如果數(shù)據(jù)龐大時還是比較消耗性能
• 在備份周期在一定間隔時間做一次備份，所以如果Redis意外down的話，就會丟失最后一次快照后所有修改

三、AOF（Append Of File）

1、AOF原理

AOF 日志存儲的是 Redis 服務(wù)器的順序指令序列，AOF 日志只記錄對內(nèi)存進行修改的指令記錄。

假設(shè) AOF 日志記錄了自 Redis 實例創(chuàng)建以來所有的修改性指令序列，那么就可以通過對一個空的 Redis 實例順序執(zhí)行所有的指令，也就是「重放」，來恢復(fù) Redis 當前實例的內(nèi)存數(shù)據(jù)結(jié)構(gòu)的狀態(tài)。

（1）寫入機制

Redis 在收到客戶端修改命令后，先進行相應(yīng)的校驗，如果沒問題，就立即將該命令存追加到 .aof 文件中，也就是先存到磁盤中，然后服務(wù)器再執(zhí)行命令。這樣就算遇到了突發(fā)的宕機情況情況，也只需將存儲到 .aof 文件中的命令，進行一次“命令重演”就可以恢復(fù)到宕機前的狀態(tài)。

（2）寫入緩存

在上述執(zhí)行過程中，有一個很重要的環(huán)節(jié)就是命令的寫入，這是一個 IO 操作。Redis 為了提升寫入效率，它不會將內(nèi)容直接寫入到磁盤中，而是將其放到一個內(nèi)存緩存區(qū)（buffer）中，等到緩存區(qū)被填滿時采用異步真正將緩存區(qū)中的內(nèi)容寫入到磁盤里。

這就意味著如果機器突然宕機，AOF 日志內(nèi)容可能還沒有來得及完全刷到磁盤中，這個時候就會出現(xiàn)日志丟失。那該怎么辦？

Redis 為數(shù)據(jù)的安全性考慮，同樣為 AOF 持久化提供了策略配置，打開 Redis 配置文件，如下圖所示：

上述配置策略說明如下：

• Always：服務(wù)器每寫入一個命令，就調(diào)用一次 fsync函數(shù)，將緩沖區(qū)里面的命令寫入到硬盤。這種模式下，服務(wù)器出現(xiàn)故障，也不會丟失任何已經(jīng)成功執(zhí)行的命令數(shù)據(jù)，但是其執(zhí)行速度較慢；
• Everysec（默認）：服務(wù)器每一秒調(diào)用一次 fsync 函數(shù)，將緩沖區(qū)里面的命令寫入到硬盤。這種模式下，服務(wù)器出現(xiàn)故障，最多只丟失一秒鐘內(nèi)的執(zhí)行的命令數(shù)據(jù)，通常都使用它作為 AOF 配置策略；
• No：服務(wù)器不主動調(diào)用 fsync 函數(shù)，由操作系統(tǒng)決定何時將緩沖區(qū)里面的命令寫入到硬盤。這種模式下，服務(wù)器遭遇意外停機時，丟失命令的數(shù)量是不確定的，所以這種策略，不確定性較大，不安全。

注意：Linux 系統(tǒng)的 fsync() 函數(shù)可以將指定文件的內(nèi)容從內(nèi)核緩存刷到硬盤中。

由于是 fsync 是磁盤 IO 操作，所以它很慢！如果 Redis 執(zhí)行一條指令就要 fsync 一次（Always），那么 Redis 高性能將嚴重受到影響。

在生產(chǎn)環(huán)境的服務(wù)器中，Redis 通常是每隔 1s 左右執(zhí)行一次 fsync 操作（ Everysec），這樣既保持了高性能，也讓數(shù)據(jù)盡可能的少丟失。最后一種策略（No），讓操作系統(tǒng)來決定何時將數(shù)據(jù)同步到磁盤，這種策略存在許多不確定性，所以不建議使用。

（3）重寫機制

Redis 在長期運行的過程中，aof 文件會越變越長。如果機器宕機重啟，“重演”整個 aof 文件會非常耗時，導(dǎo)致長時間 Redis 無法對外提供服務(wù)。因此就需要對 aof 文件做一下“瘦身”運動。

為了讓 aof 文件的大小控制在合理的范圍內(nèi)，Redis 提供了 AOF 重寫機制，手動執(zhí)行BGREWRITEAOF命令，開始重寫 aof 文件，如下所示：

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

通過 bgrewriteaof 操作后，服務(wù)器會生成一個新的 aof 文件，該文件具有以下特點：

• 新的 aof 文件記錄的數(shù)據(jù)庫數(shù)據(jù)和原 aof 文件記錄的數(shù)據(jù)庫數(shù)據(jù)完全一致；
• 新的 aof 文件會使用盡可能少的命令來記錄數(shù)據(jù)庫數(shù)據(jù)，因此新的 aof 文件的體積會小很多；
• AOF 重寫期間，服務(wù)器不會被阻塞，它可以正常處理客戶端發(fā)送的命令。
• 即使 Bgrewriteaof 執(zhí)行失敗，也不會有任何數(shù)據(jù)丟失，因為舊的 AOF 文件在 Bgrewriteaof 成功之前不會被修改

重寫機制AOF文件對比：

（4）自動觸發(fā)AOF重寫

Redis 為自動觸發(fā) AOF 重寫功能，提供了相應(yīng)的配置策略。如下所示：修改 Redis 配置文件，讓服務(wù)器自動執(zhí)行 BGREWRITEAOF 命令。

#默認配置項
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb #表示觸發(fā)AOF重寫的最小文件體積,大于或等于64MB自動觸發(fā)。

該配置項表示：觸發(fā)重寫所需要的 aof 文件體積百分比，只有當 aof 文件的增量大于 100% 時才進行重寫，也就是大一倍。比如，第一次重寫時文件大小為 64M，那么第二次觸發(fā)重寫的體積為 128M，第三次重寫為 256M，以此類推。如果將百分比值設(shè)置為 0 就表示關(guān)閉 AOF 自動重寫功能。

（5）整個下來運行流程如下：

客戶端的請求寫命令會被append追加到AOF緩沖區(qū)內(nèi)

AOF緩沖區(qū)會根據(jù)AOF持久化策略[always,everysec,no]將操作sync同步到磁盤的AOF文件中

AOF文件大小超過重寫策略或手動重寫時，會對AOF文件進行重寫（rewrite），壓縮AOF文件容量redis服務(wù)器重啟時，會重新load加載AOF文件中的寫操作達到數(shù)據(jù)恢復(fù)的目的

2、AOF配置

AOF默認不開啟，可以在 redis.conf 文件中對AOF進行配置開啟：

appendonly no # 是否開啟AOF，yes：開啟，no：不開啟，默認為no
appendfilename "appendonly.aof" # aof文件名稱，默認為appendonly.aof
dir ./ # aof文件所在目錄，默認./，表示執(zhí)行啟動命令時所在的目錄

3、AOF的備份恢復(fù)

AOF的備份機制和性能雖然和RDB不同，但是備份和恢復(fù)的操作同RDB一樣，都是拷貝備份文件，需要恢復(fù)時再拷貝到Redis工作目錄下，啟動系統(tǒng)即加載。

正常恢復(fù)

• 修改默認的appendonly no，改為yes
• 將有數(shù)據(jù)的aof文件復(fù)制一份保存到對應(yīng)的目錄（查看目錄：config get dir）
• 恢復(fù)：重啟redis然后重新加載

異?；謴?fù)

• 修改默認的appendonly no，改為yes
• 如遇到aof文件損壞，通過 redis-check-aof --fix appendonly.aof 進行恢復(fù)，appendonly.aof是文件名

4、重寫流程

• 手動執(zhí)行 bgrewriteaof命令觸發(fā)重寫，判斷是否當前有bgfsave或bgrewriteaof在運行，如果有，則等待該命令結(jié)束后再繼續(xù)執(zhí)行
• 主進程fork出子進程執(zhí)行重寫操作，保證主進程不會阻塞
• 子進程遍歷redis內(nèi)存中的數(shù)據(jù)到臨時文件，客戶端的寫請求同時寫入aof_buf緩沖區(qū)和aof_rewrite_buf重寫緩沖區(qū)保證原AOF文件完整性以及新AOF文件生成期間的新的數(shù)據(jù)修改動作不會丟失
• 子進程寫完新的AOF文件后，向主進程發(fā)送信號，父進程更新統(tǒng)計信息
• 主進程把aof_rewrite_buf中的數(shù)據(jù)寫入到新的AOF文件
• 使用新的AOF文件覆蓋舊的AOF文件，完成AOF重寫

no-appendfsync-on-rewrite：重寫時，不會執(zhí)行appendfsync操作

該參數(shù)表示在正在進行AOF重寫時不會將AOF緩沖區(qū)中的數(shù)據(jù)同步到舊的AOF文件磁盤，也就是說在進行AOF重寫的時候，如果此時有寫操作進來，此時寫操作的命令會放在aof_buf緩存中（內(nèi)存中），而不會將其追加到舊的AOF文件中，這么做是為了避免同時寫舊的AOF文件和新的AOF文件對磁盤產(chǎn)生的壓力。

• 默認是ON，表示關(guān)閉，即在AOF重寫時，會對AOF緩沖區(qū)中的數(shù)據(jù)做同步磁盤操作，這在很大程度上保證了數(shù)據(jù)的安全性。但是遇到重寫操作，可能會發(fā)生阻塞。（數(shù)據(jù)安全，但是性能降低）
• 如果no-appendfsync-on-rewrite為yes，不寫入aof文件，只寫入緩存，用戶請求不會阻塞，但是在這段時間如果宕機會丟失這段時間的緩存數(shù)據(jù)。（降低數(shù)據(jù)安全性，提高性能）

但在數(shù)據(jù)量很大的場景，因為兩者都會消耗磁盤IO，對磁盤的影響較大，可以將其設(shè)置為“yes”減輕磁盤壓力，但在極端情況下可能丟失整個AOF重寫期間的數(shù)據(jù)。

5、AOF優(yōu)缺點

優(yōu)勢：

• 備份機制更穩(wěn)健，丟失數(shù)據(jù)概率更低
• 可讀的日志文本，通過操作AOF文件，可以處理誤操作

劣勢：

• 比RDB占用更多的磁盤空間
• 恢復(fù)備份速度要慢
• 每次讀寫都同步的話，有一定的性能壓力
• 存在個別bug，造成不能恢復(fù)

總結(jié)：

• AOF文件是一個只進行追加的日志文件
• Redis可以在AOF文件體積變得過大時，自動地在后臺對AOF文件進行重寫
• AOF文件有序地保存了對數(shù)據(jù)庫執(zhí)行的所有寫入操作，這些寫入操作以redis協(xié)議的格式保存，因此AOF文件的內(nèi)容非常容易被人讀懂，對文件進行分析也很輕松。
• 對于相同的數(shù)據(jù)集來說，AOF文件的體積通常要大于RDB文件的體積
• 根據(jù)所使用的fsync策略，AOF的速度可能會慢于RDB

四、AOF和RDB對比

官方推薦2個都啟用。
如果對數(shù)據(jù)不敏感，可以單獨用RDB。
不建議單獨使用AOF，因為可能會出現(xiàn)BUG。
如果只是做純內(nèi)存緩存，可以都不用。

五、AOF和RDB官網(wǎng)建議

• RDB持久化方式能夠在指定的時間間隔對你的數(shù)據(jù)進行快照存儲
• AOF持久化方式記錄每次對服務(wù)器寫的操作，當服務(wù)器重啟的時候會重新執(zhí)行這些命令來恢復(fù)原始數(shù)據(jù)，AOF命令以redis協(xié)議追加保存每次寫的操作到AOF文件末尾
• Redis還能對AOF文件進行后臺重寫，使得AOF文件的體積不至于過大
• 只做緩存：如果你只希望你的數(shù)據(jù)在服務(wù)器運行的時候存在，你也可以不使用任何持久化方式
• 同時開啟兩種持久化方式：在這種情況下，當redis重啟的時候會優(yōu)先載入AOF文件來恢復(fù)原始的數(shù)據(jù)，因為在通常情況下AOF文件保存的數(shù)據(jù)集要比RDB文件保存的數(shù)據(jù)集要完整
• RDB的數(shù)據(jù)不實時，同時使用兩者時服務(wù)器重啟也只會找AOF文件，那要是只用AOF呢？
• 建議不要，因為RDB更適合用于備份數(shù)據(jù)庫，快速重啟，而且不會有AOF可能潛在的bug，留著作為一個萬一的手段
• 性能建議
  • 因為RDB文件只用作后備用途，建議只在Slave上持久化RDB文件，而且只要15分鐘備份一次就夠了，只保留 save 900 1 這一條
  • 如果使用AOF，好處是在最惡劣的情況下也只會丟失不超過兩秒數(shù)據(jù)，啟動腳本較簡單只load自己的AOF文件就可以了
  • AOF的代價，一是帶來持續(xù)的IO，二是AOF rewrite的最后將rewrite過程中產(chǎn)生的新數(shù)據(jù)（aof_rewrite_buf）寫到文件造成的阻塞幾乎是不可避免的
  • 只要硬盤許可，應(yīng)該盡量減少AOF rewrite的頻率，AOF重寫的基數(shù)大小默認值64M（autoaof-rewrite-min-size）太小了，可以設(shè)置到5G以上
  • 默認超過原大小100%（auto-aof-rewrite-percentage）大小時重寫可以改到適當?shù)臄?shù)值。

通常 Redis 的主節(jié)點是不會進行持久化操作，持久化操作主要在從節(jié)點進行。從節(jié)點是備份節(jié)點，沒有來自客戶端請求的壓力，它的操作系統(tǒng)資源往往比較充沛。

但是如果出現(xiàn)網(wǎng)絡(luò)分區(qū)，從節(jié)點長期連不上主節(jié)點，就會出現(xiàn)數(shù)據(jù)不一致的問題，特別是在網(wǎng)絡(luò)分區(qū)出現(xiàn)的情況下又不小心主節(jié)點宕機了，那么數(shù)據(jù)就會丟失，所以在生產(chǎn)環(huán)境要做好實時監(jiān)控工作，保證網(wǎng)絡(luò)暢通或者能快速修復(fù)。另外還應(yīng)該再增加一個從節(jié)點以降低網(wǎng)絡(luò)分區(qū)的概率，只要有一個從節(jié)點數(shù)據(jù)同步正常，數(shù)據(jù)也就不會輕易丟失。

六、Redis 4.0 混合持久化

1、混合持久化原理

重啟 Redis 時，我們很少使用 rdb 來恢復(fù)內(nèi)存狀態(tài)，因為會丟失大量數(shù)據(jù)。我們通常使用 AOF 日志重放，但是重放 AOF 日志性能相對 rdb 來說要慢很多，這樣在 Redis 實例很大的情況下，啟動需要花費很長的時間。

Redis 4.0 為了解決這個問題，帶來了一個新的持久化選項——混合持久化。將 rdb 文件的內(nèi)容和增量的 AOF 日志文件存在一起。這里的 AOF 日志不再是全量的日志，而是自持久化開始到持久化結(jié)束的這段時間發(fā)生的增量 AOF 日志，通常這部分 AOF 日志很小。

于是在 Redis 重啟的時候，可以先加載 rdb 的內(nèi)容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重啟效率因此大幅得到提升。

混合持久化的加載流程如下：

2、混合持久化配置

在redis的配置文件當中有一個aof-use-rdb-preamble參數(shù)來開啟 混合持久化，默認是yes開啟的。混合持久化結(jié)合了 RDB 和 AOF 的優(yōu)點，Redis 5.0 默認是開啟的。

3、混合持久化優(yōu)缺點

優(yōu)點：

• 混合持久化結(jié)合了 RDB 和 AOF 持久化的優(yōu)點，開頭為 RDB 的格式，使得 Redis 可以更快的啟動，同時結(jié)合 AOF的優(yōu)點，有減低了大量數(shù)據(jù)丟失的風險。

缺點：

• AOF 文件中添加了 RDB 格式的內(nèi)容，使得 AOF 文件的可讀性變得很差；
• 兼容性差，如果開啟混合持久化，那么此混合持久化 AOF 文件，就不能用在 Redis 4.0 之前版本了。

以上就是Redis的持久化詳解的詳細內(nèi)容，更多關(guān)于Redis 持久化的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論