一、Redis持久化原因:Redis是內存數據庫，數據都是存放到內存中的，如突然宕機，數據就會丟失，因此必須有一種機制來保證redis在內存中的數據不會 丟失，這種機制就叫redis持久化機制。
二、支持的持久化有如下幾種：
RDB（Redis 數據庫）：RDB 持久性以指定的時間間隔執行數據集的時間點快照(把某一時刻的狀態到磁盤以文件的形式進行全量備份)。
AOF（僅追加文件）：AOF 持久性記錄服務器接收到的每個寫操作。然后可以在服務器啟動時再次重播這些操作，從而重建原始數據集。命令使用與 Redis 協議本身相同的格式進行記錄。
RDB + AOF：還可在同一個實例中組合 AOF 和 RDB
三、RDB是Redis DataBase 的縮寫，中文名為快照/內存快照，RDB持久化是把當前進程數據生成快照保存到磁盤上的過程，由于是某一時刻的快照，那么快照中的值要早于或者等于內存中的值。
1、默認情況下，Redis 將數據集的快照保存在磁盤上名為 dump.rdb 的二進制文件中。
2、Redis 提供了兩個命令來生成 RDB 文件，分別是 save 和 bgsave。一般使用bgsave，既能提供數據的可靠性，也能避免影響redis性能。
①save：在主線程中執行，會導致阻塞；
②bgsave：創建一個子進程，專門用于寫入 RDB 文件，避免了主線程的阻塞，這也是 Redis RDB 文件生成的默認配置。
偽代碼
void SAVE(){ # 創建RDB文件
rdbSave();
}
void BGSAVE(){
# 創建子進程
pid = fork();
if (pid==0){
# 子進程創建RDB
rdbSave();
# 創建完成之后向父進程發送信息
signal_parent();
}else if (pid>0){
# 父進程（主線程）繼續處理客戶端請求，并通過輪詢等待子進程的返回信號
handle_request_and_wait_signal();
}else{
# 處理異常
...
}
}
3、redis.conf中配置RDB：內存快照雖然可以通過命令來進行，但生產環境下多數情況都會設置其周期性執行條件，自動保存。
# 周期性執行條件的設置格式為
save <seconds> <changes>
# 默認的設置為：save 900 1save 300 10save 60 10000
# 以下設置方式為關閉RDB快照功能save ""
以上三項默認信息設置代表的意義是：
如果900秒內有1條Key信息發生變化，則進行快照；
如果300秒內有10條Key信息發生變化，則進行快照；
如果60秒內有10000條Key信息發生變化，則進行快照。
①savaparams屬性
struct redisServer{
...
// 修改次數的計數器
long dirty;
// 上一次成功執行RDB快照的時間
time_t lastsave;
// 保存條件配置的數組
struct saveparam *saveparams;
...
}
struct saveparam{
// 秒數
time_t seconds;
// 修改次數
int changes;
}
②周期性檢查保存條件：serverCron函數默認每隔100毫秒就會執行一次，該函數的其中一個作用就是檢查
save命令設置的保存條件是否被滿足，是則執行
BGSAVE命令。偽代碼
如下
void serverCron(){
...
for (saveparam in server.saveparams){
// 計算距離上次成功進行RDB快照多少時間
save_interval = unixtime_now() - server.lastsave;
// 如果距離上次快照時間超過條件設置時間 && 數據庫修改次數超過條件所設置的次數，則執行快照操作
if (save_interval > saveparam.seconds && server.dirty >= saveparam.changes){
BGSAVE()
}
}
...
}
4、Copy-On-Write, COW
redis在執行bgsave生成快照的期間，將內存中的數據同步到硬盤的過程可能就會持續比較長的時間，而實際情況是這段時間Redis服務一般都會收到數據寫操作請求。這時Redis 就會借助操作系統提供的寫時復制技術（Copy-On-Write, COW），在執行快照的同時，正常處理寫操作。
bgsave 子進程是由主線程 fork 生成的，可以共享主線程的所有內存數據。bgsave 子進程運行后，開始讀取主線程的內存數據，并把它們寫入 RDB 文件。
如果主線程對這些數據也都是讀操作，那么，主線程和 bgsave 子進程相互不影響。但是，如果主線程要修改一塊數據，那么，這塊數據就會被復制一份，生成該數據的副本。然后，主線程在這個數據副本上進行修改。同時，bgsave 子進程可以繼續把原來的數據寫入 RDB 文件。
· 寫時復制機制保證快照期間數據可修改，既保證了快照的完整性，也允許主線程同時對數據進行修改，避免了對正常業務的影響。
5、快照的頻率：快照間隔越短，宕機時丟失數據越少。但頻率越高，對磁盤會造成壓力，另外也會頻繁阻塞主線程。這個根據業務和實際來確定。
6、優點
①RDB文件是某個時間節點的快照，默認使用LZF算法進行壓縮，壓縮后的文件體積遠遠小于內存大小，適用于備份、全量復制等場景；
②Redis加載RDB文件恢復數據要遠遠快于AOF方式；
7、缺點:實時性不夠，無法做到妙計持久化；
每次調用bgsave都需要fork子進程，占用系統資源；
RDB文件是二進制的，沒有可讀性