摘要：上一篇文章實(shí)戰(zhàn)第四章數(shù)據(jù)安全與性能保障第節(jié)持久化下一篇文章實(shí)戰(zhàn)第四章數(shù)據(jù)安全與性能保障第節(jié)處理系統(tǒng)故障對(duì)于有擴(kuò)展平臺(tái)以適應(yīng)更高負(fù)載經(jīng)驗(yàn)的工程師和管理員來說，復(fù)制是不可或缺的。

上一篇文章：Python--Redis實(shí)戰(zhàn)：第四章：數(shù)據(jù)安全與性能保障：第3節(jié)：AOF持久化
下一篇文章：Python--Redis實(shí)戰(zhàn)：第四章：數(shù)據(jù)安全與性能保障：第5節(jié)：處理系統(tǒng)故障

對(duì)于有擴(kuò)展平臺(tái)以適應(yīng)更高負(fù)載經(jīng)驗(yàn)的工程師和管理員來說，復(fù)制(replication)是不可或缺的。復(fù)制可以讓其他服務(wù)器擁有一個(gè)不斷地更新的數(shù)據(jù)副本，從而使得擁有數(shù)據(jù)副本的服務(wù)器可以用于處理客戶端發(fā)送的讀請(qǐng)求，。關(guān)系數(shù)據(jù)庫(kù)通常會(huì)使用一個(gè)主服務(wù)器（

master）向多個(gè)從服務(wù)器（slave）發(fā)送更新，并使用從服務(wù)器來處理所有讀請(qǐng)求。Redis也采用了同樣的方法來實(shí)現(xiàn)自己的復(fù)制特性，并將其用作擴(kuò)展性能的一種手段。本節(jié)將對(duì)Redis的復(fù)制配置選項(xiàng)進(jìn)行討論，并說明Redis在進(jìn)行復(fù)制的各個(gè)步驟。

盡管Redis的性能的非常優(yōu)秀，但它也會(huì)遇上沒辦法快速的處理請(qǐng)求的情況，特別是在對(duì)集合和有序集合進(jìn)行操作的時(shí)候，涉及的元素可能會(huì)有上萬(wàn)個(gè)甚至上百萬(wàn)個(gè)，在這種情況下，執(zhí)行操作所花費(fèi)的時(shí)間可能需要以秒來進(jìn)行計(jì)算，而不是毫秒或者微妙。但即使一個(gè)命令值需要花費(fèi)10毫秒就能完成，單個(gè)Redis實(shí)例1秒也只能處理100個(gè)命令。

sunionstore命令的性能：
作為對(duì)Redis性能的一個(gè)參考，在主頻為2.4GHz的英特爾酷睿2處理器上，對(duì)兩個(gè)分別包含10 000個(gè)元素的集合執(zhí)行sunionstore命令并產(chǎn)生一個(gè)包含20 000個(gè)元素的結(jié)果集合，需要花費(fèi)Redis七八毫秒的時(shí)間。

在需要擴(kuò)展讀請(qǐng)求的時(shí)候，或者在需要寫入臨時(shí)數(shù)據(jù)的時(shí)候，用戶可以通過設(shè)置額外的Redis【從服務(wù)器】來保存數(shù)據(jù)集的副本。在接受到主服務(wù)器發(fā)送的數(shù)據(jù)初始副本（initial copy of data）之后，客戶端每次向【主服務(wù)器】進(jìn)行寫入時(shí)，【從服務(wù)器】都會(huì)實(shí)時(shí)地得到更新。在部署好主從服務(wù)器之后，客戶端就可以向任意一個(gè)服務(wù)器發(fā)送讀請(qǐng)求了，而不必再像之前一樣，總是把每個(gè)讀請(qǐng)求都發(fā)送給主服務(wù)器（客戶端通常會(huì)隨機(jī)地選擇使用哪個(gè)從服務(wù)器，從而將負(fù)載平均分配到各個(gè)從服務(wù)器上）。

接下來將介紹配置Redis主從服務(wù)器的方法，并說明Redis在整個(gè)復(fù)制過程中所做的各項(xiàng)操作。

之前介紹過，當(dāng)從服務(wù)器連接主服務(wù)器的時(shí)候，主服務(wù)器會(huì)執(zhí)行bgsave操作。因此為了正確的使用復(fù)制特性，用戶需要保證主服務(wù)已經(jīng)正確的配置了dir選項(xiàng)和dbfilename選項(xiàng)，并且這兩個(gè)選項(xiàng)所指示的路徑和文件對(duì)于Redis進(jìn)程來說都是可寫的。

