一.概念介紹

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

RDB方式

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

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

AOF方式

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

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

二. 兩種方式優(yōu)缺點

1. RDB方式

•優(yōu)點：

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

•缺點：

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

2. AOF方式

•優(yōu)點

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

•缺點

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

三. 配置方式

1. RDB配置方式

默認(rèn)情況下，是快照rdb的持久化方式，將內(nèi)存中的數(shù)據(jù)以快照的方式寫入二進(jìn)制文件中，默認(rèn)的文件名是dump.rdb
 redis.conf配置：

save 900 1 
save 300 10
save 60 10000

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

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

所以，如果這兩種方式同時開啟，如果對數(shù)據(jù)進(jìn)行恢復(fù)，不應(yīng)該用rdb持久化方式對數(shù)據(jù)庫進(jìn)行恢復(fù)。

2. AOF 配置方式

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

appendonly yes

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