什么是Redis持久化？

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

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

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

RDB快照

rdb是Redis DataBase縮寫。

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

RBD持久化通過(guò)保存數(shù)據(jù)庫(kù)中的鍵值對(duì)來(lái)記錄數(shù)據(jù)庫(kù)狀態(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個(gè)選項(xiàng)都屏蔽，則rdb禁用)
stop-writes-on-bgsave-error yes  // 后臺(tái)備份進(jìn)程出錯(cuò)時(shí),主進(jìn)程是否停止寫入
rdbcompression yes    // 導(dǎo)出的rdb文件是否壓縮。建議沒(méi)有必要開啟，畢竟Redis本身就屬于CPU密集型服務(wù)器，再開啟壓縮會(huì)帶來(lái)更多的CPU消耗，相比硬盤成本，CPU更值錢。
rdbchecksum   yes //  導(dǎo)入rbd恢復(fù)數(shù)據(jù)時(shí)，是否驗(yàn)證rdb的完整性
dbfilename dump.rdb  //導(dǎo)出來(lái)的rdb文件名
dir ./  //rdb的放置路徑

RDB原理

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

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

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

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

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

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

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

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

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

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

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

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

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

AOF

Aof是Append-only file縮寫。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

下面來(lái)看看重寫的一個(gè)流程圖：

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

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

Aof 的配置

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

AOF和RDB比較

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

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

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

最新評(píng)論