什么是Redis持久化？

redis是一種內(nèi)存數(shù)據(jù)庫。持久化就是把內(nèi)存的數(shù)據(jù)寫到磁盤中去，防止服務(wù)宕機(jī)了內(nèi)存數(shù)據(jù)丟失。

Redis提供了兩種持久化策略: RDB（默認(rèn)） 和AOF 。

RDB是指在指定的時間間隔內(nèi)，把內(nèi)存中的數(shù)據(jù)集快照寫入磁盤。也就是只保留某個時間點(diǎn)的數(shù)據(jù)。
而AOF持久化會記錄服務(wù)器接收的所有寫操作命令，并且把這些命令追加到一個文件里面，持久化到磁盤上，在服務(wù)器啟動的時候，通過重新執(zhí)行這些命令來還原數(shù)據(jù)。

RDB快照

rdb是Redis DataBase縮寫。

功能核心函數(shù)rdbSave(生成RDB文件)和rdbLoad（從文件加載內(nèi)存）兩個函數(shù)。

RBD持久化通過保存數(shù)據(jù)庫中的鍵值對來記錄數(shù)據(jù)庫狀態(tài)。

RBD配置文件的開啟

save 900 1      // 900s內(nèi),有1條寫入,則產(chǎn)生快照
save 300 1000   // 如果300秒內(nèi)有1000次寫入,則產(chǎn)生快照
save 60 10000  // 如果60秒內(nèi)有10000次寫入,則產(chǎn)生快照
(這3個選項(xiàng)都屏蔽，則rdb禁用)
stop-writes-on-bgsave-error yes  // 后臺備份進(jìn)程出錯時,主進(jìn)程是否停止寫入
rdbcompression yes    // 導(dǎo)出的rdb文件是否壓縮。建議沒有必要開啟，畢竟Redis本身就屬于CPU密集型服務(wù)器，再開啟壓縮會帶來更多的CPU消耗，相比硬盤成本，CPU更值錢。
rdbchecksum   yes //  導(dǎo)入rbd恢復(fù)數(shù)據(jù)時，是否驗(yàn)證rdb的完整性
dbfilename dump.rdb  //導(dǎo)出來的rdb文件名
dir ./  //rdb的放置路徑

RDB原理

針對RDB方式的持久化，手動觸發(fā)可以使用：

save：會阻塞當(dāng)前Redis服務(wù)器，直到持久化完成，線上應(yīng)該禁止使用。

bgsave：該觸發(fā)方式會fork一個子進(jìn)程，由子進(jìn)程負(fù)責(zé)持久化過程，因此阻塞只會發(fā)生在fork子進(jìn)程的時候。

而自動觸發(fā)的場景主要是有以下幾點(diǎn)：

• 根據(jù)我們的 save m n 配置規(guī)則自動觸發(fā)；
• 從節(jié)點(diǎn)全量復(fù)制時，主節(jié)點(diǎn)發(fā)送rdb文件給從節(jié)點(diǎn)完成復(fù)制操作，主節(jié)點(diǎn)會觸發(fā) bgsave；
• 執(zhí)行 debug reload 時；
• 執(zhí)行 shutdown時，如果沒有開啟aof，也會觸發(fā)。

由于 save 基本不會被使用到，我們重點(diǎn)看看 bgsave 這個命令是如何完成RDB的持久化的。

這里注意的是 fork 操作會阻塞，導(dǎo)致Redis讀寫性能下降。我們可以控制單個Redis實(shí)例的最大內(nèi)存，來盡可能降低Redis在fork時的事件消耗。以及上面提到的自動觸發(fā)的頻率減少fork次數(shù)，或者使用手動觸發(fā)，根據(jù)自己的機(jī)制來完成持久化。

BGSAVE命令執(zhí)行時的服務(wù)器狀態(tài)

