快捷導(dǎo)航

Redis的持久化方案詳解

更新時間：2020年03月12日 09:43:59 作者：【空山新雨】

在本篇文章里小編給大家整理的是關(guān)于Redis的持久化方案詳解，有興趣的朋友們可以參考下。

Redis支持RDB與AOF兩種持久化機制，持久化可以避免因進程異常退出或down機導(dǎo)致的數(shù)據(jù)丟失問題，在下次重啟時能利用之前的持久化文件實現(xiàn)數(shù)據(jù)恢復(fù)。

RDB持久化

RDB持久化即通過創(chuàng)建快照（壓縮的二進制文件）的方式進行持久化，保存某個時間點的全量數(shù)據(jù)。RDB持久化是Redis默認的持久化方式。RDB持久化的觸發(fā)包括手動觸發(fā)與自動觸發(fā)兩種方式。

手動觸發(fā)

save，在命令行執(zhí)行save命令，將以同步的方式創(chuàng)建rdb文件保存快照，會阻塞服務(wù)器的主進程，生產(chǎn)環(huán)境中不要用
bgsave, 在命令行執(zhí)行bgsave命令，將通過fork一個子進程以異步的方式創(chuàng)建rdb文件保存快照，除了fork時有阻塞，子進程在創(chuàng)建rdb文件時，主進程可繼續(xù)處理請求

自動觸發(fā)

在redis.conf中配置 save m n 定時觸發(fā)，如 save 900 1表示在900s內(nèi)至少存在一次更新就觸發(fā)
主從復(fù)制時，如果從節(jié)點執(zhí)行全量復(fù)制操作，主節(jié)點自動執(zhí)行bgsave生成RDB文件并發(fā)送給從節(jié)點
執(zhí)行debug reload命令重新加載Redis時
執(zhí)行shutdown且沒有開啟AOF持久化
redis.conf中RDB持久化配置

# 只要滿足下列條件之一，則會執(zhí)行bgsave命令
save 900 1 # 在900s內(nèi)存在至少一次寫操作
save 300 10
save 60 10000
# 禁用RBD持久化，可在最后加 save ""

# 當備份進程出錯時主進程是否停止寫入操作
stop-writes-on-bgsave-error yes
# 是否壓縮rdb文件推薦no 相對于硬盤成本cpu資源更貴
rdbcompression no

AOF持久化

AOF（Append-Only-File）持久化即記錄所有變更數(shù)據(jù)庫狀態(tài)的指令，以append的形式追加保存到AOF文件中。在服務(wù)器下次啟動時，就可以通過載入和執(zhí)行AOF文件中保存的命令，來還原服務(wù)器關(guān)閉前的數(shù)據(jù)庫狀態(tài)。

redis.conf中AOF持久化配置如下

# 默認關(guān)閉AOF，若要開啟將no改為yes
appendonly no

# append文件的名字
appendfilename "appendonly.aof"

# 每隔一秒將緩存區(qū)內(nèi)容寫入文件默認開啟的寫入方式
appendfsync everysec

# 當AOF文件大小的增長率大于該配置項時自動開啟重寫（這里指超過原大小的100%）。
auto-aof-rewrite-percentage 100

# 當AOF文件大小大于該配置項時自動開啟重寫
auto-aof-rewrite-min-size 64mb

AOF持久化的實現(xiàn)包括3個步驟:

命令追加：將命令追加到AOF緩沖區(qū)
文件寫入：緩沖區(qū)內(nèi)容寫到AOF文件
文件保存：AOF文件保存到磁盤

其中后兩步的頻率通過appendfsync來配置，appendfsync的選項包括

always，每執(zhí)行一個命令就保存一次，安全性最高，最多只丟失一個命令的數(shù)據(jù)，但是性能也最低（頻繁的磁盤IO）
everysec，每一秒保存一次，推薦使用，在安全性與性能之間折中，最多丟失一秒的數(shù)據(jù)
no，依賴操作系統(tǒng)來執(zhí)行（一般大概30s一次的樣子），安全性最低，性能最高，丟失操作系統(tǒng)最后一次對AOF文件觸發(fā)SAVE操作之后的數(shù)據(jù)

AOF通過保存命令來持久化，隨著時間的推移，AOF文件會越來越大，Redis通過AOF文件重寫來解決AOF文件不斷增大的問題（可以減少文件的磁盤占有量，加快數(shù)據(jù)恢復(fù)的速度），原理如下：

調(diào)用fork，創(chuàng)建一個子進程

