摘要：上一篇文章實(shí)戰(zhàn)第四章數(shù)據(jù)安全與性能保障第節(jié)持久化選項(xiàng)下一篇文章實(shí)戰(zhàn)第四章數(shù)據(jù)安全與性能保障第節(jié)持久化可以通過創(chuàng)建快照來獲得存儲(chǔ)在內(nèi)存里面的數(shù)據(jù)在某個(gè)時(shí)間點(diǎn)上的副本。

上一篇文章：Python--Redis實(shí)戰(zhàn)：第四章：數(shù)據(jù)安全與性能保障：第1節(jié)：持久化選項(xiàng)
下一篇文章：Python--Redis實(shí)戰(zhàn)：第四章：數(shù)據(jù)安全與性能保障：第3節(jié)：AOF持久化

Redis可以通過創(chuàng)建快照來獲得存儲(chǔ)在內(nèi)存里面的數(shù)據(jù)在某個(gè)時(shí)間點(diǎn)上的副本。在創(chuàng)建快照之后，用戶可以對快照進(jìn)行備份，可以將快照復(fù)制到其它服務(wù)器從而創(chuàng)建具有相同數(shù)據(jù)的服務(wù)器副本，還可以將快照留在原地以便重啟服務(wù)器時(shí)使用。

根據(jù)配置，快照將被寫入dbfilename選項(xiàng)指定的文件里面，并存儲(chǔ)在dir選項(xiàng)指定的路徑上面。如果在新的快照文件創(chuàng)建成功之前，Redis、系統(tǒng)或者硬件上三者之中的任意一個(gè)崩潰了，那么Redis將丟失最近一次創(chuàng)建快照之后寫入的所有數(shù)據(jù)。

舉個(gè)例子，假設(shè)Redis目前在內(nèi)存里面存儲(chǔ)了10GB的數(shù)據(jù)，上一個(gè)快照是在下午2：35開始創(chuàng)建的，并且已經(jīng)創(chuàng)建成功。下午3：06時(shí)，Redis又開始創(chuàng)建新的快照，并且在下午3：08快照文件創(chuàng)建完畢之前，有35個(gè)鍵進(jìn)行了更新。如果在下午3：06至3：08期間，系統(tǒng)發(fā)生崩潰，導(dǎo)致Redis無法完成新快照的創(chuàng)建工作，那么Redis將丟失下午2：35之后寫入的所有數(shù)據(jù)。

創(chuàng)建快照的辦法有以下幾種：

客戶端可以通過向Redis發(fā)送bgsave命令創(chuàng)建一個(gè)快照。對于支持bgsave命令的平臺來說（基本上所有的平臺都支持，除了Windows平臺），Redis會(huì)調(diào)用fork來創(chuàng)建一個(gè)子進(jìn)程，然后子進(jìn)程負(fù)責(zé)將快照寫入硬盤，而父進(jìn)程則繼續(xù)處理命令請求。

fork：當(dāng)一個(gè)進(jìn)程創(chuàng)建子進(jìn)程的時(shí)候，底層的操作系統(tǒng)會(huì)創(chuàng)建該進(jìn)程的一個(gè)副本。在Unix和類Unix系統(tǒng)上面，創(chuàng)建子進(jìn)程的操作會(huì)進(jìn)行如下優(yōu)化：在剛開始的時(shí)候，父進(jìn)程共享相同的內(nèi)存，直到父進(jìn)程或者子進(jìn)程對內(nèi)存進(jìn)行了寫入之后，寫入內(nèi)存的共享才會(huì)結(jié)束。

客戶端還可以通過向Redis發(fā)singsave命令來創(chuàng)建一個(gè)快照，接到save命令的Redis服務(wù)器在快照創(chuàng)建完畢之前將不再響應(yīng)任何其他命令。save命令并不常用，我們通常只會(huì)在沒有足夠內(nèi)存去執(zhí)行bgsave命令的情況下，又或者即使等待持久化操作執(zhí)行完畢也無所謂的情況下，才會(huì)使用這個(gè)命令。

