一、二者的區別
RDB持久化是指在指定的時間間隔內將內存中的數據集快照寫入磁盤，實際操作過程是fork一個子進程，先將數據集寫入臨時文件，寫入成功后，再替換之前的文件，用二進制壓縮存儲。
AOF持久化以日志的形式記錄服務器所處理的每一個寫操作，查詢操作不會記錄，以文本的方式記錄，可以打開文件看到詳細的操作記錄。
二、持久化配置
1. RDB持久化配置
Redis會將數據集的快照dump到dump.rdb文件中。此外，我們也可以通過配置文件來修改Redis服務器dump快照的頻率，在打開6379.conf文件之后，我們搜索save，可以看到下面的配置信息：
- save 900 1 #在900秒(15分鍾)之后，如果至少有1個key發生變化，則dump內存快照。
- save 300 10 #在300秒(5分鍾)之后，如果至少有10個key發生變化，則dump內存快照。
- save 60 10000 #在60秒(1分鍾)之后，如果至少有10000個key發生變化，則dump內存快照。
2. AOF持久化配置
在Redis的配置文件中存在三種同步方式，它們分別是：
- appendfsync always #每次有數據修改發生時都會寫入AOF文件。
- appendfsync everysec #每秒鍾同步一次，該策略為AOF的缺省策略。
- appendfsync no #從不同步。高效但是數據不會被持久化。
三、RDB和AOF的選擇
- RDB持久化方式能夠在指定的時間間隔內對你的數據進行快照存儲
- AOF持久化方式記錄每次對服務器寫的操作，當服務器重啟的時候會重新執行這些命令來恢復原始的數據，AOF命令以Redis 協議追加保存每次寫的操作到文件末尾，Redis還能對AOF文件進行后台重寫，使得AOF文件的體積不至於過大。
- 只做緩存，如果你只希望你的數據在服務器運行的時候存在，你也可以不使用任何持久化
- 同時開啟兩種持久化方式，在這種情況下，當redis重啟的時候會優先載入AOF文件來恢復原始的數據，因為在通常情況下AOF文件保存的數據集要比RDB文件保存的數據集要完整。dump.rdb 的數據不實時，同時使用兩者時服務器重啟也只會找AOF文件
- 那要不要只使用AOF呢?作者建議不要，因為RDB更適合用於備份數據庫（AOF在不斷變化不好備份），快速重啟，而且不會有AOF可能潛在的Bug，留着作為一個萬一的手段。
性能建議
- RDB文件只用作備份用途，建議只在Slave上持久化RDB文件，而且只要15分鍾備份一次就夠了，只保留save 900 1這條規則。
- Enable AOF（appendfsync everysec），好處是在最惡劣情況下也只會丟失不超過兩秒數據，啟動腳本較簡單只加載自己的AOF文件就可以了，代價一是帶來了持續的IO，二是AOF rewrite的最后將rewrite過程中產生的新數據寫到新文件造成的阻塞幾乎是不可避免的。只要硬盤許可，應該盡量減少AOF rewrite的頻率，AOF重寫的基礎大小默認值64M太小了，可以設到5G以上，默認超過原大小100%大小重寫可以改到適當的數值。
- 不使用 AOF，僅靠Master-Slave Repllcation（主從復制）實現高可用性也可以，能省掉一大筆IO，也減少了rewrite時帶來的系統波動。代價是如果Master/Slave同時掛掉（斷電），會丟失十幾分鍾的數據，啟動腳本也要比較兩個Master/Slave 中的 RDB文件，載入較新的那個，微博就是這種架構。