Redis DataBase(簡稱RDB)Append-only file (簡稱AOF)除了這兩種方法，Redis在早起的版本還存在虛擬內(nèi)存的方法，現(xiàn)在已經(jīng)被廢棄。
一、RDB概述
RDB是在某個時間點(diǎn)將數(shù)據(jù)寫入一個臨時文件，持久化結(jié)束后，用這個臨時文件替換上次持久化的文件，達(dá)到數(shù)據(jù)恢復(fù)。 優(yōu)點(diǎn)：使用單獨(dú)子進(jìn)程來進(jìn)行持久化，主進(jìn)程不會進(jìn)行任何IO操作，保證了redis的高性能 缺點(diǎn)：RDB是間隔一段時間進(jìn)行持久化，如果持久化之間redis發(fā)生故障，會發(fā)生數(shù)據(jù)丟失。所以這種方式更適合數(shù)據(jù)要求不嚴(yán)謹(jǐn)?shù)臅r候
這里說的這個執(zhí)行數(shù)據(jù)寫入到臨時文件的時間點(diǎn)是可以通過配置來自己確定的，通過配置redis在n秒內(nèi)如果超過m個key被修改這執(zhí)行一次RDB操作。這個操作就類似于在這個時間點(diǎn)來保存一次Redis的所有數(shù)據(jù)，一次快照數(shù)據(jù)。所有這個持久化方法也通常叫做snapshots。
RDB默認(rèn)開啟，redis.conf中的具體配置參數(shù)如下；
#dbfilename：持久化數(shù)據(jù)存儲在本地的文件dbfilename dump.rdb#dir：持久化數(shù)據(jù)存儲在本地的路徑，如果是在/redis/redis-3.0.6/src下啟動的redis-cli，則數(shù)據(jù)會存儲在當(dāng)前src目錄下dir ./##snapshot觸發(fā)的時機(jī)，save <seconds> <changes> ##如下為900秒后，至少有一個變更操作，才會snapshot ##對于此值的設(shè)置，需要謹(jǐn)慎，評估系統(tǒng)的變更操作密集程度 ##可以通過“save “””來關(guān)閉snapshot功能 #save時間，以下分別表示更改了1個key時間隔900s進(jìn)行持久化存儲；更改了10個key300s進(jìn)行存儲；更改10000個key60s進(jìn)行存儲。save 900 1save 300 10save 60 10000##當(dāng)snapshot時出現(xiàn)錯誤無法繼續(xù)時，是否阻塞客戶端“變更操作”，“錯誤”可能因為磁盤已滿/磁盤故障/OS級別異常等 stop-writes-on-bgsave-error yes ##是否啟用rdb文件壓縮，默認(rèn)為“yes”，壓縮往往意味著“額外的cpu消耗”，同時也意味這較小的文件尺寸以及較短的網(wǎng)絡(luò)傳輸時間 rdbcomPRession yes 1234567891011121314151612345678910111213141516snapshot觸發(fā)的時機(jī)，是有“間隔時間”和“變更次數(shù)”共同決定，同時符合2個條件才會觸發(fā)snapshot,否則“變更次數(shù)”會被繼續(xù)累加到下一個“間隔時間”上。snapshot過程中并不阻塞客戶端請求。snapshot首先將數(shù)據(jù)寫入臨時文件，當(dāng)成功結(jié)束后，將臨時文件重名為dump.rdb。
使用RDB恢復(fù)數(shù)據(jù)： 自動的持久化數(shù)據(jù)存儲到dump.rdb后。實(shí)際只要重啟redis服務(wù)即可完成（啟動redis的server時會從dump.rdb中先同步數(shù)據(jù)）
客戶端使用命令進(jìn)行持久化save存儲：
./redis-cli -h ip -p port save./redis-cli -h ip -p port bgsave1212一個是在前臺進(jìn)行存儲，一個是在后臺進(jìn)行存儲。我的client就在server這臺服務(wù)器上，所以不需要連其他機(jī)器，直接./redis-cli bgsave。由于redis是用一個主線程來處理所有 client的請求，這種方式會阻塞所有client請求。所以不推薦使用。另一點(diǎn)需要注意的是，每次快照持久化都是將內(nèi)存數(shù)據(jù)完整寫入到磁盤一次，并不是增量的只同步臟數(shù)據(jù)。如果數(shù)據(jù)量大的話，而且寫操作比較多，必然會引起大量的磁盤io操作，可能會嚴(yán)重影響性能。
二、AOF概述
Append-only file，將“操作 + 數(shù)據(jù)”以格式化指令的方式追加到操作日志文件的尾部，在append操作返回后(已經(jīng)寫入到文件或者即將寫入)，才進(jìn)行實(shí)際的數(shù)據(jù)變更，“日志文件”保存了歷史所有的操作過程；當(dāng)server需要數(shù)據(jù)恢復(fù)時，可以直接replay此日志文件，即可還原所有的操作過程。AOF相對可靠，它和MySQL中bin.log、apache.log、zookeeper中txn-log簡直異曲同工。AOF文件內(nèi)容是字符串，非常容易閱讀和解析。 優(yōu)點(diǎn)：可以保持更高的數(shù)據(jù)完整性，如果設(shè)置追加file的時間是1s，如果redis發(fā)生故障，最多會丟失1s的數(shù)據(jù)；且如果日志寫入不完整支持redis-check-aof來進(jìn)行日志修復(fù)；AOF文件沒被rewrite之前（文件過大時會對命令進(jìn)行合并重寫），可以刪除其中的某些命令（比如誤操作的flushall）。 缺點(diǎn)：AOF文件比RDB文件大，且恢復(fù)速度慢。
我們可以簡單的認(rèn)為AOF就是日志文件，此文件只會記錄“變更操作”(例如：set/del等)，如果server中持續(xù)的大量變更操作，將會導(dǎo)致AOF文件非常的龐大，意味著server失效后，數(shù)據(jù)恢復(fù)的過程將會很長；事實(shí)上，一條數(shù)據(jù)經(jīng)過多次變更，將會產(chǎn)生多條AOF記錄，其實(shí)只要保存當(dāng)前的狀態(tài)，歷史的操作記錄是可以拋棄的；因為AOF持久化模式還伴生了“AOF rewrite”。 AOF的特性決定了它相對比較安全，如果你期望數(shù)據(jù)更少的丟失，那么可以采用AOF模式。如果AOF文件正在被寫入時突然server失效，有可能導(dǎo)致文件的最后一次記錄是不完整，你可以通過手工或者程序的方式去檢測并修正不完整的記錄，以便通過aof文件恢復(fù)能夠正常；同時需要提醒，如果你的redis持久化手段中有aof，那么在server故障失效后再次啟動前，需要檢測aof文件的完整性。
AOF默認(rèn)關(guān)閉，開啟方法，修改配置文件reds.conf：appendonly yes
##此選項為aof功能的開關(guān)，默認(rèn)為“no”，可以通過“yes”來開啟aof功能 ##只有在“yes”下，aof重寫/文件同步等特性才會生效 appendonly yes ##指定aof文件名稱 appendfilename appendonly.aof ##指定aof操作中文件同步策略，有三個合法值：always everysec no,默認(rèn)為everysec appendfsync everysec ##在aof-rewrite期間，appendfsync是否暫緩文件同步，"no"表示“不暫緩”，“yes”表示“暫緩”，默認(rèn)為“no” no-appendfsync-on-rewrite no ##aof文件rewrite觸發(fā)的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才會觸發(fā)rewrite，默認(rèn)“64mb”，建議“512mb” auto-aof-rewrite-min-size 64mb ##相對于“上一次”rewrite，本次rewrite觸發(fā)時aof文件應(yīng)該增長的百分比。 ##每一次rewrite之后，redis都會記錄下此時“新aof”文件的大小(例如A)，那么當(dāng)aof文件增長到A*(1 + p)之后 ##觸發(fā)下一次rewrite，每一次aof記錄的添加，都會檢測當(dāng)前aof文件的尺寸。 auto-aof-rewrite-percentage 100 1234567891011121314151617181912345678910111213141516171819AOF是文件操作，對于變更操作比較密集的server，那么必將造成磁盤IO的負(fù)荷加重；此外linux對文件操作采取了“延遲寫入”手段，即并非每次write操作都會觸發(fā)實(shí)際磁盤操作，而是進(jìn)入了buffer中，當(dāng)buffer數(shù)據(jù)達(dá)到閥值時觸發(fā)實(shí)際寫入(也有其他時機(jī))，這是linux對文件系統(tǒng)的優(yōu)化，但是這卻有可能帶來隱患，如果buffer沒有刷新到磁盤，此時物理機(jī)器失效(比如斷電)，那么有可能導(dǎo)致最后一條或者多條aof記錄的丟失。通過上述配置文件，可以得知redis提供了3中aof記錄同步選項：
always：每一條aof記錄都立即同步到文件，這是最安全的方式，也以為更多的磁盤操作和阻塞延遲，是IO開支較大。everysec：每秒同步一次，性能和安全都比較中庸的方式，也是redis推薦的方式。如果遇到物理服務(wù)器故障，有可能導(dǎo)致最近一秒內(nèi)aof記錄丟失(可能為部分丟失)。no：redis并不直接調(diào)用文件同步，而是交給操作系統(tǒng)來處理，操作系統(tǒng)可以根據(jù)buffer填充情況/通道空閑時間等擇機(jī)觸發(fā)同步；這是一種普通的文件操作方式。性能較好，在物理服務(wù)器故障時，數(shù)據(jù)丟失量會因OS配置有關(guān)。其實(shí)，我們可以選擇的太少，everysec是最佳的選擇。如果你非常在意每個數(shù)據(jù)都極其可靠，建議你選擇一款“關(guān)系性數(shù)據(jù)庫”吧。 AOF文件會不斷增大，它的大小直接影響“故障恢復(fù)”的時間,而且AOF文件中歷史操作是可以丟棄的。AOF rewrite操作就是“壓縮”AOF文件的過程，當(dāng)然redis并沒有采用“基于原aof文件”來重寫的方式，而是采取了類似snapshot的方式：基于copy-on-write，全量遍歷內(nèi)存中數(shù)據(jù)，然后逐個序列到aof文件中。因此AOF rewrite能夠正確反應(yīng)當(dāng)前內(nèi)存數(shù)據(jù)的狀態(tài)，這正是我們所需要的；*rewrite過程中，對于新的變更操作將仍然被寫入到原AOF文件中，同時這些新的變更操作也會被redis收集起來(buffer，copy-on-write方式下，最極端的可能是所有的key都在此期間被修改，將會耗費(fèi)2倍內(nèi)存)，當(dāng)內(nèi)存數(shù)據(jù)被全部寫入到新的aof文件之后，收集的新的變更操作也將會一并追加到新的aof文件中，此后將會重命名新的aof文件為appendonly.aof,此后所有的操作都將被寫入新的aof文件。如果在rewrite過程中，出現(xiàn)故障，將不會影響原AOF文件的正常工作，只有當(dāng)rewrite完成之后才會切換文件，因為rewrite過程是比較可靠的。*
觸發(fā)rewrite的時機(jī)可以通過配置文件來聲明，同時redis中可以通過bgrewriteaof指令人工干預(yù)。
redis-cli -h ip -p port bgrewriteaof11因為rewrite操作/aof記錄同步/snapshot都消耗磁盤IO，redis采取了“schedule”策略：無論是“人工干預(yù)”還是系統(tǒng)觸發(fā)，snapshot和rewrite需要逐個被執(zhí)行。
AOF rewrite過程并不阻塞客戶端請求。系統(tǒng)會開啟一個子進(jìn)程來完成。
三.總結(jié)：
AOF和RDB各有優(yōu)缺點(diǎn)，這是有它們各自的特點(diǎn)所決定：
1) AOF更加安全，可以將數(shù)據(jù)更加及時的同步到文件中，但是AOF需要較多的磁盤IO開支，AOF文件尺寸較大，文件內(nèi)容恢復(fù)數(shù)度相對較慢。 *2) snapshot，安全性較差，它是“正常時期”數(shù)據(jù)備份以及master-slave數(shù)據(jù)同步的最佳手段，文件尺寸較小，恢復(fù)數(shù)度較快。可以通過配置文件來指定它們中的一種，或者同時使用它們(不建議同時使用)，或者全部禁用，在架構(gòu)良好的環(huán)境中，master通常使用AOF，slave使用snapshot，主要原因是master需要首先確保數(shù)據(jù)完整性，它作為數(shù)據(jù)備份的第一選擇；slave提供只讀服務(wù)(目前slave只能提供讀取服務(wù))，它的主要目的就是快速響應(yīng)客戶端read請求；但是如果你的redis運(yùn)行在網(wǎng)絡(luò)穩(wěn)定性差/物理環(huán)境糟糕情況下，建議你master和slave均采取AOF，這個在master和slave角色切換時，可以減少“人工數(shù)據(jù)備份”/“人工引導(dǎo)數(shù)據(jù)恢復(fù)”的時間成本；如果你的環(huán)境一切非常良好，且服務(wù)需要接收密集性的write操作，那么建議master采取snapshot，而slave采用AOF。
