Redis 持久化方案

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

Redis支援RDB與AOF兩種持久化機制，持久化可以避免因程式異常退出或down機導致的資料丟失問題，在下次重啟時能利用之前的持久化檔案實現資料恢復。

RDB持久化即透過建立快照（壓縮的二進位制檔案）的方式進行持久化，儲存某個時間點的全量資料。RDB持久化是Redis預設的持久化方式。RDB持久化的觸發包括手動觸發與自動觸發兩種方式。

save， 在 行執行save ，將以同步的方式建立rdb檔案儲存快照，會阻塞伺服器的主程式，生產環境中不要用
bgsave, 在命令列執行bgsave命令，將透過fork一個子程式以非同步的方式建立rdb檔案儲存快照，除了fork時有阻塞，子程式在建立rdb檔案時，主程式可繼續處理請求

在redis.conf中配置 save m n 定時觸發，如 save 900 1表示在900s內至少存在一次更新就觸發
主從複製時，如果從節點執行全量複製操作，主節點自動執行bgsave生成RDB檔案併傳送給從節點
執行debug reload命令重新載入Redis時
執行shutdown且沒有開啟AOF持久化
redis.conf中RDB持久化配置

# 只要滿足下列條件之一，則會執行bgsave命令
save 900 1 # 在900s記憶體在至少一次寫操作
save 300 10
save 60 10000
# 禁用RBD持久化，可在最後加 save ""
# 當備份程式出錯時主程式是否停止寫入操作
stop-writes-on-bgsave-error yes
# 是否壓縮rdb檔案 推薦no 相對於硬碟成本cpu資源更貴
rdbcompression no

AOF（Append-Only-File）持久化即記錄所有變更資料庫狀態的指令，以append的形式追加儲存到AOF檔案中。在伺服器下次啟動時，就可以透過載入和執行AOF檔案中儲存的命令，來還原伺服器關閉前的資料庫狀態。

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

# 預設關閉AOF，若要開啟將no改為yes
appendonly no
# append檔案的名字
appendfilename "appendonly.aof"
# 每隔一秒將快取區內容寫入檔案 預設開啟的寫入方式
appendfsync everysec
# 當AOF檔案大小的增長率大於該配置項時自動開啟重寫（這裡指超過原大小的100%）。
auto-aof-rewrite-percentage 100
# 當AOF檔案大小大於該配置項時自動開啟重寫
auto-aof-rewrite-min-size 64mb

AOF持久化的實現包括3個步驟:

命令追加：將命令追加到AOF緩衝區
檔案寫入：緩衝區內容寫到AOF檔案
檔案儲存：AOF檔案儲存到磁碟
其中後兩步的頻率透過appendfsync來配置，appendfsync的選項包括

always， 每執行一個命令就儲存一次，安全性最高，最多隻丟失一個命令的資料，但是效能也最低（頻繁的磁碟IO）
everysec，每一秒儲存一次，推薦使用，在安全性與效能之間折中，最多丟失一秒的資料
no， 依賴作業系統來執行（一般大概30s一次的樣子），安全性最低，效能最高，丟失作業系統最後一次對AOF檔案觸發SAVE操作之後的資料
AOF透過儲存命令來持久化，隨著時間的推移，AOF檔案會越來越大，Redis透過AOF檔案重寫來解決AOF檔案不斷增大的問題（可以減少檔案的磁碟佔有量，加快資料恢復的速度），原理如下：

呼叫fork，建立一個子程式

子程式讀取當前資料庫的狀態來“重寫”一個新的AOF檔案（這裡雖然叫“重寫”，但實際並沒有對舊檔案進行任何讀取，而是根據資料庫的當前狀態來形成指令）

主程式持續將新的變動同時寫到AOF重寫緩衝區與原來的AOF緩衝區中

主程式獲取到子程式重寫AOF完成的訊號，呼叫訊號處理函式將AOF重寫緩衝區內容寫入新的AOF檔案中，並對新檔案進行重新命名，原子地覆蓋原有AOF檔案，完成新舊檔案的替換