首先,在BGSAVE命令執(zhí)行期間,客戶端發(fā)送的SAVE命令會被服務(wù)器拒絕,服務(wù)器禁止SAVE命令和BGSAVE命令同時執(zhí)行是為了避免父進(jìn)程(服務(wù)器進(jìn)程)和子進(jìn)程同時執(zhí)行兩個rdbSave調(diào)用,防止產(chǎn)生競爭條件。

其次,在BGSAVE命令執(zhí)行期間,客戶端發(fā)送的BGSAVE命令會被服務(wù)器拒絕,因?yàn)橥瑫r執(zhí)行兩個BGSAVE命令也會產(chǎn)生競爭條件。

最后, BGREWRITEAOF和BGSAVE兩個命令不能同時執(zhí)行:

• 如果BGSAVE命令正在執(zhí)行,那么客戶端發(fā)送的BGREWRITEAOF命令會被延遲到BGSAVE命令執(zhí)行完畢之后執(zhí)行。
• 如果BGREWRITEAOF命令正在執(zhí)行,那么客戶端發(fā)送的BGSAVE命令會被服務(wù)器拒絕。

因?yàn)锽GREWRITEAOF和BGSAVE兩個命令的實(shí)際工作都由子進(jìn)程執(zhí)行,所以這兩個命令在操作方面并沒有什么沖突的地方,不能同時執(zhí)行它們只是一個性能方面的考慮-并
發(fā)出兩個子進(jìn)程,并且這兩個子進(jìn)程都同時執(zhí)行大量的磁盤寫入操作,這怎么想都不會是一個好主意。

AOF

Aof是Append-only file縮寫。

AOF持久化通過保存redis服務(wù)器所執(zhí)行的寫命令來記錄數(shù)據(jù)庫狀態(tài)。

AOF持久化的實(shí)現(xiàn)：

AOF持久化可分為命令追加、文件寫入、文件同步三個步驟。

從持久化中恢復(fù)數(shù)據(jù)

RDB文件的載入工作是在服務(wù)器啟動時自動執(zhí)行的,所以Redis并沒有專門用于載入RDB文件的命令,只要Redis服務(wù)器在啟動時檢測到RDB文件存在,它就會自動載入RDB文件。

服務(wù)器在載入RDB文件期間，會一直處于阻塞狀態(tài) ，直到載入完成。

另外值得一提的是,因?yàn)锳OF文件的更新頻率通常比RDB文件的更新頻率高, 保存的數(shù)據(jù)更完整，AOF基本上最多損失1s的數(shù)據(jù)。所以:

• 如果服務(wù)器開啟了AOF持久化功能,那么服務(wù)器會優(yōu)先使用AOF文件來還原數(shù)據(jù)陣狀態(tài)。
• 只有在AOF持久化功能處于關(guān)閉狀態(tài)時,服務(wù)器才會使用RDB文件來還原數(shù)據(jù)庫狀態(tài)。

每當(dāng)執(zhí)行服務(wù)器(定時)任務(wù)或者函數(shù)時flushAppendOnlyFile 函數(shù)都會被調(diào)用， 這個函數(shù)執(zhí)行以下兩個工作
aof寫入保存：

WRITE：根據(jù)條件，將 aof\_buf 中的緩存寫入到 AOF 文件

SAVE：根據(jù)條件，調(diào)用 fsync 或 fdatasync 函數(shù)，將 AOF 文件保存到磁盤中。

那么這里為什么要先寫入buf在同步到磁盤呢？如果實(shí)時寫入磁盤會帶來非常高的磁盤IO，影響整體性能。

aof重寫是為了減少aof文件的大小，可以手動或者自動觸發(fā)

手動觸發(fā)： bgrewriteaof，自動觸發(fā) 就是根據(jù)配置規(guī)則來觸發(fā)，當(dāng)然自動觸發(fā)的整體時間還跟Redis的定時任務(wù)頻率有關(guān)系。

下面來看看重寫的一個流程圖：

