一、什麼是 Redis 的持久化
rdb和aof
二、RDB（Redis DataBase）：
1、RDB是什麼?
- 在指定的時間間隔內將記憶體中的資料集快照寫入磁碟，
也就是行話講的：
Snapshot快照，它恢復時是將快照檔案直接讀到記憶體裡 - Redis會單獨建立（fork拷貝）一個子程式來進行持久化，會先將資料寫入到一個臨時檔案中，待持久化過程都結束了，再用這個臨時檔案替換上次持久化好的檔案。比如：第一次儲存5條資料到
dump.rdb檔案中，5分鐘後，第二次儲存20到條dump.rdb檔案中，就把第一次的覆蓋了。 - 整個過程中，主程式是不進行任何IO操作的，這就確保了極高的效能。如果需要進行大規模資料的恢復，且對於資料恢復的完整性不是非常敏感， 那RDB方式要比AOF方式更加的高效。
- RDB的缺點：最後一次持久化後的資料可能丟失。比如：伺服器剛好炸了。
2、Fork
Fork的作用：複製一個與當前程式一樣的程式。新程式的所有資料（變數、環境變數、程式計數器等）
數值都和原程式一致，但是是一個全新的程式，並作為原程式的子程式。
3、RDB 儲存的是 dump.rdb檔案。
4、配置位置：redis.conf 的 SNAPSHOTTING
5、配置詳解：
在磁碟上儲存資料的命令：save <seconds> <changes>
以下情況3選1，將會觸發資料庫儲存：
- 900秒（15分鐘）內，如果至少增刪改了1個key，觸發資料庫儲存，會產生dump.rdb檔案，默默地儲存到磁碟中。
- 300秒（5分鐘）內，如果至少改變了10個key，觸發資料庫儲存，會產生dump.rdb檔案，默默地儲存到磁碟中。
- 60秒內，如果至少改變了10000個key，觸發資料庫儲存，會產生dump.rdb檔案，默默地儲存到磁碟中。
手動立即儲存：
set key value->save
不儲存：
- 註釋掉上面的配置即可。
注意：
- 執行
ShutDown，相當於MySQL的commit，會立即生成dump.rdb檔案。此時，如果之前執行FLUSHALL，把資料庫清空，此時既清空又提交，生成的dump.rdb是空的檔案。所以，恢復的檔案也是空的。
恢復：
- 遠端伺服器已備份的資料拷貝到生產機器，命名為：
dump.rdb即可。
stop-writes-on-bgsave-error：後臺save出錯，那麼就停止寫入，出錯就剎車。
rdbcompression：是否啟用壓縮演算法，預設開啟。
rdbchecksum：用於資料校驗。
6、如何觸發RDB快照（3種方式）
- 配置檔案中預設的快照配置（3種策略）
- 命令
save或者bgsave。Save：save時只管儲存，其它不管，全部阻塞。BGSAVE：Redis會在後臺非同步進行快照操作，快照同時還可以響應客戶端請求。可以通過：lastsave，獲取最後一次成功執行快照的時間 - 執行
flushall命令，也會產生dump.rdb檔案，但裡面是空的，無意義
7、RDB優勢和劣勢：
- 優勢：適合大規模的資料恢復；對資料完整性和一致性要求不高
- 劣勢：在一定間隔時間做一次備份，所以如果redis意外down掉的話，就會丟失最後一次快照後的所有修改的時候；記憶體中的資料被克隆了一份，大致2倍的膨脹性需要考慮。
8、如何停止：
- 動態所有停止RDB儲存規則的方法：
redis-cli config set save ""
三、AOF（Append Only File）
1、AOF是什麼?
- 是記錄操作者的所有寫操作，資料恢復的時候，把所有寫操作執行一遍。
- 以日誌的形式來記錄每個寫操作，將Redis執行過的所有寫指令記錄下來(讀操作不記錄)，只許追加檔案但不可以改寫檔案，redis重啟的話就根據日誌檔案的內容，將寫指令從頭到尾執行一次以完成資料的恢復工作。
2、AOF 儲存的是 appendonly.aof檔案
3、配置的位置：redis.conf 的 APPEND ONLY MODE
4、配置詳解：
appendfsync ：同步寫的策略，有三種
always：同步持久化，每次發生資料變更會被立即記錄到磁碟，效能較差，但資料完整性比較好everysec：出廠預設推薦，非同步操作，每秒記錄，如果一秒內當機，有資料丟失no：從不同步
預設AOF檔名：appendonly.aof
AOF啟動，修復，恢復：
1、啟動 AOF
AOF持久化儲存方式預設關閉，設定yes就是啟動持久化
2、修復 AOF
如果我在上面檔案的後面，模擬檔案損壞的場景，能否成功啟動redis？同時存在rdb 和aof ，兩者能否共存，能的話優先載入誰？
模擬：
啟動：
第一問：啟動失敗；
第二問：可以共存；
第三問：優先載入 aof 檔案，因為 rdb 檔案是正常的，aof 檔案是損壞的，載入失敗的原因是 aof 檔案損壞，所以得出：優先載入 aof 檔案
3、如何修復 aof 檔案？
輸入命令：redis-check-aof --fix appendonly.aof
Rewrite(AOF檔案自我瘦身)：
1、是什麼？
- AOF採用檔案追加的方式，檔案會越來越大，為避免出現此種情況：新增了重寫機制，當AOF檔案的大小超過所設定的閾值時，redis就會自動開啟AOF檔案的內容壓縮，只保留可以恢復資料的最小指令集，可以使用
bgrewriteaof。
2、重寫原理：
- AOF檔案持續增長而過大時，會fork出一條新程式來將檔案重寫。重寫aof檔案的操作，並沒有讀取舊的aof檔案，而是將整個記憶體中的資料庫內容用命令方式重寫了一個新的aof檔案，這點和快照有點類似。
3、觸發條件:
- redis會記錄上次重寫時的AOF大小，預設配置：是當AOF檔案大小是上次rewrite後大小的一倍，且檔案大於64M時觸發，高併發系統絕對不止64mb。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
複製程式碼AOF優勢和劣勢：
- 優勢：可以靈活設定同步寫的策略；資料比較完整
- 劣勢：相同資料集的資料而言aof檔案要遠大於rdb檔案，恢復速度慢於rdb；aof執行效率要慢於rdb，每秒同步策略效率較好，不同步效率和rdb相同
四、RDB or AOF
- 同時開啟兩種持久化方式：在這種情況下，當redis重啟的時候會優先載入AOF檔案來恢復原始的資料。
- 因為在通常情況下AOF檔案儲存的資料集要比RDB檔案儲存的資料集要完整。
- RDB的資料不實時，同時使用兩者時伺服器重啟也只會找AOF檔案。那要不要只使用AOF呢？建議不要，因為RDB更適合用於備份資料庫(AOF在不斷變化不好備份)。
五、面試：
1、什麼是持久化？
rdb和aof
2、如果dump.rdb和appendonly.aof可以共存，同時存在的情況下，會先載入誰？
- 優先載入
appendonly.aof