一.概念介紹

redis提供了兩種持久化的方式，分別是RDB（Redis DataBase）和AOF（Apend Only File）。

RDB方式

RDB方式是一種快照式的持久化方法，將某一時刻的數據持久化到磁盤中。

•redis在進行數據持久化的過程中，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，才會用這個臨時文件替換上次持久化好的文件。正是這種特性，讓我們可以隨時來進行備份，因為快照文件總是完整可用的。
•對于RDB方式，redis會單獨創建（fork）一個子進程來進行持久化，而主進程是不會進行任何IO操作的，這樣就確保了redis極高的性能。
•如果需要進行大規模數據的恢復，且對于數據恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

AOF方式

AOF方式是將執行過的寫指令記錄下來，在數據恢復時按照叢前到后的順序再將指令執行一遍。

•AOF命令以redis協議追加保存每次寫的操作到文件末尾.Redis還能對AOF文件進行后臺重寫,使得AOF文件的體積不至于過大.默認的AOF持久化策略是每秒鐘fsync一次（fsync是指把緩存中的寫指令記錄到磁盤中），因為在這種情況下，redis仍然可以保持很好的處理性能，即使redis故障，也只會丟失最近1秒鐘的數據。
•如果在追加日志時，恰好遇到磁盤空間滿、inode滿或斷電等情況導致日志寫入不完整，也沒有關系，redis提供了redis-check-aof工具，可以用來進行日志修復。
•因為采用了追加方式，如果不做任何處理的話，AOF文件會變得越來越大，為此，redis提供了AOF文件重寫（rewrite）機制，即當AOF文件的大小超過所設定的閾值時，redis就會啟動AOF文件的內容壓縮，只保留可以恢復數據的最小指令集。舉個例子或許更形象，假如我們調用了100次INCR指令，在AOF文件中就要存儲100條指令，但這明顯是很低效的，完全可以把這100條指令合并成一條SET指令，這就是重寫機制的原理。
•在進行AOF重寫時，仍然是采用先寫臨時文件，全部完成后再替換的流程，所以斷電、磁盤滿等問題都不會影響AOF文件的可用性。

二. 兩種方式優缺點

1. RDB方式

•優點：

1.RDB是一個單一的緊湊文件,它保存了某個時間點得數據集,非常適用于數據集的備份,比如你可以在每個小時報保存一下過去24小時內的數據,同時每天保存過去30天的數據,這樣即使出了問題你也可以根據需求恢復到不同版本的數據集.
2.RDB是一個緊湊的單一文件,方便傳送，適用于災難恢復.
3.RDB在保存RDB文件時父進程唯一需要做的就是fork出一個子進程,接下來的工作全部由子進程來做，父進程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.
4.與AOF相比,在恢復大的數據集的時候，RDB方式會更快一些.

•缺點：

1.Redis意外宕機,可能會丟失幾分鐘的數據（取決于配置的save時間點）。RDB方式需要保存珍整個數據集，是一個比較繁重的工作，通常需要設置5分鐘或者更久做一次完整的保存。
2.RDB 需要經常fork子進程來保存數據集到硬盤上,當數據集比較大的時候,fork的過程是非常耗時的,可能會導致Redis在一些毫秒級內不能響應客戶端的請求.如果數據集巨大并且CPU性能不是很好的情況下,這種情況會持續更久。

2. AOF方式

•優點

1.使用AOF 會讓Redis數據更加耐久: 你可以使用不同的fsync策略：無fsync,每秒fsync,每次寫的時候fsync.使用默認的每秒fsync策略,Redis的性能依然很好(fsync是由后臺線程進行處理的,主線程會盡力處理客戶端請求),一旦出現故障，你最多丟失1秒的數據.
2.AOF文件是一個只進行追加的日志文件,所以不需要寫入seek,即使由于某些原因(磁盤空間已滿，寫的過程中宕機等等)未執行完整的寫入命令,你也也可使用redis-check-aof工具修復這些問題.
3.Redis 可以在 AOF 文件體積變得過大時，自動地在后臺對 AOF 進行重寫： 重寫后的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。 整個重寫操作是絕對安全的，因為 Redis 在創建新 AOF 文件的過程中，會繼續將命令追加到現有的 AOF 文件里面，即使重寫過程中發生停機，現有的 AOF 文件也不會丟失。 而一旦新 AOF 文件創建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，并開始對新 AOF 文件進行追加操作。
4.AOF 文件有序地保存了對數據庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式保存， 因此 AOF 文件的內容非常容易被人讀懂， 對文件進行分析也很輕松。 導出AOF 文件也非常簡單： 舉個例子， 如果你不小心執行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那么只要停止服務器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重啟 Redis ， 就可以將數據集恢復到 FLUSHALL 執行之前的狀態。

•缺點

1.對于相同的數據集來說，AOF 文件的體積通常要大于 RDB 文件的體積。
2.根據所使用的 fsync 策略，AOF 的速度可能會慢于 RDB 。 在一般情況下， 每秒 fsync 的性能依然非常高， 而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間。

三. 配置方式

1. RDB配置方式

默認情況下，是快照rdb的持久化方式，將內存中的數據以快照的方式寫入二進制文件中，默認的文件名是dump.rdb
 redis.conf配置：

save 900 1 
save 300 10
save 60 10000

以上是默認配置：900秒之內，如果超過1個key被修改，則發起快照保存；
300秒內，如果超過10個key被修改，則發起快照保存 ；
1分鐘之內，如果1萬個key被修改，則發起快照保存 ；

這種方式不能完全保證數據持久化，因為是定時保存，所以當redis服務down掉，就會丟失一部分數據，而且數據量大，寫操作多的情況下，會引起大量的磁盤IO操作，會影響性能。

所以，如果這兩種方式同時開啟，如果對數據進行恢復，不應該用rdb持久化方式對數據庫進行恢復。

2. AOF 配置方式

使用aof做持久化，每一個寫命令都通過write函數追加到appendonly.aof中.
配置方式：啟動aof持久化的方式

appendonly yes

參考資料：http://redis.io/topics/persistence