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

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

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

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

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

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

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

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

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

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

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

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

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

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

從服務(wù)器在運(yùn)行同步時，會清空自己的所有數(shù)據(jù)：
因為有些用戶在第一次使用從服務(wù)器時會忘記這件事，所以在這里要特別提醒一下：從服務(wù)器在于主服務(wù)器進(jìn)行初始連接時，數(shù)據(jù)庫中原有的所有數(shù)據(jù)將丟失，并被替換成主服務(wù)器發(fā)送來的數(shù)據(jù)。

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

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

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

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

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

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

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

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

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

為了驗證主服務(wù)器是否已經(jīng)將寫數(shù)據(jù)發(fā)送至從服務(wù)器，用戶需要在向主服務(wù)器寫入真正的數(shù)據(jù)之后，再向從服務(wù)器寫入一個唯一的虛構(gòu)值，然后通過驗證虛構(gòu)值是否存在于從服務(wù)器來判斷寫數(shù)據(jù)是否已經(jīng)到達(dá)從服務(wù)器，這個操作很容易就可以實現(xiàn)。另一方面，判斷數(shù)據(jù)是否已經(jīng)被保存到硬盤里面則要困難的多。對于每秒同步一次AOF文件的Redis服務(wù)器來說，用戶總是可以通過等待1秒來確保數(shù)據(jù)已經(jīng)被保存到硬盤里面，但更節(jié)約時間的做法是，檢查info命令的輸出結(jié)果中aof_pending_bio_fsync屬性的值是否為0，如果是的話，那么就表示服務(wù)器已經(jīng)將已知的所有數(shù)據(jù)都保存到硬盤里面了。在向主服務(wù)器寫入數(shù)據(jù)之后，用戶可以將主服務(wù)器和從服務(wù)器的連接作為參數(shù)，調(diào)用下面函數(shù)來能自動進(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ù)、每個數(shù)據(jù)庫包含的鍵的數(shù)量、上一次創(chuàng)建快照文件之后執(zhí)行的命令數(shù)量、等待。總的來說，info命令對于了解Redis服務(wù)器的綜合狀態(tài)非常有幫助，網(wǎng)上有很多資源對info命令進(jìn)行了詳細(xì)的介紹。

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