子進程讀取當前數(shù)據(jù)庫的狀態(tài)來“重寫”一個新的AOF文件（這里雖然叫“重寫”，但實際并沒有對舊文件進行任何讀取，而是根據(jù)數(shù)據(jù)庫的當前狀態(tài)來形成指令）

主進程持續(xù)將新的變動同時寫到AOF重寫緩沖區(qū)與原來的AOF緩沖區(qū)中

主進程獲取到子進程重寫AOF完成的信號，調(diào)用信號處理函數(shù)將AOF重寫緩沖區(qū)內(nèi)容寫入新的AOF文件中，并對新文件進行重命名，原子地覆蓋原有AOF文件，完成新舊文件的替換

AOF的重寫也分為手動觸發(fā)與自動觸發(fā)

手動觸發(fā)：直接調(diào)用bgrewriteaof命令
自動觸發(fā)：根據(jù)auto-aof-rewrite-min-size和auto-aof-rewrite-percentage參數(shù)確定自動觸發(fā)時機。其中auto-aof-rewrite-min-size表示運行AOF重寫時文件最小體積，默認為64MB。auto-aof-rewrite-percentage表示當前AOF文件大?。╝of_current_size）和上一次重寫后AOF文件大?。╝of_base_size）的比值。自動觸發(fā)時機為 aof_current_size > auto-aof-rewrite-min-size &&（aof_current_size - aof_base_size）/aof_base_size> = auto-aof-rewrite-percentage

RDB vs AOF

RDB與AOF兩種方式各有優(yōu)缺點。

RDB的優(yōu)點：與AOF相比，RDB文件相對較小，恢復(fù)數(shù)據(jù)比較快（原因見數(shù)據(jù)恢復(fù)部分）
RDB的缺點：服務(wù)器宕機，RBD方式會丟失掉上一次RDB持久化后的數(shù)據(jù)；使用bgsave fork子進程時會耗費內(nèi)存。
AOF的優(yōu)點： AOF只是追加文件，對服務(wù)器性能影響較小，速度比RDB快，消耗內(nèi)存也少，同時可讀性高。
AOF的缺點：生成的文件相對較大，即使通過AOF重寫，仍然會比較大；恢復(fù)數(shù)據(jù)的速度比RDB慢。

數(shù)據(jù)庫的恢復(fù)

服務(wù)器啟動時，如果沒有開啟AOF持久化功能，則會自動載入RDB文件，期間會阻塞主進程。如果開啟了AOF持久化功能，服務(wù)器則會優(yōu)先使用AOF文件來還原數(shù)據(jù)庫狀態(tài)，因為AOF文件的更新頻率通常比RDB文件的更新頻率高，保存的數(shù)據(jù)更完整。

redis數(shù)據(jù)庫恢復(fù)的處理流程如下，

在數(shù)據(jù)恢復(fù)方面，RDB的啟動時間會更短，原因有兩個：

RDB 文件中每一條數(shù)據(jù)只有一條記錄，不會像AOF日志那樣可能有一條數(shù)據(jù)的多次操作記錄。所以每條數(shù)據(jù)只需要寫一次就行了，文件相對較小。

RDB 文件的存儲格式和Redis數(shù)據(jù)在內(nèi)存中的編碼格式是一致的，不需要再進行數(shù)據(jù)編碼工作，所以在CPU消耗上要遠小于AOF日志的加載。

但是在進行RDB持久化時，fork出來進行dump操作的子進程會占用與父進程一樣的內(nèi)存，采用的copy-on-write機制，對性能的影響和內(nèi)存的消耗都是比較大的。比如16G內(nèi)存，Redis已經(jīng)使用了10G，這時save的話會再生成10G，變成20G，大于系統(tǒng)的16G。這時候會發(fā)生交換，要是虛擬內(nèi)存不夠則會崩潰，導(dǎo)致數(shù)據(jù)丟失。所以在用redis的時候一定對系統(tǒng)內(nèi)存做好容量規(guī)劃。

RDB、AOF混合持久化

Redis從4.0版開始支持RDB與AOF的混合持久化方案。首先由RDB定期完成內(nèi)存快照的備份，然后再由AOF完成兩次RDB之間的數(shù)據(jù)備份，由這兩部分共同構(gòu)成持久化文件。該方案的優(yōu)點是充分利用了RDB加載快、備份文件小及AOF盡可能不丟數(shù)據(jù)的特性。缺點是兼容性差，一旦開啟了混合持久化，在4.0之前的版本都不識別該持久化文件，同時由于前部分是RDB格式，閱讀性較低。

開啟混合持久化