一 ： RDB
Redis會定期保存數據快照至一個rbd文件中，並在啓動時自動加載rdb文件，恢復之前保存的數據。可以在配置文件中配置Redis進行快照保存的時機：
save [seconds] [changes]
意爲在[seconds]秒內如果發生了[changes]次數據修改，則進行一次RDB快照保存，例如
save 60 100
會讓Redis每60秒檢查一次數據變更情況，如果發生了100次或以上的數據變更，則進行RDB快照保存。可以配置多條save指令，讓Redis執行多級的快照保存策略。Redis默認開啓RDB快照。
也可以通過命令手動觸發RDB快照保存。
SAVE 阻塞
BGSAVE 非阻塞
RDB的優點：
對性能影響最小。如前文所述，Redis在保存RDB快照時會fork出子進程進行，幾乎不影響Redis處理客戶端請求的效率。每次快照會生成一個完整的數據快照文件，所以可以輔以其他手段保存多個時間點的快照（例如把每天0點的快照備份至其他存儲媒介中），作爲非常可靠的災難恢復手段。使用RDB文件進行數據恢復比使用AOF要快很多。
RDB的缺點：
快照是定期生成的，所以在Redis crash時或多或少會丟失一部分數據。如果數據集非常大且CPU不夠強（比如單核CPU），Redis在fork子進程時可能會消耗相對較長的時間，影響Redis對外提供服務的能力。
二 ： AOF
採用AOF持久方式時，Redis會把每一個寫請求都記錄在一個日誌文件裏。在Redis重啓時，會把AOF文件中記錄的所有寫操作順序執行一遍，確保數據恢復到最新。AOF默認是關閉的，如要開啓，進行如下配置：
appendonly yes
AOF提供了三種fsync配置，always/everysec/no，通過配置項[appendfsync]指定：
appendfsync no：不進行fsync，將flush文件的時機交給OS決定，速度最快appendfsync
always：每寫入一條日誌就進行一次fsync操作，數據安全性最高，但速度最慢
appendfsync everysec：折中的做法，交由後臺線程每秒fsync一次
隨着AOF不斷地記錄寫操作日誌，因爲所有的操作都會記錄，所以必定會出現一些無用的日誌。大量無用的日誌會讓AOF文件過大，也會讓數據恢復的時間過長。不過Redis提供了AOF rewrite功能，可以重寫AOF文件，只保留能夠把數據恢復到最新狀態的最小寫操作集。
AOF rewrite可以通過BGREWRITEAOF命令觸發，也可以配置Redis定期自動進行：
auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb
上面兩行配置的含義是，Redis在每次AOF rewrite時，會記錄完成rewrite後的AOF日誌大小，當AOF日誌大小在該基礎上增長了100%後，自動進行AOF rewrite。同時如果增長的大小沒有達到64mb，則不會進行
分別優缺點+如何選擇？
RDB需要經常存儲快照，而且RDB是指定一個時間段之後進行持久化，因此如果服務器宕機，那麼RDB會造成大量數據丟失。但是因爲RDB是fork出一個子線程進行的，因此對於多cpu性能影響不大，但對單核cpu會造成redis暫時停止服務
因此，如果對存儲的數據很重要則不能使用RDB
AOF由於一次只需要append only一條語句，因此他的添加數據的週期要小得多，但是因爲添加的是對文件的修改的一整個語句，因此他對性能還是影響比較大的
Redis事務持久性（Durability）
因爲事務不過是用隊列包裹起了一組 Redis 命令，並沒有提供任何額外的持久性功能，所以事務的持久性由 Redis 所使用的持久化模式決定：
在單純的內存模式下，事務肯定是不持久的。
在 RDB 模式下，服務器可能在事務執行之後、RDB 文件更新之前的這段時間失敗，所以 RDB 模式下的 Redis 事務也是不持久的。
在 AOF 的“alwaysfsync ”模式下，事務的每條命令在執行成功之後，都會立即調用 fsync 或 fdatasync 將事務數據寫入到 AOF 文件。但是，這種保存是由後臺線程進行的，主線程不會阻塞直到保存成功，所以從命令執行成功到數據保存到硬盤是非原子性的，這之間，還是有一段非常小的間隔，所以這種模式下的事務也是不持久的（這反映了持久性一定程度上離不開原子性）。
其他 AOF 模式當然更加難以保證事務的持久性。