Redis系列五：持久化

持久化簡介

場景
在寫文檔的時候，很多人都會遇到斷電或者電腦意外死機的狀況，等重啓電腦後電腦一般會有個備份文件，打開備份文件就可以恢復到文檔最近的編輯狀態。這是MS爲我們做的持久化。

什麼是持久化

利用永久性存儲介質將數據進行保存，在特定的時間將保存的數據進行恢復的工作機制稱爲持久化。

爲什麼要進行持久化

防止數據的意外丟失，確保數據安全性

持久化過程保存什麼

將當前數據狀態進行保存，快照形式，存儲數據結構，存儲格式簡單，關注點在數據。
將數據的操作過程進行保存，日誌形式，存儲操作過程，存儲格式複雜，關注點在數據的操作過程。

虛擬機的快照爲第一種方式，在寫文檔的時候我們撤銷操作，返回上一步爲第二種方式。

RDB

RDB採用的存儲策略是以快照形式存儲數據。

RDB啓動方式————save指令

命令

save

作用
手動執行一次保存操作

save指令的相關配置

dbfilename dump.rdb
設置保存的本地數據庫名，默認爲dump.rdb。通常設置爲dump-端口號.rdb
dir
設置.rdb文件的路徑，一般戶放在較大的存儲空間中，目錄名稱設置爲data。
rdbcompression yes
設置存儲到本地時是否壓縮，默認爲yes.可以節省空間
rdbchecksum yes
設置是否進行RDB校驗，默認爲yes，會增加讀寫時間消耗。

注意：redis是單線程的，save指令會阻塞當前Redis服務器，知道當前RDB過程完成爲止，可能會造成長時間的阻塞，線上環境不建議使用。如何避免這個問題？採用後臺執行save指令

RDB啓動方式————bgsave指令

命令

bgsave

作用
手動啓動後臺保存操作，但是不是立即執行

注意：bgsave命令是最save阻塞問題的優化。redis內部所有涉及到RDB操作都採用bgsave的方式，save命令可以放棄使用

bgsave指令相關配置

dbfilename dump-端口號.rdb
dir
rdbcompression yes
rdbchecksum yes
stop-writes-on-bgsave-error yes
後臺存儲過程中如果出現錯誤現象，是否停止保存操作。通常默認爲開啓狀態

反覆執行保存指令，忘記了怎麼辦？

RGB啓動方式————save配置

配置

save second changes

作用
滿足限定時間範圍內key的變化數量達到指定數量時進行持久化
參數
- second:監控時間範圍
- changes：監控key的變化量
位置
在conf文件中進行配置
示例

save 900 1
save 300 10
save 60  10000

注意：

save配置根據實際業務情況進行設置，頻度過高或者過低都會出現性能問題
second和changes設置通常具有互補關係，儘量不要設置成包含關係。例如1s1次和100s100次，就沒有太大意義
save配置後執行的是bgsave操作

RDB三種啓動方式對比

save配置和bgsave指令是同一種性質，因此在此比較save和bgsave指令

RDB的優缺點

RDB優點

RDB存儲效率高，它是一個緊湊壓縮的二進制文件
基於某個時間點的數據快照，非常適用於數據備份，全量複製等場景
RDB恢復數據的速度比AOF快很多

RDB缺點

無法實時持久化，會丟數據
bgsave每次運行要執行fork操作創建子進程，要犧牲性能
Redis各個版本中RDB文件格式未統一，可能出現各版本服務之間的數據格式無法兼容

AOF

AOF採用的過程日誌的方式存儲數據。

AOF(append only file)持久化：以獨立日誌的方式記錄每次寫命令，重啓時再重新執行AOF文件中命令達到恢復數據的目的。與RDB相比可以簡單描述爲改記錄數據爲記錄數據產生的過程。
AOF主要作用解決了數據持久化的實時性，目前是Redis持久化的主流方式。

AOF寫數據的過程

先將寫命令刷新在緩存區中，當滿足條件後將命令同步到AOF文件中。

AOF寫數據的三種策略

always
每次寫入操作均同步到AOF文件中，數據零誤差，性能較低。
everysec

每秒將緩衝區指令同步到AOF文件中，數據準確性較高，性能較高。推薦，也是默認配置
宕機的時候回丟失1s內的數據
no
由操作系統控制，過程不可控。

AOF功能開啓

配置

appendonly yes|no

作用
是否開啓AOF持久化功能，默認不開啓，開始時優先級高於RBD
配置

appendfsync always|everysec|no

作用
AOF寫策略

AOF相關配置

配置

appendfilename filename

作用
AOF持久化文件名，默認爲appendonly.aof，建議爲appendonly-端口號.aof
配置

dir

作用
AOF持久化保存路徑，與RDB文件同位置即可。

AOF寫數據時遇到的問題

如果連續執行如下指令

在備份恢復的時候，會執行三次set name操作，但最終的結果只是得到ww，前兩次的set操作是無效的。

AOF重寫

命令的不斷寫入，AOF文件會越來越大。爲了壓縮AOF文件體積，AOF重寫是將redis進程內的數據轉化爲寫命令同步到新AOF文件的過程。簡單說就是將對同一個數據的若干條命令執行結果轉化爲最終結果數據對應的指令進行記錄。

AOF重寫作用

降低磁盤佔用量，提高磁盤的利用率
提高持久化效率，降低持久化寫時間，提高IO性能
降低數據恢復時，提高數據恢復效率

AOF重寫規則

進程內已超時的數據不再寫入文件
忽略無效指令，只保留最終數據的寫入命令
對同一數據的多寫命令合併爲一條命令

lpush list1 a、lpush alist1 b、 lpush alist c可以轉化爲 lpush list1 a b c

AOF重寫方式

手動重寫

bgrewriteaof

自動重寫

auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage  percentage

自動重寫觸發比對參數（運行指令info Persistence獲取具體信息）

aof_current_size
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 VS AOF

如何選擇RDB與AOF

對數據非常敏感，建議使用默認的AOF方案
數據呈現階段有效性，使用RDB持久化方案
綜合對比
- 不能承受數分鐘以內的數據丟失，對數據非常敏感，使用AOF
- 可以承受數據的部分丟失，且追求大數據集的恢復速度，選用RDB
- 災難恢復選用RDB