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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在對日志文件進行聚合計算或者對頁面瀏覽量進行分析的時候，我們需要唯一考慮的就是：如果Redis因為崩潰而未能成功創(chuàng)建新的快照，那么我們能夠承受丟失多長時間以內(nèi)產(chǎn)生的新數(shù)據(jù)。如果丟失一個小時之內(nèi)產(chǎn)生的數(shù)據(jù)是可以接受的，那么可以使用配置值save 3600 1（3600秒為1小時）。在決定好了持久化配置值之后，另一個需要解決的問題就是如何恢復(fù)因為故障而被終端的日志處理操作。

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

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

import os

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

#日志處理函數(shù)接收的其中以惡搞參數(shù)為回調(diào)函數(shù)
#這個回調(diào)函數(shù)接收一個Redis連接和一個日志行作為參數(shù)，
#并通過調(diào)用流水線呢對象的方法來執(zhí)行Redis命令
def process_log(conn,path,callback):
    #獲取文件當前的處理進度
    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})
        #這個語句負責(zé)執(zhí)行實際的日志更細操作，并將日志文件的名字和目前的處理器進度記錄到Redis里面
        pipe.execute()

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