如果用戶設(shè)置了save配置選項(xiàng)，比如save 60 10000，那么從Redis最近一次創(chuàng)建快照之后開始算起，當(dāng)【60秒之內(nèi)有10 000次寫入】這個(gè)條件滿足時(shí)，Redis就會(huì)自動(dòng)觸發(fā)bgsave命令。如果用戶設(shè)置了多個(gè)save配置選項(xiàng)，那么當(dāng)任意一個(gè)save的配置選項(xiàng)所設(shè)置的條件被滿足時(shí)，Redis就會(huì)觸發(fā)一次bgsave命令。

當(dāng)Redis通過shutdown命令接收到關(guān)閉服務(wù)器的請求時(shí)，或者接受到標(biāo)準(zhǔn)term信號時(shí)，會(huì)執(zhí)行一個(gè)save命令，阻塞所有客戶端，不再執(zhí)行客戶端發(fā)送的任何命令，并在save命令執(zhí)行完畢之后關(guān)閉服務(wù)器。

當(dāng)一個(gè)Redis服務(wù)器連接另一個(gè)Redis服務(wù)器，并向?qū)Ψ桨l(fā)送sync命令來開始一次復(fù)制操作的時(shí)候，如果主服務(wù)器目前沒有在執(zhí)行bgsave操作，或者主服務(wù)器并非剛剛執(zhí)行完bgsave操作，那么主服務(wù)器就會(huì)執(zhí)行bgsave命令。

在只使用快照持久化來保存數(shù)據(jù)時(shí)，一定要記住：如果系統(tǒng)真的發(fā)生崩潰，用戶將丟失最近一次生成快照之后更改的所有數(shù)據(jù)。因此，快照持久化只適用于那些丟失一部分?jǐn)?shù)據(jù)也不會(huì)造成問題的應(yīng)用程序，而不能接受這種數(shù)據(jù)損失的應(yīng)用程序則可以考慮使用AOF持久化。接下來將展示幾個(gè)使用快照持久化的場景，讀者可以從中學(xué)習(xí)到如何通過修改配置來獲得資金想要的快照持久化的行為。

在個(gè)人開發(fā)服務(wù)器上面，我主要考慮的是盡可能地降低快照持久化帶來的資源消耗。基于這個(gè)原因以及對自己硬件的信任，我只設(shè)置了save 900 1這一條規(guī)則。其中save 選項(xiàng)告知Redis，它應(yīng)該根據(jù)這個(gè)選項(xiàng)提供的兩個(gè)值來執(zhí)行bgsave操作。在這個(gè)規(guī)則設(shè)置下，如果服務(wù)器距離上次成功生成快照超過了900秒（15分鐘），并且在運(yùn)行期間執(zhí)行了至少一次寫入操作，那么Redis久自動(dòng)開始一次新的bgsave操作。

如果你打算在生產(chǎn)服務(wù)器中使用快照持久化并存儲(chǔ)大量數(shù)據(jù)，那么你的開發(fā)服務(wù)器最好能夠運(yùn)行在與生產(chǎn)服務(wù)器相同或者相似的硬件上面，并在這兩個(gè)服務(wù)器上使用相同的save選項(xiàng)、存儲(chǔ)相似的數(shù)據(jù)集并處理相似的負(fù)載量。把開發(fā)環(huán)境設(shè)置得盡量貼近生產(chǎn)環(huán)境，有助于判斷快照是否生成的過于頻繁或者稀少。過于頻繁會(huì)浪費(fèi)資源，過于稀少則帶有丟失大量數(shù)據(jù)的隱患。

