redis持久化：
1.持久化之RDB（RedisDataBase）：
在指定時間間隔內將內存中的數據集快照寫入磁盤，恢復時是將快照文件直接讀到內存；
Redis會單獨創建（fork）一個子進程來進行持久化，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。整個過程中，主進程是不進行任何IO操作的，這就確保了極高的性能。
如果需要進行大規模數據的恢復，且對於數據恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加高效。RDB的缺點是最後一次持久化後的數據可能丟失。
Fork的作用是複製一個與當前進程一樣的進程。新進程的所有數據都和原進程一致，但是是一個全新的進程，並作爲原進程的子進程。
RDB保存的是dump.rdb文件。重啓後會將dump.rdb文件重新讀回內存。dump.rdb文件名可以在redis.conf文件裏修改。
指定在多長時間內，有多少次更新操作，就將數據同步到數據文件，可以多個條件配合
save <seconds><changes>
Redis默認配置文件中提供了三個條件：
save 900 1
save 300 10
save 60 10000
分別表示900秒（15分鐘）內有1個更改，
300秒（5分鐘）內有10個更改，
60秒內有10000個更改，可以自己控制時間，截圖：
也可以用save命令手動保存，即如果5分鐘改動小於10次，但想立刻保存，可以敲save，例如：5分鐘內只修改了k12的值，但修改完了想立刻保存到dump.rdb文件中，用save，截圖：
如果想禁用RDB持久化的策略，只要不設置任何save指令，或者給save傳入一個空字符串也可以，截圖：
執行flushall命令也會產生dump.rdb文件，但是由於flushall命令把數據庫清空了，所以dump.rdb文件裏面是空的。
config get dir:查看dump.rdb文件的存放目錄，截圖：
優勢：適合大規模的數據恢復；對數據完整性和一致性要求不高。
劣勢：由於是在一定時間間隔做一次備份，所以如果redis以外down掉的話，將會丟失最後一次快照後的所有修改；fork的時候，內存中的數據被克隆了一份，大致2倍的膨脹性需要考慮。
2.持久化之AOF（AppendOnly File）：
以日誌的形式來記錄每個寫操作，將redis執行過的所有寫指令記錄下來（讀操作不記錄），只許追加文件但不可以改寫文件，redis啓動之初會讀取該文件重新構建數據，換言之，redis重啓的話就根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工作。
AOF持久化默認沒有開啓，截圖：
AOF持久化數據默認保存在appendonly.aof文件中，可以修改文件名但不建議修改，截圖：
AOF備份的頻率（策略）：
appendfsync always 每次收到寫命令就立即強制寫入磁盤，最慢的，但是保證完全的持久化，不推薦使用；
appendfsync everysec 每秒鐘強制寫入磁盤一次，在性能和持久化方面做了很好的折中，推薦；
appendfsync no 完全依賴 os，性能最好,持久化沒保證。
AOF和RDB可以共存，兩個都存在的時候先加載AOF。
appendonly.aof文件出了問題之後用redis-check-aof –-fix appendonly.aof命令修復；dump.rdb文件出了問題之後用redis-check-dump –-fix dump.rdb命令修復。
Rewrite：AOF採用文件追加方式，文件會越來越大，爲避免出現此種情況，新增了重寫機制，當AOF文件的大小超過所設定的閾值時，redis就會啓動AOF文件的內容壓縮，只保留可以恢復數據的最小指令集，可以使用命令bgrewriteaof;
重寫原理：AOF文件持續增長而過大時，會fork出一條新進程來將文件重寫（也是先寫臨時文件最後再rename），遍歷新進程的內存中數據，每條記錄有一條set語句。重寫AOF文件的操作，並沒有讀取舊的AOF文件，而是將整個內存中的數據庫內容用命令的方式重寫了一個新的AOF文件，這點和快照有點類似。
觸發機制：redis會記錄上次重寫時的AOF大小，默認配置是當AOF文件大小是上次rewrite後大小的一倍（下圖中的100%）且文件大於64M時觸發（實際開發中遠遠大於64M,可以設到5G以上），截圖：
no-appendfsync-on-rewrite:重寫時是否可以運用appendfsync,用默認no即可，保證數據安全性，截圖：
優勢：可靈活配置爲：每秒同步：appendfsync always;每修改同步：appendfsync everysec;不同步：appendfsync no;
劣勢：對相同數據集的數據而言AOF文件遠大於RDB，恢復速度慢於RDB；AOF運行效率慢於RDB，每秒同步策略效率較好，不同步效率和RDB相同。
建議AOF和RDB同時使用保證數據完整性。
