redis數(shù)據(jù)的兩種持久化方式對(duì)比

一.概念介紹

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

RDB方式

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

•redis在進(jìn)行數(shù)據(jù)持久化的過(guò)程中，會(huì)先將數(shù)據(jù)寫(xiě)入到一個(gè)臨時(shí)文件中，待持久化過(guò)程都結(jié)束了，才會(huì)用這個(gè)臨時(shí)文件替換上次持久化好的文件。正是這種特性，讓我們可以隨時(shí)來(lái)進(jìn)行備份，因?yàn)榭煺瘴募偸峭暾捎玫摹?br /> •對(duì)于RDB方式，redis會(huì)單獨(dú)創(chuàng)建（fork）一個(gè)子進(jìn)程來(lái)進(jìn)行持久化，而主進(jìn)程是不會(huì)進(jìn)行任何IO操作的，這樣就確保了redis極高的性能。
•如果需要進(jìn)行大規(guī)模數(shù)據(jù)的恢復(fù)，且對(duì)于數(shù)據(jù)恢復(fù)的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

AOF方式

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

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

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

1. RDB方式

•優(yōu)點(diǎn)：

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

•缺點(diǎn)：

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

2. AOF方式

•優(yōu)點(diǎn)

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

•缺點(diǎn)

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

三. 配置方式

1. RDB配置方式

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

save 900 1 
save 300 10
save 60 10000

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

這種方式不能完全保證數(shù)據(jù)持久化，因?yàn)槭嵌〞r(shí)保存，所以當(dāng)redis服務(wù)down掉，就會(huì)丟失一部分?jǐn)?shù)據(jù)，而且數(shù)據(jù)量大，寫(xiě)操作多的情況下，會(huì)引起大量的磁盤(pán)IO操作，會(huì)影響性能。

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

2. AOF 配置方式

使用aof做持久化，每一個(gè)寫(xiě)命令都通過(guò)write函數(shù)追加到appendonly.aof中.
配置方式：?jiǎn)?dòng)aof持久化的方式

appendonly yes

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