redis的持久化方式只有2種，rdb和aof。
RDB：
redis會單獨創建（fork）一個子進程來進行實例化，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。整個過程中，主進程是不進行任何 IO操作的，這就確保了極高的性能。RDB的缺點是最後一次持久化後的數據可能丟失。RDB保存的是dump.rdb文件
fork的作用是複製一個與當前進程一樣的進程，新進程的所有數據都和原進程一致，但是是一個全新的進程，並作爲原進程的子進程。
通過save或bgsave命令可以立刻備份，save時只管保存，其他不管，全部阻塞；bgsave時，redis會在後臺異步進行快照操作，快照同時還可以響應客戶端請求，可以通過lastsave命令獲取最後一次成功執行快照的時間。
執行flushall命令，也會產生dump.rdb文件，但裏面是空的。
AOF :
以日誌的形式來記錄來記錄每個寫操作，將redis執行過的所有寫指令記錄下來（讀操作不記錄），只許追加文件但不能改寫文件，redis啓動時會讀取該文件重新構建數據，換言之，redis重啓的話就根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工作。
appendfsync有3種策略：默認是everysec(異步操作，每秒記錄，如果一秒內宕機，有數據丟失)，always（同步持久化，每次發生數據變更都會被立即記錄到磁盤，性能較差），no（從不同步）
rewrite
: 當aof文件的大小超過所設定的閾值時，redis就會啓動aof文件的內容壓縮，只保留可以恢復數據的最小指令集，可以使用命令bgrewriteaof。
重寫原理：aof文件持續增長而過大時，會fork出一條新進程來將文件重寫（也是先寫臨時文件最後再rename），遍歷新進程的內存中數據，每條記錄有一個對應的set語句。重寫aof文件的操作，並沒有讀取舊的aof文件，而是將整個內存中數據庫的內容用命令的方式重寫了一個新的aof文件，這點和快照有點類似。
觸發機制：redis會記錄上次重寫時的aof大小，默認配置是當aof文件大小是上次rewrite後大小的一倍且文件大於64M時觸發。（生產上文件大小一般以G爲單位）
dump.rdb和appendonly.aof文件可以共存，redis啓動時會先加載appendonly.aof。
如果appendonly.aof文件出現問題，可以使用redis-check-aof --fix appendonly.aof
修復。
如果dump.rdb文件出現問題，可以使用redis-check-rdb --fix dump.rdb修復。
對於相同數據集的數據而言，aof文件要遠大於rdb文件，恢復速度慢於rdb。
aof運行效率要慢於rdb，每秒同步策略較好，不同步效率和rdb相同。
