Redis一共有2種持久化策略，分別是
RDB：Redis DataBase
AOF：Append Only File
RDB
默認情況下，是快照rdb的持久化方式，將內存中的數據以快照的方式寫入二進制文
件中，默認的文件名dump.rdb
RDB持久化是指在指定的時間間隔內將內存中的數據集快照寫入磁盤，
寫入成功後，再替換之前的文件，用二進制壓縮存儲。
RDB持久化配置
save 900 1 15分鐘內至少有1個key被修改
save 300 10 5分鐘內至少有0個key被修改
save 60 10000 1分鐘內至少有100000個key被修改
以上三種默認配置，觸發條件之後，redis就會生成快照，將內存中的數據寫入到dump.rdb文件中
注意：執行save，FlushDB，FlushAll，Shutdown 命令之後，會立即生成快照，自動備份
RBD文件修復命令：redis-check-dump –fix dump.rdb
RDB的優缺點
優點：
由於存儲的有數據快照文件，恢復數據很方便。
相比於AOF機制，如果數據集很大，RDB的啓動效率會更高
性能最大化。對於Redis的服務進程而言，在開始持久化時，
之後再由子進程完成這些持久化的工作，
這樣就可以極大的避免服務進程執行IO操作了
缺點：
會丟失最後一次快照以後更改的所有數據。
因此，如果當數據集較大時，
可能會導致整個服務器停止服務幾百毫秒，甚至是1秒鐘。
AOF
AOF持久化以日誌的形式記錄服務器所處理的每一個寫、刪除操作，
查詢操作不會記錄，以文本的方式記錄，可以打開文件看到詳細的操作記錄。
開啓方法：
只需要在redis.conf中，將appendonly 設置爲 yes，即可開啓AOF持久化
AOF持久化配置
在Redis的配置文件中存在三種同步方式，它們分別是：
appendfsync always #每次有數據修改發生時都會寫入AOF文件。
appendfsync everysec #每秒鐘同步一次，該策略爲AOF的缺省策略。（推薦策略）
appendfsync no #從不同步。高效但是數據不會被持久化。
AOF文件重寫
auto-aof-rewrite-percentage 100：默認超過當前配置重寫容量100%（當前爲64M），則進行重寫
auto-aof-rewrite-min-size 64mb：默認存儲64M
AOF文件修復命令：redis-check-aof –fix appendonly.aof
AOF的優缺點
優點：
Redis中AOF默認同步策略是每秒同步一次，所以丟失數據小，數據一致性高
缺點：
數據量相同的情況下，AOF恢復數據的速度要低於RDB
總之，每秒同步策略的效率是比較高的，同步禁用策略的效率和RDB一樣高效。
二者選擇的標準，就是看系統是願意犧牲一些性能，換取更高的緩存一致性（aof），還是願意寫操作頻繁的時候，不啓用備份來換取更高的性能，待手動運行save的時候，再做備份（rdb）。rdb這個就更有些 eventually consistent的意思了。
數據恢復
將備份的dump.rdb或者appendonly.aof文件拷貝到redis.conf文件同級目錄下，
重新啓動redis服務，即可恢復數據
注意：當redis啓動時，如果rdb持久化和aof持久化都打開了，那麼程序會優先使用aof方式來恢復數據集，因爲aof方式所保存的數據通常是最完整的。如果aof文件丟失了，則啓動之後數據庫內容爲空。
注意：如果想把正在運行的redis數據庫，從RDB切換到AOF，建議先使用動態切換方式，再修改配置文件，重啓數據庫。(不能直接修改配置文件，重啓數據庫，否則數據庫中數據就爲空了