在對日志文件進(jìn)行聚合計(jì)算或者對頁面瀏覽量進(jìn)行分析的時(shí)候，我們需要唯一考慮的就是：如果Redis因?yàn)楸罎⒍茨艹晒?chuàng)建新的快照，那么我們能夠承受丟失多長時(shí)間以內(nèi)產(chǎn)生的新數(shù)據(jù)。如果丟失一個(gè)小時(shí)之內(nèi)產(chǎn)生的數(shù)據(jù)是可以接受的，那么可以使用配置值save 3600 1（3600秒為1小時(shí)）。在決定好了持久化配置值之后，另一個(gè)需要解決的問題就是如何恢復(fù)因?yàn)楣收隙唤K端的日志處理操作。

在進(jìn)行數(shù)據(jù)恢復(fù)時(shí)，首先要做的就是弄清楚我們丟失了哪些數(shù)據(jù)。為了弄明白這一點(diǎn)，我們需要在處理日志的同時(shí)記錄被處理日志的相關(guān)信息。

下面代碼展示了一個(gè)用于處理新日志的函數(shù)，該函數(shù)有3個(gè)參數(shù)，他們分別是：一個(gè)Redis鏈接；一個(gè)存儲(chǔ)日志文件的路徑；待處理日志文件中各個(gè)行（line）的回調(diào)函數(shù)。這個(gè)函數(shù)可以在處理日志文件的同時(shí)，記錄被處理的日志文件的名字以及偏移量。

import os

import redis  # 導(dǎo)入redis包包

#日志處理函數(shù)接收的其中以惡搞參數(shù)為回調(diào)函數(shù)
#這個(gè)回調(diào)函數(shù)接收一個(gè)Redis連接和一個(gè)日志行作為參數(shù)，
#并通過調(diào)用流水線呢對象的方法來執(zhí)行Redis命令
def process_log(conn,path,callback):
    #獲取文件當(dāng)前的處理進(jìn)度
    current_file,offset=conn.mget("progress.file","progress.position")
    pipe=conn.pipeline()

    #通過使用閉包（closur）來減少重復(fù)代碼
    def update_progress():
        pipe.mset({"progress.file":fname,"progress:position":offset})
        #這個(gè)語句負(fù)責(zé)執(zhí)行實(shí)際的日志更細(xì)操作，并將日志文件的名字和目前的處理器進(jìn)度記錄到Redis里面
        pipe.execute()

    #有序的遍歷各個(gè)日志文件
    for fname in sorted(os.listdir(path)):
        #略過所有已處理的日志文件
        if fname 