對于上圖有四個關(guān)鍵點(diǎn)補(bǔ)充一下：

• 在重寫期間，由于主進(jìn)程依然在響應(yīng)命令，為了保證最終備份的完整性；因此它依然會寫入舊的AOF file中，如果重寫失敗，能夠保證數(shù)據(jù)不丟失。
• 為了把重寫期間響應(yīng)的寫入信息也寫入到新的文件中，因此也會為子進(jìn)程保留一個buf，防止新寫的file丟失數(shù)據(jù)。
• 重寫是直接把當(dāng)前內(nèi)存的數(shù)據(jù)生成對應(yīng)命令，并不需要讀取老的AOF文件進(jìn)行分析、命令合并。
• AOF文件直接采用的文本協(xié)議，主要是兼容性好、追加方便、可讀性高可認(rèn)為修改修復(fù)。
• 不管是RDB還是AOF都是先寫入一個臨時文件，然后通過 rename 完成文件的替換工作。

Aof 的配置

appendonly no # 是否打開 aof日志功能
# 文件名稱
appendfilename "appendonly.aof"
appendfsync always   # 每1個命令,都立即同步到aof. 安全,速度慢
#appendfsync everysec # 折衷方案,每秒寫1次
#appendfsync no      # 寫入工作交給操作系統(tǒng),由操作系統(tǒng)判斷緩沖區(qū)大小,統(tǒng)一寫入到aof. 同步頻率低,速度快,
no-appendfsync-on-rewrite  yes: # 正在導(dǎo)出rdb快照的過程中，是否停止同步aof
auto-aof-rewrite-percentage 100 #aof文件大小比起上次重寫時的大小,增長率100%時,重寫
auto-aof-rewrite-min-size 64mb #aof文件,至少超過64M時,才重寫

AOF和RDB比較

• aof文件比rdb更新頻率高，優(yōu)先使用aof還原數(shù)據(jù)。—— 更加穩(wěn)定，數(shù)據(jù)的完整性更好。
• aof比rdb更安全也更大。—— 記錄了每一個寫操作，但是隨著文件越來越大，可能會影響到redis的寫性能。
• rdb性能比aof好：恢復(fù)大數(shù)據(jù)集的速度比AOF快，對CPU和內(nèi)存的影響比較小。更加適用于需要做冷備份或者對數(shù)據(jù)恢復(fù)要求不高的場景，因?yàn)樗情g隔一段時間進(jìn)行持久化。如果在這個時間斷內(nèi)發(fā)生宕機(jī)，那么這些數(shù)據(jù)就會丟失。
• 如果兩個都配了優(yōu)先加載AOF。
• AOF適用于對數(shù)據(jù)安全性較高的場景，比如購物車/訂單等關(guān)鍵性業(yè)務(wù)。

定時任務(wù)執(zhí)行的頻率可以在配置文件中通過 hz 10 來設(shè)置（這個配置表示1s內(nèi)執(zhí)行10次，也就是每100ms觸發(fā)一次定時任務(wù)）。該值最大能夠設(shè)置為：500，但是不建議超過：100，因?yàn)橹翟酱笳f明執(zhí)行頻率越頻繁越高，這會帶來CPU的更多消耗，從而影響主進(jìn)程讀寫性能。
定時任務(wù)使用的是Redis自己實(shí)現(xiàn)的 TimeEvent，它會定時去調(diào)用一些命令完成定時任務(wù)，這些任務(wù)可能會阻塞主進(jìn)程導(dǎo)致Redis性能下降。因此我們在配置Redis時，一定要整體考慮一些會觸發(fā)定時任務(wù)的配置，根據(jù)實(shí)際情況進(jìn)行調(diào)整。

以上就是redis持久化AOF和RDB的區(qū)別及解決各個場景問題示例的詳細(xì)內(nèi)容，更多關(guān)于redis持久化AOF RDB的資料請關(guān)注腳本之家其它相關(guān)文章！