盡管有多個(gè)不同的選項(xiàng)可以控制從服務(wù)器自身的行為，但開啟從服務(wù)器所必須的選項(xiàng)只有slaveof一個(gè)。如果用戶在啟動(dòng)Redis服務(wù)器的時(shí)候，指定了一個(gè)包含slaveof host port選項(xiàng)的配置文件，那么Redis服務(wù)器將根據(jù)該選項(xiàng)給定的IP地址和端口號(hào)來連接主服務(wù)器。對(duì)于一個(gè)正在運(yùn)行的Redis服務(wù)器，用戶可以通過發(fā)送slaveof no one命令來讓服務(wù)器終止復(fù)制操作，不再接受主服務(wù)器的數(shù)據(jù)更新，也可以通過發(fā)送slaveof host port命令來讓服務(wù)器開始復(fù)制一個(gè)新的主服務(wù)器。

開啟Redis的主從復(fù)制特性并不需要進(jìn)行太多的配置，但了解Redis服務(wù)器是如何變成主服務(wù)器或者從服務(wù)器的，對(duì)于我們來說將是非常有用和有趣的過程。

上面曾將說過，從服務(wù)器在連接一個(gè)主服務(wù)器的時(shí)候，主服務(wù)器會(huì)創(chuàng)建一個(gè)快照文件并將其發(fā)送至從服務(wù)器，但這只是主從復(fù)制執(zhí)行的其中一步，下表完整的列出了當(dāng)從服務(wù)器連接主服務(wù)器時(shí)，主從服務(wù)器執(zhí)行的所有操作：

Redis在復(fù)制進(jìn)行期間也會(huì)盡可能地處理接受到的命令請(qǐng)求，但是，如果主從服務(wù)器之間的網(wǎng)絡(luò)帶寬不足，或者主服務(wù)器沒有足夠的內(nèi)存來創(chuàng)建子進(jìn)程和創(chuàng)建記錄寫命令的緩沖區(qū)，那么Redis處理命令請(qǐng)求的效率會(huì)受到影響。因此，盡管這并不是必需的，但在實(shí)際中華最好還是讓主服務(wù)器只使用50%~65%的內(nèi)存，預(yù)留30%~45%內(nèi)存用于執(zhí)行bgsave命令和創(chuàng)建記錄寫命令的緩沖區(qū)。

設(shè)置從服務(wù)器的步驟非常簡(jiǎn)單，用戶既可以通過配置選項(xiàng)slaveof host port來將一個(gè)Redis服務(wù)器設(shè)置為從服務(wù)器，又可以通過向運(yùn)行中的Redis服務(wù)器發(fā)送slaveof命令來將其設(shè)置為從服務(wù)。如果用戶使用的是slaveof配置選項(xiàng)，那么Redis在啟動(dòng)時(shí)首先載入當(dāng)前可用的任何快照問價(jià)或者AOF文件，然后連接主服務(wù)并執(zhí)行上表的復(fù)制過程。如果用戶使用的是slaveof命令，那么Redis會(huì)立即嘗試連接主服務(wù)器，并在連接成功后，開始上表所示的復(fù)制過程。

從服務(wù)器在運(yùn)行同步時(shí)，會(huì)清空自己的所有數(shù)據(jù)：
因?yàn)橛行┯脩粼诘谝淮问褂脧姆?wù)器時(shí)會(huì)忘記這件事，所以在這里要特別提醒一下：從服務(wù)器在于主服務(wù)器進(jìn)行初始連接時(shí)，數(shù)據(jù)庫(kù)中原有的所有數(shù)據(jù)將丟失，并被替換成主服務(wù)器發(fā)送來的數(shù)據(jù)。

警告：Redis不支持主主復(fù)制：
因?yàn)镽edis允許用戶在服務(wù)器啟動(dòng)之后使用slaveof命令來設(shè)置從服務(wù)器選項(xiàng)，所以可能會(huì)有讀者誤以為可以通過將兩個(gè)Redis實(shí)例互相設(shè)置為對(duì)方的主服務(wù)器來實(shí)現(xiàn)多主復(fù)制，遺憾的是，這種做法是行不通的：被互相設(shè)置為主服務(wù)器的兩個(gè)Redis實(shí)例只會(huì)持續(xù)的占用大量處理器資環(huán)并持續(xù)不斷的嘗試與對(duì)方進(jìn)行通信，根據(jù)客戶端鏈接的服務(wù)器的不同，客戶端的請(qǐng)求可能會(huì)得到不一致的數(shù)據(jù)或者完全得不到數(shù)據(jù)。