手動觸發： 直接呼叫bgrewriteaof命令
自動觸發： 根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage引數確定自動觸發時機。其中auto-aof-rewrite-min-size表示執行AOF重寫時檔案最小體積，預設為64MB。auto-aof-rewrite-percentage表示當前AOF檔案大小（aof_current_size）和上一次重寫後AOF檔案大小（aof_base_size）的比值。自動觸發時機為 aof_current_size > auto-aof-rewrite-min-size &&（aof_current_size - aof_base_size）/aof_base_size> = auto-aof-rewrite-percentage

RDB與AOF兩種方式各有優缺點。

RDB的優點：與AOF相比，RDB檔案相對較小，恢復資料比較快（原因見資料恢復部分）
RDB的缺點：伺服器當機，RBD方式會丟失掉上一次RDB持久化後的資料；使用bgsave fork子程式時會耗費記憶體。
AOF的優點： AOF只是追加檔案，對伺服器效能影響較小，速度比RDB快，消耗記憶體也少，同時可讀性高。
AOF的缺點：生成的檔案相對較大，即使透過AOF重寫，仍然會比較大；恢復資料的速度比RDB慢。
資料庫的恢復

伺服器啟動時，如果沒有開啟AOF持久化功能，則會自動載入RDB檔案，期間會阻塞主程式。如果開啟了AOF持久化功能，伺服器則會優先使用AOF檔案來還原資料庫狀態，因為AOF檔案的更新頻率通常比RDB檔案的更新頻率高，儲存的資料更完整。

redis資料庫恢復的處理流程如下，

在資料恢復方面，RDB的啟動時間會更短，原因有兩個：

RDB 檔案中每一條資料只有一條記錄，不會像AOF日誌那樣可能有一條資料的多次操作記錄。所以每條資料只需要寫一次就行了，檔案相對較小。

RDB 檔案的儲存格式和Redis資料在記憶體中的編碼格式是一致的，不需要再進行資料編碼工作，所以在CPU消耗上要遠小於AOF日誌的載入。

但是在進行RDB持久化時，fork出來進行dump操作的子程式會佔用與父程式一樣的記憶體，採用的copy-on-write機制，對效能的影響和記憶體的消耗都是比較大的。比如16G記憶體，Redis已經使用了10G，這時save的話會再生成10G，變成20G，大於系統的16G。這時候會發生交換，要是虛擬記憶體不夠則會崩潰，導致資料丟失。所以在用redis的時候一定對系統記憶體做好容量規劃。

RDB、AOF混合持久化

Redis從4.0版開始支援RDB與AOF的混合持久化方案。首先由RDB定期完成記憶體快照的備份，然後再由AOF完成兩次RDB之間的資料備份，由這兩部分共同構成持久化檔案。該方案的優點是充分利用了RDB載入快、備份檔案小及AOF儘可能不丟資料的特性。缺點是相容性差，一旦開啟了混合持久化，在4.0之前的版本都不識別該持久化檔案，同時由於前部分是RDB格式，閱讀性較低。

開啟混合持久化

aof-use-rdb-preamble yes

資料恢復載入過程就是先按照RDB進行載入，然後把AOF命令追加寫入。

持久化方案的建議
如果Redis只是用來做快取伺服器，比如資料庫查詢資料後快取，那可以不用考慮持久化，因為快取服務失效還能再從資料庫獲取恢復。
如果你要想提供很高的資料保障性，那麼建議你同時使用兩種持久化方式。如果你可以接受災難帶來的幾分鐘的資料丟失，那麼可以僅使用RDB。
通常的設計思路是利用主從複製機制來彌補持久化時效能上的影響。即Master上RDB、AOF都不做，保證Master的讀寫效能，而Slave上則同時開啟RDB和AOF（或4.0以上版本的混合持久化方式）來進行持久化，保證資料的安全性。

原文地址：