RDB
rdb保存的是dump.rdb文件。
在指定的時間間隔內將內存中的數據快照寫入磁盤，也就是行話中的快照，它恢復時是將快照文件直接讀到內存。這個快照就是dump.rdb
Redis會單獨創建（fork）一個子進程來進行持久化。
會先將數據寫到一個臨時文件中。待持久化過程都結束了，
在用這個文件替代上次持久化好的文件，
主進程是不任何的IO操作的，這就保持了很高的性能。
如果需要進行大規模的數據回覆，且對數據恢復的完整性不是非常敏感，
那RDB方式要比AOF方式更加高效。
優勢：
1、適合大規模的數據恢復
2、對數據完整性和一致性要求不高
劣勢：
1、在一定間隔時間做一次備份，如果redis意味down掉的話，就會丟失最後一次快照後的所有修改
2、fork的時候，內存中的數據會被克隆一份，大致2倍的膨脹性需要考慮
AOF
AOF保存的是appendonly.aof文件
AOF的出現就是爲了彌補RDB的劣勢。
它以日誌的形式來記錄每個寫操作，將Redis執行過的所有寫指令記錄下來（讀操作不記錄），
只許追加文件但不可以修改文件，
redis啓動之初會讀取該文件重新構建數據。
優勢：
每修改同步：appendfsnc always 同步持久化每次發生數據變更會被立即記錄到磁盤，性能較差但數據完整性比較好。
每秒同步：appendfsnc everysec 異步操作，每秒記錄，如果一秒內宕機，有數據丟失
不同步：appendfsnc no 從不同步
劣勢：
1、相同數據集的數據而言aof文件要遠大於rdb文件，恢復速度慢於rdb
2、aof運行效率要慢於rdb，每秒同步策略效率較好，不同步效率和rdb相同
總結
RDB持久化方式能夠在指定的時間間隔能對你的數據進行快照存儲。
AOF持久化方式記錄每次對服務器寫的操作，當服務器重啓的時候會重新執行這些命令來回復原始數據，AOF命令以redis協議追加保存每次寫的操作到文件末尾。
Redis還能對AOF文件進行後臺重寫，使得AOF文件的體積不至於過大
同時開啓兩種持久化方式：
在這種情況下,當redis重啓的時候會優先載入AOF文件來恢復原始的數據,
因爲在通常情況下AOF文件保存的數據集要比RDB文件保存的數據集要完整。
RDB的數據不實時，同時使用兩者時服務器重啓也只會找AOF文件。
那要不要只使用AOF呢？
Redis的作者建議不要，因爲RDB更適合用於備份數據庫(AOF在不斷變化不好備份)，
快速重啓，而且不會有AOF可能潛在的bug，留着作爲一個萬一的手段。