當(dāng)多個(gè)從服務(wù)器嘗試連接同一個(gè)主服務(wù)器的時(shí)候，就會(huì)出現(xiàn)下表所示的兩種情況中的一種：

在大部分情況下，Redis都會(huì)盡可能地減少?gòu)?fù)制所需的工作，然而，如果從服務(wù)器連接主服務(wù)器的時(shí)間并不湊巧，那么主服務(wù)器就需要多做一些額外的工作，。另一方面，當(dāng)多個(gè)從服務(wù)器同時(shí)連接主服務(wù)器的時(shí)候，同步多個(gè)主服務(wù)器所占用的寬帶可能會(huì)使得其他命令請(qǐng)求難以傳遞給主服務(wù)器，與主服務(wù)器位于同一網(wǎng)絡(luò)中的其他硬件的網(wǎng)速可能也會(huì)因此而降低。

有些用戶發(fā)現(xiàn)，創(chuàng)建多個(gè)從服務(wù)器可能或造成網(wǎng)絡(luò)不可用：當(dāng)復(fù)制需要通過互聯(lián)網(wǎng)進(jìn)行或者需要在不同數(shù)據(jù)中心之間進(jìn)行時(shí)，尤為如此。因?yàn)镽edis的主服務(wù)和從服務(wù)器并沒有特別不同的地方，所以從服務(wù)器也可以擁有自己的從服務(wù)器，并由此形成主從鏈。

從服務(wù)器對(duì)從服務(wù)器進(jìn)行復(fù)制在操作上和那個(gè)服務(wù)器對(duì)主服務(wù)器進(jìn)行復(fù)制的唯一區(qū)別在于，如果從服務(wù)器X擁有從服務(wù)器Y，那么當(dāng)從服務(wù)器X在執(zhí)行上節(jié)復(fù)制步驟的步驟4時(shí)，它將斷開與從服務(wù)器Y的連接，導(dǎo)致從服務(wù)器Y需要重新連接并重新同步。

當(dāng)【讀請(qǐng)求】的重要性明顯高于【寫請(qǐng)求】的重要性，并且讀請(qǐng)求的數(shù)量遠(yuǎn)遠(yuǎn)超出一臺(tái)Redis服務(wù)器可以處理的范圍時(shí)，用戶就需要添加新的從服務(wù)器來處理【讀請(qǐng)求】。隨著負(fù)載不斷上升，主服務(wù)器可能會(huì)無法快速地更新所有從服務(wù)器，或者因?yàn)橹匦逻B接和重新同步從服務(wù)器而導(dǎo)致系統(tǒng)超載。為了緩解這個(gè)問題，用戶可以創(chuàng)建一個(gè)由Redis主從節(jié)點(diǎn)組成的中間層來分擔(dān)主服務(wù)器的復(fù)制工作。如下圖所示：

一個(gè)Redis主從復(fù)制樹示例，樹的中層有3個(gè)幫助開展復(fù)制工作的服務(wù)器，底層與9個(gè)從服務(wù)器。

盡管主從服務(wù)器之間并不一定要像上圖那樣組成一個(gè)樹狀結(jié)構(gòu)，但記住并理解這種樹狀結(jié)構(gòu)對(duì)于Redis復(fù)制來說是可行的并且是合理的，有主于讀者理解之后的內(nèi)容。AOF持久化的同步選項(xiàng)可以控制數(shù)據(jù)丟失的時(shí)間長(zhǎng)度：通過將每個(gè)寫命令同步到硬盤里面，用戶幾乎可以不損失任何數(shù)據(jù)（除非系統(tǒng)崩潰或者硬盤驅(qū)動(dòng)器損壞），但這種做法會(huì)對(duì)服務(wù)器的性能造成影響；另一方面，如果用戶將同步的頻率設(shè)置為每秒一次，那么服務(wù)器的性能將回到正常水平，但故障可能會(huì)造成1秒的數(shù)據(jù)損失。通過同時(shí)使用復(fù)制和AOF持久化，我們可以將數(shù)據(jù)持久化到多臺(tái)服務(wù)器上面。

