redis官方提供了兩種持久化方式
RDB 和 AOF。
RDB（快照）：
快照是基於內存數據的二進制序列化形式，
redis是單線程程序，使用多了多路複用api，但是rdb是io文件操作，io文件操作是不可以使用多路複用技術的。
所以rdb使用了操作系統的多線程cow（Copy on Write）機制實現快照持久化，這個機制很少人知道。
redis在持久化的時候會調用glibc的函數fork產生一個子線程，持久化處理交給子線程處理，主線程繼續處理線上請求。
子線程做數據持久化，不會修改現在的內存數據結構，它只是對數據結構進行遍歷讀取，然後序列化到磁盤裏，但是主線程不一樣，它必須持續服務客戶端請求，然後對內存裏的數據進行修改。
調用方式：
手動調用執行save和bgsave命令可以手動觸發RDB持久化
--save前臺調用會阻塞當前服務器，知道RDB完成爲止，如果數據量大的話會造成服務器的阻塞，線上環境一般不推薦使用
--bgsave後臺調用，執行bgsave命令時候redis進程會fork一個子進程來完成io文件操作，完成後自動結束，只有fork的時候會阻塞主線程，時間很短，推薦使用
自動調用通過設置配置文件,配置redis.config文件如下：
save <seconds> <changes>
save 900 1
這個命令指的是如果900秒內有一條key信息發生變化就執行bgsave。
在執行shutdown的時候，如果沒有開啓aof持久化，也會自行執行一次bgsave。
AOF:
aof日誌存儲的是redis服務器的順序指令序列，aof日誌只記錄對內存進行修改的指令記錄。
記錄的是resp通訊協議的命令存儲格式。
當你的redis數據全沒有了，通過aof恢復相當於重放，重新執行的之前所有寫命令操作，
當然存儲在文件裏面的都是resp格式的東西。
如果redis長期運行，aof的日誌會越來越長，如果發生宕機重啓，重放整個aof文件是很耗時的。導致redis會無法對
外提供服務，所有需要對aof日誌瘦身， 就用到了重寫機制
重寫機制：
每次都是生成一個aof文件，都會去掉一些重複和無用的命令，達到瘦身的需求。
調用方式：
1.可以手動調用bgrewriteaof命令。
2.也可以自動調用
auto-aof-rewrite-min-size 64MB
auto-aof-rewrite-min-percenrage 100
上面兩個配置表示：
- 當AOF文件小於64MB的時候不進行AOF重寫
- 噹噹前AOF文件比上次AOF重寫後的文件大100%的時候進行AOF重寫
Redis重啓時加載持久化文件的順序
--redis重啓的時候會優先加載aof文件，如果aof文件不存在再去加載rdb文件，
--如果aof文件和rdb文件都不存在，則直接啓動
--如果加載aof和rdb文件報錯，則啓動失敗
Redis4.0之後，很少使用rdb來恢復內存狀態， 因爲會丟失大量數據，我們通常使用aof重放，但是重放aof文件相對於
rdb要慢得多，這樣啓動會要很長時間，redis4.0爲了解決這個問題，新增了一個新的持久化方式選項-混合持久化，
aof重寫產生的文件同時包含rdb格式的內容和aof格式的內容，其中rdb格式的內容記錄所有的數據，aof記錄發生更改的數據，這樣就可以快速的生成重寫文件。
這個功能可以在redis.conf裏面開啓
aof-use-rdb-preamble no
以上