通過將日志的處理進(jìn)度記錄到Redis里面，程序可以在系統(tǒng)崩潰之后，根據(jù)進(jìn)度記錄繼續(xù)執(zhí)行之前未完成的處理工作。而通過事務(wù)流水線，程序保證日志的處理結(jié)果和處理進(jìn)度總是會(huì)同時(shí)被記錄到快照文件里面。
大數(shù)據(jù)
在Redis存儲(chǔ)的數(shù)據(jù)量只有幾個(gè)GB的時(shí)候，使用快照來保存數(shù)據(jù)是沒有問題的。Redis會(huì)創(chuàng)建子進(jìn)程并將數(shù)據(jù)保存到硬盤里面，生成快照需要的時(shí)間比你讀這句話的時(shí)間還要短。隨著Redis占用的內(nèi)存越來越多，bgsave在創(chuàng)建子進(jìn)程時(shí)耗費(fèi)的時(shí)間越來越多。如果Redis的內(nèi)存占用量達(dá)到數(shù)十個(gè)GB，并且剩余的空閑內(nèi)存并不多，或者Redis運(yùn)行在虛擬機(jī)上面，那么執(zhí)行bgsave可能會(huì)導(dǎo)致系統(tǒng)長時(shí)間地停頓，也可能引發(fā)系統(tǒng)大量地使用虛擬內(nèi)存，從而導(dǎo)致Redis的性能降低至無法使用的程度。
執(zhí)行bgsave而導(dǎo)致的挺短時(shí)間有多長取決于Redis所在的系統(tǒng)：對于真實(shí)的硬件，vmware虛擬機(jī)或者KVM虛擬機(jī)來說，Redis進(jìn)行每占用一個(gè)GB的內(nèi)存，創(chuàng)建該進(jìn)程的子進(jìn)程所需的時(shí)間就要增加10~20毫秒，而對于Xen虛擬機(jī)來說，根究配置的不同，Redis進(jìn)程每占用一個(gè)GB的內(nèi)存，創(chuàng)建該進(jìn)程的子進(jìn)程所需的時(shí)間就要增加200~300毫秒。因此，如果我們的Redis進(jìn)程占用了20GB的內(nèi)存，那么在標(biāo)準(zhǔn)硬件上運(yùn)行bgsave所創(chuàng)建的子進(jìn)程將導(dǎo)致Reeis停頓200~400毫秒，如果我們使用的是Xen虛擬機(jī)（亞馬遜EC2和其他幾個(gè)云計(jì)算供應(yīng)商都使用這種虛擬機(jī)），那么相同的創(chuàng)建子進(jìn)程操作將導(dǎo)致Redis停頓4~6秒。用戶必須考慮自己的應(yīng)用程序能否接受這種停頓。
為了防止Redeis因?yàn)閯?chuàng)建子進(jìn)程而出現(xiàn)停頓，我們可以考慮關(guān)閉自動(dòng)保存呢，轉(zhuǎn)而通過手動(dòng)發(fā)送bgsave或者save來進(jìn)行持久化。手動(dòng)發(fā)送bgsave一樣會(huì)引起停頓，唯一不同的是用戶可以控制停頓出現(xiàn)的時(shí)間。另一方面，雖然save會(huì)一直阻塞Redis知道快照生產(chǎn)完畢，但是因?yàn)樗恍枰獎(jiǎng)?chuàng)建子進(jìn)程，所以就不會(huì)像bgsave一樣因?yàn)閯?chuàng)建子進(jìn)程而導(dǎo)致Redis停頓；并且因?yàn)闆]有子進(jìn)程在爭搶資源，所以save創(chuàng)建快照的速度比bgsave創(chuàng)建快照的速度要快一些。
根據(jù)個(gè)人經(jīng)驗(yàn)，在一臺擁有68GB內(nèi)存的Xen虛擬機(jī)上面，對一個(gè)占用50GB內(nèi)存的Redis服務(wù)器執(zhí)行bgsave命令的話，光是創(chuàng)建子進(jìn)程就需要花費(fèi)15秒以上，而生成快照則需要花費(fèi)15~20分鐘；但使用save值需要3~5分鐘就可以完成快照的生成工作。因?yàn)榈膽?yīng)用程序只需要每天生成一次快照，所以我寫了一個(gè)腳本，讓它在每天凌晨3點(diǎn)停止所有客戶端對Redis的訪問，調(diào)用save命令并等待該命令執(zhí)行完畢，之后備份剛剛生成的快照文件，并通知客戶端繼續(xù)執(zhí)行操作。
如果用戶能夠妥善地處理快照持久化可能會(huì)帶來的大量數(shù)據(jù)丟失，那么快照持久化對用戶來說將使一個(gè)不錯(cuò)的選擇，但對于很多用于程序來說，丟失15分鐘、1小時(shí)甚至更長時(shí)間的數(shù)據(jù)都是不可接受的，在這種情況情況下，我們可以使用AOF持久化來將存儲(chǔ)在內(nèi)存里面的數(shù)據(jù)盡快的保存到硬盤里面。
上一篇文章：Python--Redis實(shí)戰(zhàn)：第四章：數(shù)據(jù)安全與性能保障：第1節(jié)：持久化選項(xiàng)
下一篇文章：Python--Redis實(shí)戰(zhàn)：第四章：數(shù)據(jù)安全與性能保障：第3節(jié)：AOF持久化