一、Redis的持久化

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

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

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

RDB（Redis DataBase）：redis備份默認(rèn)方式

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

可以選擇關(guān)閉持久化： 如果你沒有數(shù)據(jù)持久化的需求，也完全可以關(guān)閉 RDB 和 AOF 方式，這樣的話，redis 將變成一個(gè)純內(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 是單線程程序，這個(gè)線程要同時(shí)負(fù)責(zé)多個(gè)客戶端套接字的并發(fā)讀寫操作和內(nèi)存數(shù)據(jù)結(jié)構(gòu)的邏輯讀寫。

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

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

fork(多進(jìn)程)

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

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

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

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

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

這里之需要需要通知父線程，是因?yàn)楦妇€程要做個(gè)記錄，保留最后一次持久化的時(shí)間。

2、RDB配置

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

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

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

在redis.conf中，rdb文件的保存的目錄是可以修改的，默認(rèn)為Redis啟動(dòng)命令所在的目錄，如下

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

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

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

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

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

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

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

save 20 3

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

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

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

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

方式3：flushall命令

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

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

3、redis.conf 其他一些配置

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

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

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

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

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

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

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

（1）先通過CONFIG GET dir查詢r(jià)db文件的目錄，這其實(shí)就是查的redis.conf文件當(dāng)中通過dir設(shè)置的目錄

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

cp dump.rdb dump.rdb

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

5、RDB優(yōu)缺點(diǎn)

優(yōu)勢(shì)：

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

劣勢(shì)：

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

三、AOF（Append Of File）

1、AOF原理

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

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

（1）寫入機(jī)制

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

（2）寫入緩存

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

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

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

上述配置策略說明如下：

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

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

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

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

（3）重寫機(jī)制

Redis 在長(zhǎng)期運(yùn)行的過程中，aof 文件會(huì)越變?cè)介L(zhǎng)。如果機(jī)器宕機(jī)重啟，“重演”整個(gè) aof 文件會(huì)非常耗時(shí)，導(dǎo)致長(zhǎng)時(shí)間 Redis 無法對(duì)外提供服務(wù)。因此就需要對(duì) aof 文件做一下“瘦身”運(yùn)動(dòng)。

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

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

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

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

重寫機(jī)制AOF文件對(duì)比：

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

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

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

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

（5）整個(gè)下來運(yùn)行流程如下：

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

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

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

2、AOF配置

AOF默認(rèn)不開啟，可以在 redis.conf 文件中對(duì)AOF進(jìn)行配置開啟：

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

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

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

正?；謴?fù)

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

異常恢復(fù)

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

4、重寫流程

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

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

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

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

但在數(shù)據(jù)量很大的場(chǎng)景，因?yàn)閮烧叨紩?huì)消耗磁盤IO，對(duì)磁盤的影響較大，可以將其設(shè)置為“yes”減輕磁盤壓力，但在極端情況下可能丟失整個(gè)AOF重寫期間的數(shù)據(jù)。

5、AOF優(yōu)缺點(diǎn)

優(yōu)勢(shì)：

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

劣勢(shì)：

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

總結(jié)：

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

四、AOF和RDB對(duì)比

官方推薦2個(gè)都啟用。
如果對(duì)數(shù)據(jù)不敏感，可以單獨(dú)用RDB。
不建議單獨(dú)使用AOF，因?yàn)榭赡軙?huì)出現(xiàn)BUG。
如果只是做純內(nèi)存緩存，可以都不用。

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

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

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

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

六、Redis 4.0 混合持久化

1、混合持久化原理

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

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

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

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

2、混合持久化配置

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

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

優(yōu)點(diǎn)：

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

缺點(diǎn)：

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

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