之前咱們更新了Redis的基礎架構和簡單原理應用，希望給大家一個由淺及深的學習思路，今天，我們就來介紹Redis的持久化方案實現。
Redis支持RDB與AOF兩種持久化機制，持久化可以避免因進程異常退出或down機導致的數據丟失問題，在下次重啓時能利用之前的持久化文件實現數據恢復。
RDB持久化
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持久化
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文件，完成新舊文件的替換
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 vs AOF
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以上版本的混合持久化方式）來進行持久化，保證數據的安全性。
以上就是小編整理的Redis持久化方案，只是個人的一點見解，有哪裏不準確的地方，還請各位大佬多多指出，咱們共同進步。有喜歡小編的朋友，請轉發並關注小編，你們的支持就是小編最大的動力~~~