什么是Redis持久化？

redis是一種內存數據庫。持久化就是把內存的數據寫到磁盤中去，防止服務宕機了內存數據丟失。

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

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

RDB快照

rdb是Redis DataBase縮寫。

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

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

RBD配置文件的開啟

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

RDB原理

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

save：會阻塞當前Redis服務器，直到持久化完成，線上應該禁止使用。

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

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

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

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

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

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

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

其次,在BGSAVE命令執(zhí)行期間,客戶端發(fā)送的BGSAVE命令會被服務器拒絕,因為同時執(zhí)行兩個BGSAVE命令也會產生競爭條件。

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

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

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

AOF

Aof是Append-only file縮寫。

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

AOF持久化的實現：

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

從持久化中恢復數據

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

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

另外值得一提的是,因為AOF文件的更新頻率通常比RDB文件的更新頻率高, 保存的數據更完整，AOF基本上最多損失1s的數據。所以:

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

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

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

SAVE：根據條件，調用 fsync 或 fdatasync 函數，將 AOF 文件保存到磁盤中。

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

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

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

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

對于上圖有四個關鍵點補充一下：

• 在重寫期間，由于主進程依然在響應命令，為了保證最終備份的完整性；因此它依然會寫入舊的AOF file中，如果重寫失敗，能夠保證數據不丟失。
• 為了把重寫期間響應的寫入信息也寫入到新的文件中，因此也會為子進程保留一個buf，防止新寫的file丟失數據。
• 重寫是直接把當前內存的數據生成對應命令，并不需要讀取老的AOF文件進行分析、命令合并。
• AOF文件直接采用的文本協議，主要是兼容性好、追加方便、可讀性高可認為修改修復。
• 不管是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: # 正在導出rdb快照的過程中，是否停止同步aof
auto-aof-rewrite-percentage 100 #aof文件大小比起上次重寫時的大小,增長率100%時,重寫
auto-aof-rewrite-min-size 64mb #aof文件,至少超過64M時,才重寫

AOF和RDB比較

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

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

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

最新評論