1.RDB AOF區別
RDB持久化是指在指定的時間間隔內將記憶體中的資料集快照寫入磁碟中，fork一個子進程，先將資料集寫入臨時文件，寫入成功後，再替換之前的文件，用二進位壓縮儲存。
具體操作：遍歷hash table，利用copy on write，把整個db dump保存下來。
save, shutdown, slave 指令會觸發這個動作。
特點：粒度比較大，如果save, shutdown, slave 之前crash了，則中間的操作沒辦法恢復。
AOF持久化以日誌的形式記錄伺服器所處理的每一個寫入、刪除操作，查詢操作不會記錄，以文字的方式記錄，可以開啟檔案看到詳細的操作記錄。 Redis 也可以在背景對 AOF 檔案進行重寫（rewrite），使得 AOF 檔案的體積不會超出保存資料集狀態所需的實際大小。 Redis 還可以同時使用 AOF 持久化和 RDB 持久化。在這種情況下， 當 Redis 重新啟動時， 它會優先使用 AOF 檔案來還原資料集， 因為 AOF 檔案保存的資料集通常比 RDB 檔案所保存的資料集更完整。你甚至可以關閉持久化功能，讓資料只在伺服器運行時存在。
特點：粒度較小，crash之後，只有crash之前沒有來得及做日誌的操作沒辦法恢復。
選擇的標準，就是看系統是願意犧牲一些效能，換取更高的快取一致性（aof），還是願意寫作業頻繁的時候，不啟用備份來換取更高的效能，待手動運行save的時候，再做備份（rdb）。 rdb這個就更有些 eventually consistent的意思了。
2.AOF RDB優缺點
AOF：
#優點：使用AOF 持久化會讓Redis 非常耐久（much more durable）：你可以設定不同的fsync 策略，例如無fsync ，每秒鐘一次fsync ，或每次執行寫入指令時fsync 。 AOF 的預設策略為每秒鐘fsync 一次，在這種配置下，Redis 仍然可以保持良好的效能，並且就算發生故障停機，也最多只會丟失一秒鐘的資料（ fsync 會在後台執行緒執行，所以主線程可以繼續努力地處理命令請求）。 AOF 檔案是一個只進行追加操作的日誌檔案（append only log）， 因此對AOF 檔案的寫入不需要進行seek ， 即使日誌因為某些原因而包含了未寫入完整的命令（例如寫入時磁碟已滿，寫入中途停機，等等）， redis-check-aof 工具也可以輕易地修復這種問題。
Redis 可以在 AOF 檔案體積變得過大時，自動地在背景對 AOF 進行重寫： 重寫後的新 AOF 檔案包含了恢復目前資料集所需的最小指令集。整個重寫操作是絕對安全的，因為Redis 在創建新AOF 文件的過程中，會繼續將命令追加到現有的AOF 文件裡面，即使重寫過程中發生停機，現有的AOF 文件也不會丟失。而一旦新 AOF 文件創建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，並開始對新 AOF 文件進行追加操作。 AOF 檔案有序地保存了對資料庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式保存， 因此 AOF 文件的內容非常容易被人讀懂， 對文件進行分析（parse）也很輕鬆。匯出（export） AOF 檔案也非常簡單： 舉個例子， 如果你不小心執行了FLUSHALL 指令， 但只要AOF 檔案未被重寫， 那麼只要停止伺服器， 移除AOF 檔案末尾的FLUSHALL 指令， 並重啟Redis ，就可以將資料集還原到FLUSHALL 執行之前的狀態。
缺點:
對於相同的資料集來說，AOF 檔案的體積通常大於 RDB 檔案的體積。 根據所使用的 fsync 策略，AOF 的速度可能會慢於 RDB 。在一般情況下， 每秒 fsync 的效能依然非常高，而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負載之下也是如此。 不過在處理龐大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）。 AOF 在過去曾經發生過這樣的 bug ： 因為個別指令的原因，導致 AOF 檔案在重新載入時，無法將資料集恢復成保存時的原樣。 （舉個例子，阻塞指令BRPOPLPUSH 就曾經引起過這樣的bug 。）測試套件裡為這種情況添加了測試： 它們會自動產生隨機的、複雜的資料集， 並透過重新載入這些資料來確保一切正常。雖然這種 bug 在 AOF 檔案中並不常見， 但對比來說， RDB 幾乎是不可能出現這種 bug 的。
RDB 的優點:
RDB 是一個非常緊湊（compact）的文件，它保存了 Redis 在某個時間點上的資料集。 這種文件非常適合用於進行備份： 比方說，你可以在最近的 24 小時內，每小時備份一次 RDB 文件，並且在每個月的每一天，也備份一個 RDB 文件。這樣的話，即使遇上問題，也可以隨時將資料集還原到不同的版本。 RDB 非常適合災難復原（disaster recovery）：它只有一個文件，而且內容都非常緊湊，可以（在加密後）將它傳送到別的資料中心，或亞馬遜 S3 中。 RDB 可以最大化Redis 的效能：父進程在儲存RDB 檔案時唯一要做的就是fork 出一個子進程，然後這個子進程就會處理接下來的所有儲存工作，父程式無須執行任何磁碟I/O 操作。 RDB 在復原大資料集時的速度比 AOF 的復原速度還要快。
缺點:
如果你需要盡量避免在伺服器故障時遺失數據，那麼 RDB 不適合你。雖然 Redis 允許你設定不同的保存點（save point）來控制保存 RDB 檔案的頻率， 但是， 因為RDB 檔案需要保存整個資料集的狀態， 所以它並不是一個輕鬆的操作。因此你可能會至少 5 分鐘才儲存一次 RDB 檔案。在這種情況下， 一旦發生故障停機， 你就可能會遺失好幾分鐘的資料。每次儲存 RDB 的時候，Redis 都要 fork() 出一個子程序，並由子程序來進行實際的持久化工作。在資料集比較龐大時， fork() 可能會非常耗時，造成伺服器在某某毫秒內停止處理客戶端；如果資料集非常巨大，並且CPU 時間非常緊張的話，那麼這種停止時間甚至可能會長達整整一秒。雖然 AOF 重寫也需要進行 fork() ，但無論 AOF 重寫的執行間隔有多長，資料的耐久性都不會有任何損失。