為了將數(shù)據(jù)保存到多臺(tái)服務(wù)器上面，用戶首先需要為主服務(wù)器設(shè)置多個(gè)從服務(wù)器，然后對(duì)每個(gè)從服務(wù)設(shè)置appendonly yes選項(xiàng)和sppendonly everysec選項(xiàng)（如果有需要得我話，也可以對(duì)主服務(wù)器進(jìn)行相同的設(shè)置），這樣的話，用戶就可以讓多臺(tái)服務(wù)器以每秒1次的頻率將數(shù)據(jù)同步到硬盤上了，但這還只是第一步：因?yàn)橛脩暨€必須等待主服務(wù)器發(fā)送的寫命令到達(dá)從服務(wù)器，并且在執(zhí)行后續(xù)操作之前，檢查數(shù)據(jù)是否已經(jīng)被同步到硬盤里面。

為了驗(yàn)證主服務(wù)器是否已經(jīng)將寫數(shù)據(jù)發(fā)送至從服務(wù)器，用戶需要在向主服務(wù)器寫入真正的數(shù)據(jù)之后，再向從服務(wù)器寫入一個(gè)唯一的虛構(gòu)值，然后通過驗(yàn)證虛構(gòu)值是否存在于從服務(wù)器來判斷寫數(shù)據(jù)是否已經(jīng)到達(dá)從服務(wù)器，這個(gè)操作很容易就可以實(shí)現(xiàn)。另一方面，判斷數(shù)據(jù)是否已經(jīng)被保存到硬盤里面則要困難的多。對(duì)于每秒同步一次AOF文件的Redis服務(wù)器來說，用戶總是可以通過等待1秒來確保數(shù)據(jù)已經(jīng)被保存到硬盤里面，但更節(jié)約時(shí)間的做法是，檢查info命令的輸出結(jié)果中aof_pending_bio_fsync屬性的值是否為0，如果是的話，那么就表示服務(wù)器已經(jīng)將已知的所有數(shù)據(jù)都保存到硬盤里面了。在向主服務(wù)器寫入數(shù)據(jù)之后，用戶可以將主服務(wù)器和從服務(wù)器的連接作為參數(shù)，調(diào)用下面函數(shù)來能自動(dòng)進(jìn)行上述的檢查操作。

import time
import uuid


def wait_for_sync(mconn,sconn):
    identifier=str(uuid.uuid4())
    #將令牌添加至主服務(wù)器
    mconn.zadd("sync:wait",identifier,time.time())

    #如果有必要的話，等待從服務(wù)器完成同步
    while not sconn.info()["master_lin_status"]!="up":
        time.sleep(.001)

    #等待從服務(wù)器接收數(shù)據(jù)更新
    while not sconn.zscore("sync:wait",identifier):
        time.sleep(.001)

    deadline=time.time()+1.01
    #最多只等待一秒
    while time.time()
info命令中的其他信息：
info命令提供了大量的與Redis服務(wù)器當(dāng)前狀態(tài)相關(guān)的信息，比如內(nèi)存占用量、客戶端連接數(shù)、每個(gè)數(shù)據(jù)庫(kù)包含的鍵的數(shù)量、上一次創(chuàng)建快照文件之后執(zhí)行的命令數(shù)量、等待?？偟膩碚f，info命令對(duì)于了解Redis服務(wù)器的綜合狀態(tài)非常有幫助，網(wǎng)上有很多資源對(duì)info命令進(jìn)行了詳細(xì)的介紹。

為了確保操作可以正確執(zhí)行，上面函數(shù)會(huì)首先確認(rèn)從服務(wù)器已經(jīng)連接上主服務(wù)器，然后檢查自己添加到等待同步有序集合里面的值是否已經(jīng)存在于從服務(wù)器。在發(fā)現(xiàn)值已經(jīng)存在于從服務(wù)器之后，函數(shù)會(huì)檢查從服務(wù)器寫入緩沖區(qū)的狀態(tài)，并在一秒之內(nèi)，等待從服務(wù)器將緩沖區(qū)中的所有數(shù)據(jù)寫入硬盤里面。雖然函數(shù)最多會(huì)花費(fèi)1秒來等待同步完成，但實(shí)際上大部分同步都會(huì)在很短的時(shí)間完成。最后，在確認(rèn)數(shù)據(jù)已經(jīng)被保存到硬盤之后，函數(shù)會(huì)執(zhí)行一些清理操作。
通過同步使用復(fù)制和AOF持久化，用戶可以增強(qiáng)Redis對(duì)于系統(tǒng)崩潰的抵抗能力。
上一篇文章：Python--Redis實(shí)戰(zhàn)：第四章：數(shù)據(jù)安全與性能保障：第3節(jié)：AOF持久化
下一篇文章：Python--Redis實(shí)戰(zhàn)：第四章：數(shù)據(jù)安全與性能保障：第5節(jié)：處理系統(tǒng)故障