1 主從復(fù)制概述
主從復(fù)制，是指將一臺Redis服務(wù)器的數(shù)據(jù)，復(fù)制到其他的Redis服務(wù)器。前者稱為主節(jié)點(master)，后者稱為從節(jié)點(slave)；數(shù)據(jù)的復(fù)制是單向的，只能由主節(jié)點到從節(jié)點。
默認情況下，每臺Redis服務(wù)器都是主節(jié)點；且一個主節(jié)點可以有多個從節(jié)點(或沒有從節(jié)點)，但一個從節(jié)點只能有一個主節(jié)點。
主從復(fù)制的作用
主從復(fù)制的作用主要包括：
數(shù)據(jù)冗余：主從復(fù)制實現(xiàn)了數(shù)據(jù)的熱備份，是持久化之外的一種數(shù)據(jù)冗余方式。
故障恢復(fù)：當主節(jié)點出現(xiàn)問題時，可以由從節(jié)點提供服務(wù)，實現(xiàn)快速的故障恢復(fù)；實際上是一種服務(wù)的冗余。
負載均衡：在主從復(fù)制的基礎(chǔ)上，配合讀寫分離，可以由主節(jié)點提供寫服務(wù)，由從節(jié)點提供讀服務(wù)（即寫Redis數(shù)據(jù)時應(yīng)用連接主節(jié)點，讀Redis數(shù)據(jù)時應(yīng)用連接從節(jié)點），分擔服務(wù)器負載；尤其是在寫少讀多的場景下，通過多個從節(jié)點分擔讀負載，可以大大提高Redis服務(wù)器的并發(fā)量。
高可用基石：除了上述作用以外，主從復(fù)制還是哨兵和集群能夠?qū)嵤┑幕A(chǔ)，因此說主從復(fù)制是Redis高可用的基礎(chǔ)。
2 如何使用主從復(fù)制
為了更直觀的理解主從復(fù)制，在介紹其內(nèi)部原理之前，先說明我們需要如何操作才能開啟主從復(fù)制。
2.1 建立復(fù)制
需要注意，主從復(fù)制的開啟，完全是在從節(jié)點發(fā)起的，不需要我們在主節(jié)點做任何事情。
從節(jié)點開啟主從復(fù)制，有3種方式：
（1）配置文件
在從服務(wù)器的配置文件中加入：slaveof <masterip> <masterport>
（2）啟動命令
redis-server啟動命令后加入 --slaveof <masterip> <masterport>
（3）客戶端命令
Redis服務(wù)器啟動后，直接通過客戶端執(zhí)行命令：slaveof <masterip> <masterport>，則該Redis實例成為從節(jié)點。
上述3種方式是等效的，下面以客戶端命令的方式為例，看一下當執(zhí)行了slaveof后，Redis主節(jié)點和從節(jié)點的變化。
2.2 實例
2.2.1準備工作：啟動兩個節(jié)點
方便起見，實驗所使用的主從節(jié)點是在一臺機器上的不同Redis實例，其中主節(jié)點監(jiān)聽6379端口，從節(jié)點監(jiān)聽6380端口；從節(jié)點監(jiān)聽的端口號可以在配置文件中修改：
啟動后可以看到：
兩個Redis節(jié)點啟動后（分別稱為6379節(jié)點和6380節(jié)點），默認都是主節(jié)點。
2.2.2 建立復(fù)制
此時在6380節(jié)點執(zhí)行slaveof命令，使之變?yōu)閺墓?jié)點：
2.2.3 觀察效果
下面驗證一下，在主從復(fù)制建立后，主節(jié)點的數(shù)據(jù)會復(fù)制到從節(jié)點中。
（1）首先在從節(jié)點查詢一個不存在的key：
（2）然后在主節(jié)點中增加這個key：
（3）此時在從節(jié)點中再次查詢這個key，會發(fā)現(xiàn)主節(jié)點的操作已經(jīng)同步至從節(jié)點：
（4）然后在主節(jié)點刪除這個key：
（5）此時在從節(jié)點中再次查詢這個key，會發(fā)現(xiàn)主節(jié)點的操作已經(jīng)同步至從節(jié)點：
2.3 斷開復(fù)制
通過slaveof <masterip> <masterport>命令建立主從復(fù)制關(guān)系以后，可以通過slaveof no one斷開。需要注意的是，從節(jié)點斷開復(fù)制后，不會刪除已有的數(shù)據(jù)，只是不再接受主節(jié)點新的數(shù)據(jù)變化。
從節(jié)點執(zhí)行slaveof no one后，打印日志如下所示；可以看出斷開復(fù)制后，從節(jié)點又變回為主節(jié)點。
主節(jié)點打印日志如下：
3 主從復(fù)制的實現(xiàn)原理
上面一節(jié)中，介紹了如何操作可以建立主從關(guān)系；本小節(jié)將介紹主從復(fù)制的實現(xiàn)原理。
主從復(fù)制過程大體可以分為3個階段：連接建立階段（即準備階段）、數(shù)據(jù)同步階段、命令傳播階段；下面分別進行介紹。
3.1 連接建立階段
該階段的主要作用是在主從節(jié)點之間建立連接，為數(shù)據(jù)同步做好準備。
步驟1：保存主節(jié)點信息
從節(jié)點服務(wù)器內(nèi)部維護了兩個字段，即masterhost和masterport字段，用于存儲主節(jié)點的ip和port信息。
需要注意的是，slaveof是異步命令，從節(jié)點完成主節(jié)點ip和port的保存后，向發(fā)送slaveof命令的客戶端直接返回OK，實際的復(fù)制操作在這之后才開始進行。
這個過程中，可以看到從節(jié)點打印日志如下：
步驟2：建立socket連接
從節(jié)點每秒1次調(diào)用復(fù)制定時函數(shù)replicationCron()，如果發(fā)現(xiàn)了有主節(jié)點可以連接，便會根據(jù)主節(jié)點的ip和port，創(chuàng)建socket連接。如果連接成功，則：
從節(jié)點：為該socket建立一個專門處理復(fù)制工作的文件事件處理器，負責后續(xù)的復(fù)制工作，如接收RDB文件、接收命令傳播等。
主節(jié)點：接收到從節(jié)點的socket連接后（即accept之后），為該socket創(chuàng)建相應(yīng)的客戶端狀態(tài)，并將從節(jié)點看做是連接到主節(jié)點的一個客戶端，后面的步驟會以從節(jié)點向主節(jié)點發(fā)送命令請求的形式來進行。
這個過程中，從節(jié)點打印日志如下：
步驟3：發(fā)送ping命令
從節(jié)點成為主節(jié)點的客戶端之后，發(fā)送ping命令進行首次請求，目的是：檢查socket連接是否可用，以及主節(jié)點當前是否能夠處理請求。
從節(jié)點發(fā)送ping命令后，可能出現(xiàn)3種情況：
（1）返回pong：說明socket連接正常，且主節(jié)點當前可以處理請求，復(fù)制過程繼續(xù)。
（2）超時：一定時間后從節(jié)點仍未收到主節(jié)點的回復(fù)，說明socket連接不可用，則從節(jié)點斷開socket連接，并重連。
（3）返回pong以外的結(jié)果：如果主節(jié)點返回其他結(jié)果，如正在處理超時運行的腳本，說明主節(jié)點當前無法處理命令，則從節(jié)點斷開socket連接，并重連。
在主節(jié)點返回pong情況下，從節(jié)點打印日志如下：
步驟4：身份驗證
如果從節(jié)點中設(shè)置了masterauth選項，則從節(jié)點需要向主節(jié)點進行身份驗證；沒有設(shè)置該選項，則不需要驗證。從節(jié)點進行身份驗證是通過向主節(jié)點發(fā)送auth命令進行的，auth命令的參數(shù)即為配置文件中的masterauth的值。
如果主節(jié)點設(shè)置密碼的狀態(tài)，與從節(jié)點masterauth的狀態(tài)一致（一致是指都存在，且密碼相同，或者都不存在），則身份驗證通過，復(fù)制過程繼續(xù)；如果不一致，則從節(jié)點斷開socket連接，并重連。
步驟5：發(fā)送從節(jié)點端口信息
身份驗證之后，從節(jié)點會向主節(jié)點發(fā)送其監(jiān)聽的端口號（前述例子中為6380），主節(jié)點將該信息保存到該從節(jié)點對應(yīng)的客戶端的slave_listening_port字段中；該端口信息除了在主節(jié)點中執(zhí)行info Replication時顯示以外，沒有其他作用。
3.2 數(shù)據(jù)同步階段
主從節(jié)點之間的連接建立以后，便可以開始進行數(shù)據(jù)同步，該階段可以理解為從節(jié)點數(shù)據(jù)的初始化。具體執(zhí)行的方式是：從節(jié)點向主節(jié)點發(fā)送psync命令（Redis2.8以前是sync命令），開始同步。
數(shù)據(jù)同步階段是主從復(fù)制最核心的階段，根據(jù)主從節(jié)點當前狀態(tài)的不同，可以分為全量復(fù)制和部分復(fù)制，下面會有一章專門講解這兩種復(fù)制方式以及psync命令的執(zhí)行過程，這里不再詳述。
需要注意的是，在數(shù)據(jù)同步階段之前，從節(jié)點是主節(jié)點的客戶端，主節(jié)點不是從節(jié)點的客戶端；而到了這一階段及以后，主從節(jié)點互為客戶端。原因在于：在此之前，主節(jié)點只需要響應(yīng)從節(jié)點的請求即可，不需要主動發(fā)請求，而在數(shù)據(jù)同步階段和后面的命令傳播階段，主節(jié)點需要主動向從節(jié)點發(fā)送請求（如推送緩沖區(qū)中的寫命令），才能完成復(fù)制。
3.3 命令傳播階段
數(shù)據(jù)同步階段完成后，主從節(jié)點進入命令傳播階段；在這個階段主節(jié)點將自己執(zhí)行的寫命令發(fā)送給從節(jié)點，從節(jié)點接收命令并執(zhí)行，從而保證主從節(jié)點數(shù)據(jù)的一致性。
在命令傳播階段，除了發(fā)送寫命令，主從節(jié)點還維持著心跳機制：PING和REPLCONF ACK。由于心跳機制的原理涉及部分復(fù)制，因此將在介紹了部分復(fù)制的相關(guān)內(nèi)容后單獨介紹該心跳機制。
延遲與不一致
需要注意的是，命令傳播是異步的過程，即主節(jié)點發(fā)送寫命令后并不會等待從節(jié)點的回復(fù)；因此實際上主從節(jié)點之間很難保持實時的一致性，延遲在所難免。數(shù)據(jù)不一致的程度，與主從節(jié)點之間的網(wǎng)絡(luò)狀況、主節(jié)點寫命令的執(zhí)行頻率、以及主節(jié)點中的repl-disable-tcp-nodelay配置等有關(guān)。
repl-disable-tcp-nodelay no：該配置作用于命令傳播階段，控制主節(jié)點是否禁止與從節(jié)點的TCP_NODELAY；默認no，即不禁止TCP_NODELAY。當設(shè)置為yes時，TCP會對包進行合并從而減少帶寬，但是發(fā)送的頻率會降低，從節(jié)點數(shù)據(jù)延遲增加，一致性變差；具體發(fā)送頻率與Linux內(nèi)核的配置有關(guān)，默認配置為40ms。當設(shè)置為no時，TCP會立馬將主節(jié)點的數(shù)據(jù)發(fā)送給從節(jié)點，帶寬增加但延遲變小。
一般來說，只有當應(yīng)用對Redis數(shù)據(jù)不一致的容忍度較高，且主從節(jié)點之間網(wǎng)絡(luò)狀況不好時，才會設(shè)置為yes；多數(shù)情況使用默認值no。
4 數(shù)據(jù)同步階段全量復(fù)制和部分復(fù)制
在Redis2.8以前，從節(jié)點向主節(jié)點發(fā)送sync命令請求同步數(shù)據(jù)，此時的同步方式是全量復(fù)制；在Redis2.8及以后，從節(jié)點可以發(fā)送psync命令請求同步數(shù)據(jù)，此時根據(jù)主從節(jié)點當前狀態(tài)的不同，同步方式可能是全量復(fù)制或部分復(fù)制。后文介紹以Redis2.8及以后版本為例。
全量復(fù)制：用于初次復(fù)制或其他無法進行部分復(fù)制的情況，將主節(jié)點中的所有數(shù)據(jù)都發(fā)送給從節(jié)點，是一個非常重型的操作。
部分復(fù)制：用于網(wǎng)絡(luò)中斷等情況后的復(fù)制，只將中斷期間主節(jié)點執(zhí)行的寫命令發(fā)送給從節(jié)點，與全量復(fù)制相比更加高效。需要注意的是，如果網(wǎng)絡(luò)中斷時間過長，導(dǎo)致主節(jié)點沒有能夠完整地保存中斷期間執(zhí)行的寫命令，則無法進行部分復(fù)制，仍使用全量復(fù)制。
4.1 全量復(fù)制
Redis通過psync命令進行全量復(fù)制的過程如下：
（1）從節(jié)點判斷無法進行部分復(fù)制，向主節(jié)點發(fā)送全量復(fù)制的請求；或從節(jié)點發(fā)送部分復(fù)制的請求，但主節(jié)點判斷無法進行部分復(fù)制；具體判斷過程需要在講述了部分復(fù)制原理后再介紹。
（2）主節(jié)點收到全量復(fù)制的命令后，執(zhí)行bgsave，在后臺生成RDB文件，并使用一個緩沖區(qū)（稱為復(fù)制緩沖區(qū)）記錄從現(xiàn)在開始執(zhí)行的所有寫命令
（3）主節(jié)點的bgsave執(zhí)行完成后，將RDB文件發(fā)送給從節(jié)點；從節(jié)點首先清除自己的舊數(shù)據(jù)，然后載入接收的RDB文件，將數(shù)據(jù)庫狀態(tài)更新至主節(jié)點執(zhí)行bgsave時的數(shù)據(jù)庫狀態(tài)
（4）主節(jié)點將前述復(fù)制緩沖區(qū)中的所有寫命令發(fā)送給從節(jié)點，從節(jié)點執(zhí)行這些寫命令，將數(shù)據(jù)庫狀態(tài)更新至主節(jié)點的最新狀態(tài)
（5）如果從節(jié)點開啟了AOF，則會觸發(fā)bgrewriteaof的執(zhí)行，從而保證AOF文件更新至主節(jié)點的最新狀態(tài)
下面是執(zhí)行全量復(fù)制時，主從節(jié)點打印的日志；可以看出日志內(nèi)容與上述步驟是完全對應(yīng)的。
主節(jié)點的打印日志如下：
從節(jié)點打印日志如下圖所示：
其中，有幾點需要注意：從節(jié)點接收了來自主節(jié)點的89260個字節(jié)的數(shù)據(jù)；從節(jié)點在載入主節(jié)點的數(shù)據(jù)之前要先將老數(shù)據(jù)清除；從節(jié)點在同步完數(shù)據(jù)后，調(diào)用了bgrewriteaof。
通過全量復(fù)制的過程可以看出，全量復(fù)制是非常重型的操作：
（1）主節(jié)點通過bgsave命令fork子進程進行RDB持久化，該過程是非常消耗CPU、內(nèi)存(頁表復(fù)制)、硬盤IO的；關(guān)于bgsave的性能問題，可以參考 深入學習Redis（2）：持久化
（2）主節(jié)點通過網(wǎng)絡(luò)將RDB文件發(fā)送給從節(jié)點，對主從節(jié)點的帶寬都會帶來很大的消耗
（3）從節(jié)點清空老數(shù)據(jù)、載入新RDB文件的過程是阻塞的，無法響應(yīng)客戶端的命令；如果從節(jié)點執(zhí)行bgrewriteaof，也會帶來額外的消耗
4.2 部分復(fù)制
由于全量復(fù)制在主節(jié)點數(shù)據(jù)量較大時效率太低，因此Redis2.8開始提供部分復(fù)制，用于處理網(wǎng)絡(luò)中斷時的數(shù)據(jù)同步。
部分復(fù)制的實現(xiàn)，依賴于三個重要的概念：
（1）復(fù)制偏移量
主節(jié)點和從節(jié)點分別維護一個復(fù)制偏移量（offset），代表的是主節(jié)點向從節(jié)點傳遞的字節(jié)數(shù)；主節(jié)點每次向從節(jié)點傳播N個字節(jié)數(shù)據(jù)時，主節(jié)點的offset增加N；從節(jié)點每次收到主節(jié)點傳來的N個字節(jié)數(shù)據(jù)時，從節(jié)點的offset增加N。
offset用于判斷主從節(jié)點的數(shù)據(jù)庫狀態(tài)是否一致：如果二者offset相同，則一致；如果offset不同，則不一致，此時可以根據(jù)兩個offset找出從節(jié)點缺少的那部分數(shù)據(jù)。例如，如果主節(jié)點的offset是1000，而從節(jié)點的offset是500，那么部分復(fù)制就需要將offset為501-1000的數(shù)據(jù)傳遞給從節(jié)點。而offset為501-1000的數(shù)據(jù)存儲的位置，就是下面要介紹的復(fù)制積壓緩沖區(qū)。
（2）復(fù)制積壓緩沖區(qū)
復(fù)制積壓緩沖區(qū)是由主節(jié)點維護的、固定長度的、先進先出(FIFO)隊列，默認大小1MB；當主節(jié)點開始有從節(jié)點時創(chuàng)建，其作用是備份主節(jié)點最近發(fā)送給從節(jié)點的數(shù)據(jù)。注意，無論主節(jié)點有一個還是多個從節(jié)點，都只需要一個復(fù)制積壓緩沖區(qū)。
在命令傳播階段，主節(jié)點除了將寫命令發(fā)送給從節(jié)點，還會發(fā)送一份給復(fù)制積壓緩沖區(qū)，作為寫命令的備份；除了存儲寫命令，復(fù)制積壓緩沖區(qū)中還存儲了其中的每個字節(jié)對應(yīng)的復(fù)制偏移量（offset）。由于復(fù)制積壓緩沖區(qū)定長且是先進先出，所以它保存的是主節(jié)點最近執(zhí)行的寫命令；時間較早的寫命令會被擠出緩沖區(qū)。
由于該緩沖區(qū)長度固定且有限，因此可以備份的寫命令也有限，當主從節(jié)點offset的差距過大超過緩沖區(qū)長度時，將無法執(zhí)行部分復(fù)制，只能執(zhí)行全量復(fù)制。反過來說，為了提高網(wǎng)絡(luò)中斷時部分復(fù)制執(zhí)行的概率，可以根據(jù)需要增大復(fù)制積壓緩沖區(qū)的大小(通過配置repl-backlog-size)；例如如果網(wǎng)絡(luò)中斷的平均時間是60s，而主節(jié)點平均每秒產(chǎn)生的寫命令(特定協(xié)議格式)所占的字節(jié)數(shù)為100KB，則復(fù)制積壓緩沖區(qū)的平均需求為6MB，保險起見，可以設(shè)置為12MB，來保證絕大多數(shù)斷線情況都可以使用部分復(fù)制。
從節(jié)點將offset發(fā)送給主節(jié)點后，主節(jié)點根據(jù)offset和緩沖區(qū)大小決定能否執(zhí)行部分復(fù)制：
如果offset偏移量之后的數(shù)據(jù)，仍然都在復(fù)制積壓緩沖區(qū)里，則執(zhí)行部分復(fù)制；
如果offset偏移量之后的數(shù)據(jù)已不在復(fù)制積壓緩沖區(qū)中（數(shù)據(jù)已被擠出），則執(zhí)行全量復(fù)制。
（3）服務(wù)器運行ID(runid)
每個Redis節(jié)點(無論主從)，在啟動時都會自動生成一個隨機ID(每次啟動都不一樣)，由40個隨機的十六進制字符組成；runid用來唯一識別一個Redis節(jié)點。通過info Server命令，可以查看節(jié)點的runid：
主從節(jié)點初次復(fù)制時，主節(jié)點將自己的runid發(fā)送給從節(jié)點，從節(jié)點將這個runid保存起來；當斷線重連時，從節(jié)點會將這個runid發(fā)送給主節(jié)點；主節(jié)點根據(jù)runid判斷能否進行部分復(fù)制：
如果從節(jié)點保存的runid與主節(jié)點現(xiàn)在的runid相同，說明主從節(jié)點之前同步過，主節(jié)點會繼續(xù)嘗試使用部分復(fù)制(到底能不能部分復(fù)制還要看offset和復(fù)制積壓緩沖區(qū)的情況)；
如果從節(jié)點保存的runid與主節(jié)點現(xiàn)在的runid不同，說明從節(jié)點在斷線前同步的Redis節(jié)點并不是當前的主節(jié)點，只能進行全量復(fù)制。
4.3 psync命令的執(zhí)行
在了解了復(fù)制偏移量、復(fù)制積壓緩沖區(qū)、節(jié)點運行id之后，本節(jié)將介紹psync命令的參數(shù)和返回值，從而說明psync命令執(zhí)行過程中，主從節(jié)點是如何確定使用全量復(fù)制還是部分復(fù)制的。
psync命令的執(zhí)行過程可以參見下圖（圖片來源：《Redis設(shè)計與實現(xiàn)》）：
（1）首先，從節(jié)點根據(jù)當前狀態(tài)，決定如何調(diào)用psync命令：
如果從節(jié)點之前未執(zhí)行過slaveof或最近執(zhí)行了slaveof no one，則從節(jié)點發(fā)送命令為psync ? -1，向主節(jié)點請求全量復(fù)制；
如果從節(jié)點之前執(zhí)行了slaveof，則發(fā)送命令為psync <runid> <offset>，其中runid為上次復(fù)制的主節(jié)點的runid，offset為上次復(fù)制截止時從節(jié)點保存的復(fù)制偏移量。
（2）主節(jié)點根據(jù)收到的psync命令，及當前服務(wù)器狀態(tài)，決定執(zhí)行全量復(fù)制還是部分復(fù)制：
如果主節(jié)點版本低于Redis2.8，則返回-ERR回復(fù)，此時從節(jié)點重新發(fā)送sync命令執(zhí)行全量復(fù)制；
如果主節(jié)點版本夠新，且runid與從節(jié)點發(fā)送的runid相同，且從節(jié)點發(fā)送的offset之后的數(shù)據(jù)在復(fù)制積壓緩沖區(qū)中都存在，則回復(fù)+CONTINUE，表示將進行部分復(fù)制，從節(jié)點等待主節(jié)點發(fā)送其缺少的數(shù)據(jù)即可；
如果主節(jié)點版本夠新，但是runid與從節(jié)點發(fā)送的runid不同，或從節(jié)點發(fā)送的offset之后的數(shù)據(jù)已不在復(fù)制積壓緩沖區(qū)中(在隊列中被擠出了)，則回復(fù)+FULLRESYNC <runid> <offset>，表示要進行全量復(fù)制，其中runid表示主節(jié)點當前的runid，offset表示主節(jié)點當前的offset，從節(jié)點保存這兩個值，以備使用。
4.4 部分復(fù)制演示
在下面的演示中，網(wǎng)絡(luò)中斷幾分鐘后恢復(fù)，斷開連接的主從節(jié)點進行了部分復(fù)制；為了便于模擬網(wǎng)絡(luò)中斷，本例中的主從節(jié)點在局域網(wǎng)中的兩臺機器上。
網(wǎng)絡(luò)中斷
網(wǎng)絡(luò)中斷一段時間后，主節(jié)點和從節(jié)點都會發(fā)現(xiàn)失去了與對方的連接（關(guān)于主從節(jié)點對超時的判斷機制，后面會有說明）；此后，從節(jié)點便開始執(zhí)行對主節(jié)點的重連，由于此時網(wǎng)絡(luò)還沒有恢復(fù)，重連失敗，從節(jié)點會一直嘗試重連。
主節(jié)點日志如下：
從節(jié)點日志如下：
網(wǎng)絡(luò)恢復(fù)
網(wǎng)絡(luò)恢復(fù)后，從節(jié)點連接主節(jié)點成功，并請求進行部分復(fù)制，主節(jié)點接收請求后，二者進行部分復(fù)制以同步數(shù)據(jù)。
主節(jié)點日志如下：
從節(jié)點日志如下：
5 命令傳播階段心跳機制
在命令傳播階段，除了發(fā)送寫命令，主從節(jié)點還維持著心跳機制：PING和REPLCONF ACK。心跳機制對于主從復(fù)制的超時判斷、數(shù)據(jù)安全等有作用。
5.1主->從：PING
每隔指定的時間，主節(jié)點會向從節(jié)點發(fā)送PING命令，這個PING命令的作用，主要是為了讓從節(jié)點進行超時判斷。
PING發(fā)送的頻率由repl-ping-slave-period參數(shù)控制，單位是秒，默認值是10s。
關(guān)于該PING命令究竟是由主節(jié)點發(fā)給從節(jié)點，還是相反，有一些爭議；因為在Redis的官方文檔中，對該參數(shù)的注釋中說明是從節(jié)點向主節(jié)點發(fā)送PING命令，如下圖所示：
但是根據(jù)該參數(shù)的名稱(含有ping-slave)，以及代碼實現(xiàn)，我認為該PING命令是主節(jié)點發(fā)給從節(jié)點的。相關(guān)代碼如下：
5.2 從->主：REPLCONF ACK
在命令傳播階段，從節(jié)點會向主節(jié)點發(fā)送REPLCONF ACK命令，頻率是每秒1次；命令格式為：REPLCONF ACK {offset}，其中offset指從節(jié)點保存的復(fù)制偏移量。REPLCONF ACK命令的作用包括：
（1）實時監(jiān)測主從節(jié)點網(wǎng)絡(luò)狀態(tài)：該命令會被主節(jié)點用于復(fù)制超時的判斷。此外，在主節(jié)點中使用info Replication，可以看到其從節(jié)點的狀態(tài)中的lag值，代表的是主節(jié)點上次收到該REPLCONF ACK命令的時間間隔，在正常情況下，該值應(yīng)該是0或1，如下圖所示：
（2）檢測命令丟失：從節(jié)點發(fā)送了自身的offset，主節(jié)點會與自己的offset對比，如果從節(jié)點數(shù)據(jù)缺失（如網(wǎng)絡(luò)丟包），主節(jié)點會推送缺失的數(shù)據(jù)（這里也會利用復(fù)制積壓緩沖區(qū)）。注意，offset和復(fù)制積壓緩沖區(qū)，不僅可以用于部分復(fù)制，也可以用于處理命令丟失等情形；區(qū)別在于前者是在斷線重連后進行的，而后者是在主從節(jié)點沒有斷線的情況下進行的。
（3）輔助保證從節(jié)點的數(shù)量和延遲：Redis主節(jié)點中使用min-slaves-to-write和min-slaves-max-lag參數(shù)，來保證主節(jié)點在不安全的情況下不會執(zhí)行寫命令；所謂不安全，是指從節(jié)點數(shù)量太少，或延遲過高。例如min-slaves-to-write和min-slaves-max-lag分別是3和10，含義是如果從節(jié)點數(shù)量小于3個，或所有從節(jié)點的延遲值都大于10s，則主節(jié)點拒絕執(zhí)行寫命令。而這里從節(jié)點延遲值的獲取，就是通過主節(jié)點接收到REPLCONF ACK命令的時間來判斷的，即前面所說的info Replication中的lag值。
6 應(yīng)用中的問題
6.1 讀寫分離及其中的問題
在主從復(fù)制基礎(chǔ)上實現(xiàn)的讀寫分離，可以實現(xiàn)Redis的讀負載均衡：由主節(jié)點提供寫服務(wù)，由一個或多個從節(jié)點提供讀服務(wù)（多個從節(jié)點既可以提高數(shù)據(jù)冗余程度，也可以最大化讀負載能力）；在讀負載較大的應(yīng)用場景下，可以大大提高Redis服務(wù)器的并發(fā)量。下面介紹在使用Redis讀寫分離時，需要注意的問題。
（1）延遲與不一致問題
前面已經(jīng)講到，由于主從復(fù)制的命令傳播是異步的，延遲與數(shù)據(jù)的不一致不可避免。如果應(yīng)用對數(shù)據(jù)不一致的接受程度程度較低，可能的優(yōu)化措施包括：優(yōu)化主從節(jié)點之間的網(wǎng)絡(luò)環(huán)境（如在同機房部署）；監(jiān)控主從節(jié)點延遲（通過offset）判斷，如果從節(jié)點延遲過大，通知應(yīng)用不再通過該從節(jié)點讀取數(shù)據(jù)；使用集群同時擴展寫負載和讀負載等。
在命令傳播階段以外的其他情況下，從節(jié)點的數(shù)據(jù)不一致可能更加嚴重，例如連接在數(shù)據(jù)同步階段，或從節(jié)點失去與主節(jié)點的連接時等。從節(jié)點的slave-serve-stale-data參數(shù)便與此有關(guān)：它控制這種情況下從節(jié)點的表現(xiàn)；如果為yes（默認值），則從節(jié)點仍能夠響應(yīng)客戶端的命令，如果為no，則從節(jié)點只能響應(yīng)info、slaveof等少數(shù)命令。該參數(shù)的設(shè)置與應(yīng)用對數(shù)據(jù)一致性的要求有關(guān)；如果對數(shù)據(jù)一致性要求很高，則應(yīng)設(shè)置為no。
（2）數(shù)據(jù)過期問題
在單機版Redis中，存在兩種刪除策略：
惰性刪除：服務(wù)器不會主動刪除數(shù)據(jù)，只有當客戶端查詢某個數(shù)據(jù)時，服務(wù)器判斷該數(shù)據(jù)是否過期，如果過期則刪除。
定期刪除：服務(wù)器執(zhí)行定時任務(wù)刪除過期數(shù)據(jù)，但是考慮到內(nèi)存和CPU的折中（刪除會釋放內(nèi)存，但是頻繁的刪除操作對CPU不友好），該刪除的頻率和執(zhí)行時間都受到了限制。
在主從復(fù)制場景下，為了主從節(jié)點的數(shù)據(jù)一致性，從節(jié)點不會主動刪除數(shù)據(jù)，而是由主節(jié)點控制從節(jié)點中過期數(shù)據(jù)的刪除。由于主節(jié)點的惰性刪除和定期刪除策略，都不能保證主節(jié)點及時對過期數(shù)據(jù)執(zhí)行刪除操作，因此，當客戶端通過Redis從節(jié)點讀取數(shù)據(jù)時，很容易讀取到已經(jīng)過期的數(shù)據(jù)。
Redis 3.2中，從節(jié)點在讀取數(shù)據(jù)時，增加了對數(shù)據(jù)是否過期的判斷：如果該數(shù)據(jù)已過期，則不返回給客戶端；將Redis升級到3.2可以解決數(shù)據(jù)過期問題。
（3）故障切換問題
在沒有使用哨兵的讀寫分離場景下，應(yīng)用針對讀和寫分別連接不同的Redis節(jié)點；當主節(jié)點或從節(jié)點出現(xiàn)問題而發(fā)生更改時，需要及時修改應(yīng)用程序讀寫Redis數(shù)據(jù)的連接；連接的切換可以手動進行，或者自己寫監(jiān)控程序進行切換，但前者響應(yīng)慢、容易出錯，后者實現(xiàn)復(fù)雜，成本都不算低。
（4）總結(jié)
在使用讀寫分離之前，可以考慮其他方法增加Redis的讀負載能力：如盡量優(yōu)化主節(jié)點（減少慢查詢、減少持久化等其他情況帶來的阻塞等）提高負載能力；使用Redis集群同時提高讀負載能力和寫負載能力等。如果使用讀寫分離，可以使用哨兵，使主從節(jié)點的故障切換盡可能自動化，并減少對應(yīng)用程序的侵入。
6.2 復(fù)制超時問題
主從節(jié)點復(fù)制超時是導(dǎo)致復(fù)制中斷的最重要的原因之一，本小節(jié)單獨說明超時問題，下一小節(jié)說明其他會導(dǎo)致復(fù)制中斷的問題。
超時判斷意義
在復(fù)制連接建立過程中及之后，主從節(jié)點都有機制判斷連接是否超時，其意義在于：
（1）如果主節(jié)點判斷連接超時，其會釋放相應(yīng)從節(jié)點的連接，從而釋放各種資源，否則無效的從節(jié)點仍會占用主節(jié)點的各種資源（輸出緩沖區(qū)、帶寬、連接等）；此外連接超時的判斷可以讓主節(jié)點更準確的知道當前有效從節(jié)點的個數(shù)，有助于保證數(shù)據(jù)安全（配合前面講到的min-slaves-to-write等參數(shù)）。
（2）如果從節(jié)點判斷連接超時，則可以及時重新建立連接，避免與主節(jié)點數(shù)據(jù)長期的不一致。
判斷機制
主從復(fù)制超時判斷的核心，在于repl-timeout參數(shù)，該參數(shù)規(guī)定了超時時間的閾值（默認60s），對于主節(jié)點和從節(jié)點同時有效；主從節(jié)點觸發(fā)超時的條件分別如下：
（1）主節(jié)點：每秒1次調(diào)用復(fù)制定時函數(shù)replicationCron()，在其中判斷當前時間距離上次收到各個從節(jié)點REPLCONF ACK的時間，是否超過了repl-timeout值，如果超過了則釋放相應(yīng)從節(jié)點的連接。
（2）從節(jié)點：從節(jié)點對超時的判斷同樣是在復(fù)制定時函數(shù)中判斷，基本邏輯是：
如果當前處于連接建立階段，且距離上次收到主節(jié)點的信息的時間已超過repl-timeout，則釋放與主節(jié)點的連接；
如果當前處于數(shù)據(jù)同步階段，且收到主節(jié)點的RDB文件的時間超時，則停止數(shù)據(jù)同步，釋放連接；
如果當前處于命令傳播階段，且距離上次收到主節(jié)點的PING命令或數(shù)據(jù)的時間已超過repl-timeout值，則釋放與主節(jié)點的連接。
主從節(jié)點判斷連接超時的相關(guān)源代碼如下：
/* Replication cron function, called 1 time per second. */
void replicationCron(void) {
static long long replication_cron_loops = 0;
/* Non blocking connection timeout? */
if (server.masterhost &&
(server.repl_state == REDIS_REPL_CONNECTING ||
slaveIsInHandshakeState()) &&
(time(NULL)-server.repl_transfer_lastio) > server.repl_timeout)
{
redisLog(REDIS_WARNING,"Timeout connecting to the MASTER...");
undoConnectWithMaster();
}
/* Bulk transfer I/O timeout? */
if (server.masterhost && server.repl_state == REDIS_REPL_TRANSFER &&
(time(NULL)-server.repl_transfer_lastio) > server.repl_timeout)
{
redisLog(REDIS_WARNING,"Timeout receiving bulk data from MASTER... If the problem persists try to set the 'repl-timeout' parameter in redis.conf to a larger value.");
replicationAbortSyncTransfer();
}
/* Timed out master when we are an already connected slave? */
if (server.masterhost && server.repl_state == REDIS_REPL_CONNECTED &&
(time(NULL)-server.master->lastinteraction) > server.repl_timeout)
{
redisLog(REDIS_WARNING,"MASTER timeout: no data nor PING received...");
freeClient(server.master);
}
//此處省略無關(guān)代碼……
/* Disconnect timedout slaves. */
if (listLength(server.slaves)) {
listIter li;
listNode *ln;
listRewind(server.slaves,&li);
while((ln = listNext(&li))) {
redisClient *slave = ln->value;
if (slave->replstate != REDIS_REPL_ONLINE) continue;
if (slave->flags & REDIS_PRE_PSYNC) continue;
if ((server.unixtime - slave->repl_ack_time) > server.repl_timeout)
{
redisLog(REDIS_WARNING, "Disconnecting timedout slave: %s",
replicationGetSlaveName(slave));
freeClient(slave);
}
}
}
//此處省略無關(guān)代碼……
}
需要注意的坑
下面介紹與復(fù)制階段連接超時有關(guān)的一些實際問題：
（1）數(shù)據(jù)同步階段：在主從節(jié)點進行全量復(fù)制bgsave時，主節(jié)點需要首先fork子進程將當前數(shù)據(jù)保存到RDB文件中，然后再將RDB文件通過網(wǎng)絡(luò)傳輸?shù)綇墓?jié)點。如果RDB文件過大，主節(jié)點在fork子進程+保存RDB文件時耗時過多，可能會導(dǎo)致從節(jié)點長時間收不到數(shù)據(jù)而觸發(fā)超時；此時從節(jié)點會重連主節(jié)點，然后再次全量復(fù)制，再次超時，再次重連……這是個悲傷的循環(huán)。為了避免這種情況的發(fā)生，除了注意Redis單機數(shù)據(jù)量不要過大，另一方面就是適當增大repl-timeout值，具體的大小可以根據(jù)bgsave耗時來調(diào)整。
（2）命令傳播階段：如前所述，在該階段主節(jié)點會向從節(jié)點發(fā)送PING命令，頻率由repl-ping-slave-period控制；該參數(shù)應(yīng)明顯小于repl-timeout值(后者至少是前者的幾倍)。否則，如果兩個參數(shù)相等或接近，網(wǎng)絡(luò)抖動導(dǎo)致個別PING命令丟失，此時恰巧主節(jié)點也沒有向從節(jié)點發(fā)送數(shù)據(jù)，則從節(jié)點很容易判斷超時。
（3）慢查詢導(dǎo)致的阻塞：如果主節(jié)點或從節(jié)點執(zhí)行了一些慢查詢（如keys *或者對大數(shù)據(jù)的hgetall等），導(dǎo)致服務(wù)器阻塞；阻塞期間無法響應(yīng)復(fù)制連接中對方節(jié)點的請求，可能導(dǎo)致復(fù)制超時。
6.3 復(fù)制中斷問題
主從節(jié)點超時是復(fù)制中斷的原因之一，除此之外，還有其他情況可能導(dǎo)致復(fù)制中斷，其中最主要的是復(fù)制緩沖區(qū)溢出問題。
復(fù)制緩沖區(qū)溢出
前面曾提到過，在全量復(fù)制階段，主節(jié)點會將執(zhí)行的寫命令放到復(fù)制緩沖區(qū)中，該緩沖區(qū)存放的數(shù)據(jù)包括了以下幾個時間段內(nèi)主節(jié)點執(zhí)行的寫命令：bgsave生成RDB文件、RDB文件由主節(jié)點發(fā)往從節(jié)點、從節(jié)點清空老數(shù)據(jù)并載入RDB文件中的數(shù)據(jù)。當主節(jié)點數(shù)據(jù)量較大，或者主從節(jié)點之間網(wǎng)絡(luò)延遲較大時，可能導(dǎo)致該緩沖區(qū)的大小超過了限制，此時主節(jié)點會斷開與從節(jié)點之間的連接；這種情況可能引起全量復(fù)制->復(fù)制緩沖區(qū)溢出導(dǎo)致連接中斷->重連->全量復(fù)制->復(fù)制緩沖區(qū)溢出導(dǎo)致連接中斷……的循環(huán)。
復(fù)制緩沖區(qū)的大小由client-output-buffer-limit slave {hard limit} {soft limit} {soft seconds}配置，默認值為client-output-buffer-limit slave 256MB 64MB 60，其含義是：如果buffer大于256MB，或者連續(xù)60s大于64MB，則主節(jié)點會斷開與該從節(jié)點的連接。該參數(shù)是可以通過config set命令動態(tài)配置的（即不重啟Redis也可以生效）。
當復(fù)制緩沖區(qū)溢出時，主節(jié)點打印日志如下所示：
需要注意的是，復(fù)制緩沖區(qū)是客戶端輸出緩沖區(qū)的一種，主節(jié)點會為每一個從節(jié)點分別分配復(fù)制緩沖區(qū)；而復(fù)制積壓緩沖區(qū)則是一個主節(jié)點只有一個，無論它有多少個從節(jié)點。
6.4 各場景下復(fù)制的選擇及優(yōu)化技巧
在介紹了Redis復(fù)制的種種細節(jié)之后，現(xiàn)在我們可以來總結(jié)一下，在下面常見的場景中，何時使用部分復(fù)制，以及需要注意哪些問題。
（1）第一次建立復(fù)制
此時全量復(fù)制不可避免，但仍有幾點需要注意：如果主節(jié)點的數(shù)據(jù)量較大，應(yīng)該盡量避開流量的高峰期，避免造成阻塞；如果有多個從節(jié)點需要建立對主節(jié)點的復(fù)制，可以考慮將幾個從節(jié)點錯開，避免主節(jié)點帶寬占用過大。此外，如果從節(jié)點過多，也可以調(diào)整主從復(fù)制的拓撲結(jié)構(gòu)，由一主多從結(jié)構(gòu)變?yōu)闃錉罱Y(jié)構(gòu)（中間的節(jié)點既是其主節(jié)點的從節(jié)點，也是其從節(jié)點的主節(jié)點）；但使用樹狀結(jié)構(gòu)應(yīng)該謹慎：雖然主節(jié)點的直接從節(jié)點減少，降低了主節(jié)點的負擔，但是多層從節(jié)點的延遲增大，數(shù)據(jù)一致性變差；且結(jié)構(gòu)復(fù)雜，維護相當困難。
（2）主節(jié)點重啟
主節(jié)點重啟可以分為兩種情況來討論，一種是故障導(dǎo)致宕機，另一種則是有計劃的重啟。
主節(jié)點宕機
主節(jié)點宕機重啟后，runid會發(fā)生變化，因此不能進行部分復(fù)制，只能全量復(fù)制。
實際上在主節(jié)點宕機的情況下，應(yīng)進行故障轉(zhuǎn)移處理，將其中的一個從節(jié)點升級為主節(jié)點，其他從節(jié)點從新的主節(jié)點進行復(fù)制；且故障轉(zhuǎn)移應(yīng)盡量的自動化，后面文章將要介紹的哨兵便可以進行自動的故障轉(zhuǎn)移。
安全重啟：debug reload
在一些場景下，可能希望對主節(jié)點進行重啟，例如主節(jié)點內(nèi)存碎片率過高，或者希望調(diào)整一些只能在啟動時調(diào)整的參數(shù)。如果使用普通的手段重啟主節(jié)點，會使得runid發(fā)生變化，可能導(dǎo)致不必要的全量復(fù)制。
為了解決這個問題，Redis提供了debug reload的重啟方式：重啟后，主節(jié)點的runid和offset都不受影響，避免了全量復(fù)制。
如下圖所示，debug reload重啟后runid和offset都未受影響：
但debug reload是一柄雙刃劍：它會清空當前內(nèi)存中的數(shù)據(jù)，重新從RDB文件中加載，這個過程會導(dǎo)致主節(jié)點的阻塞，因此也需要謹慎。
（3）從節(jié)點重啟
從節(jié)點宕機重啟后，其保存的主節(jié)點的runid會丟失，因此即使再次執(zhí)行slaveof，也無法進行部分復(fù)制。
（4）網(wǎng)絡(luò)中斷
如果主從節(jié)點之間出現(xiàn)網(wǎng)絡(luò)問題，造成短時間內(nèi)網(wǎng)絡(luò)中斷，可以分為多種情況討論。
第一種情況：網(wǎng)絡(luò)問題時間極為短暫，只造成了短暫的丟包，主從節(jié)點都沒有判定超時（未觸發(fā)repl-timeout）；此時只需要通過REPLCONF ACK來補充丟失的數(shù)據(jù)即可。
第二種情況：網(wǎng)絡(luò)問題時間很長，主從節(jié)點判斷超時（觸發(fā)了repl-timeout），且丟失的數(shù)據(jù)過多，超過了復(fù)制積壓緩沖區(qū)所能存儲的范圍；此時主從節(jié)點無法進行部分復(fù)制，只能進行全量復(fù)制。為了盡可能避免這種情況的發(fā)生，應(yīng)該根據(jù)實際情況適當調(diào)整復(fù)制積壓緩沖區(qū)的大??；此外及時發(fā)現(xiàn)并修復(fù)網(wǎng)絡(luò)中斷，也可以減少全量復(fù)制。
第三種情況：介于前述兩種情況之間，主從節(jié)點判斷超時，且丟失的數(shù)據(jù)仍然都在復(fù)制積壓緩沖區(qū)中；此時主從節(jié)點可以進行部分復(fù)制。
6.5 復(fù)制相關(guān)的配置
這一節(jié)總結(jié)一下與復(fù)制有關(guān)的配置，說明這些配置的作用、起作用的階段，以及配置方法等；通過了解這些配置，一方面加深對Redis復(fù)制的了解，另一方面掌握這些配置的方法，可以優(yōu)化Redis的使用，少走坑。
配置大致可以分為主節(jié)點相關(guān)配置、從節(jié)點相關(guān)配置以及與主從節(jié)點都有關(guān)的配置，下面分別說明。
（1）與主從節(jié)點都有關(guān)的配置
首先介紹最特殊的配置，它決定了該節(jié)點是主節(jié)點還是從節(jié)點：
a. slaveof <masterip> <masterport>：Redis啟動時起作用；作用是建立復(fù)制關(guān)系，開啟了該配置的Redis服務(wù)器在啟動后成為從節(jié)點。該注釋默認注釋掉，即Redis服務(wù)器默認都是主節(jié)點。
b. repl-timeout 60：與各個階段主從節(jié)點連接超時判斷有關(guān)，見前面的介紹。
（2）主節(jié)點相關(guān)配置
a. repl-diskless-sync no：作用于全量復(fù)制階段，控制主節(jié)點是否使用diskless復(fù)制（無盤復(fù)制）。所謂diskless復(fù)制，是指在全量復(fù)制時，主節(jié)點不再先把數(shù)據(jù)寫入RDB文件，而是直接寫入slave的socket中，整個過程中不涉及硬盤；diskless復(fù)制在磁盤IO很慢而網(wǎng)速很快時更有優(yōu)勢。需要注意的是，截至Redis3.0，diskless復(fù)制處于實驗階段，默認是關(guān)閉的。
b. repl-diskless-sync-delay 5：該配置作用于全量復(fù)制階段，當主節(jié)點使用diskless復(fù)制時，該配置決定主節(jié)點向從節(jié)點發(fā)送之前停頓的時間，單位是秒；只有當diskless復(fù)制打開時有效，默認5s。之所以設(shè)置停頓時間，是基于以下兩個考慮：(1)向slave的socket的傳輸一旦開始，新連接的slave只能等待當前數(shù)據(jù)傳輸結(jié)束，才能開始新的數(shù)據(jù)傳輸 (2)多個從節(jié)點有較大的概率在短時間內(nèi)建立主從復(fù)制。
c. client-output-buffer-limit slave 256MB 64MB 60：與全量復(fù)制階段主節(jié)點的緩沖區(qū)大小有關(guān)，見前面的介紹。
d. repl-disable-tcp-nodelay no：與命令傳播階段的延遲有關(guān)，見前面的介紹。
e. masterauth <master-password>：與連接建立階段的身份驗證有關(guān)，見前面的介紹。
f. repl-ping-slave-period 10：與命令傳播階段主從節(jié)點的超時判斷有關(guān)，見前面的介紹。
g. repl-backlog-size 1mb：復(fù)制積壓緩沖區(qū)的大小，見前面的介紹。
h. repl-backlog-ttl 3600：當主節(jié)點沒有從節(jié)點時，復(fù)制積壓緩沖區(qū)保留的時間，這樣當斷開的從節(jié)點重新連進來時，可以進行部分復(fù)制；默認3600s。如果設(shè)置為0，則永遠不會釋放復(fù)制積壓緩沖區(qū)。
i. min-slaves-to-write 3與min-slaves-max-lag 10：規(guī)定了主節(jié)點的最小從節(jié)點數(shù)目，及對應(yīng)的最大延遲，見前面的介紹。
（3）從節(jié)點相關(guān)配置
a. slave-serve-stale-data yes：與從節(jié)點數(shù)據(jù)陳舊時是否響應(yīng)客戶端命令有關(guān)，見前面的介紹。
b. slave-read-only yes：從節(jié)點是否只讀；默認是只讀的。由于從節(jié)點開啟寫操作容易導(dǎo)致主從節(jié)點的數(shù)據(jù)不一致，因此該配置盡量不要修改。
6.6 單機內(nèi)存大小限制
在 深入學習Redis（2）：持久化 一文中，講到了fork操作對Redis單機內(nèi)存大小的限制。實際上在Redis的使用中，限制單機內(nèi)存大小的因素非常之多，下面總結(jié)一下在主從復(fù)制中，單機內(nèi)存過大可能造成的影響：
（1）切主：當主節(jié)點宕機時，一種常見的容災(zāi)策略是將其中一個從節(jié)點提升為主節(jié)點，并將其他從節(jié)點掛載到新的主節(jié)點上，此時這些從節(jié)點只能進行全量復(fù)制；如果Redis單機內(nèi)存達到10GB，一個從節(jié)點的同步時間在幾分鐘的級別；如果從節(jié)點較多，恢復(fù)的速度會更慢。如果系統(tǒng)的讀負載很高，而這段時間從節(jié)點無法提供服務(wù)，會對系統(tǒng)造成很大的壓力。
（2）從庫擴容：如果訪問量突然增大，此時希望增加從節(jié)點分擔讀負載，如果數(shù)據(jù)量過大，從節(jié)點同步太慢，難以及時應(yīng)對訪問量的暴增。
（3）緩沖區(qū)溢出：（1）和（2）都是從節(jié)點可以正常同步的情形（雖然慢），但是如果數(shù)據(jù)量過大，導(dǎo)致全量復(fù)制階段主節(jié)點的復(fù)制緩沖區(qū)溢出，從而導(dǎo)致復(fù)制中斷，則主從節(jié)點的數(shù)據(jù)同步會全量復(fù)制->復(fù)制緩沖區(qū)溢出導(dǎo)致復(fù)制中斷->重連->全量復(fù)制->復(fù)制緩沖區(qū)溢出導(dǎo)致復(fù)制中斷……的循環(huán)。
（4）超時：如果數(shù)據(jù)量過大，全量復(fù)制階段主節(jié)點fork+保存RDB文件耗時過大，從節(jié)點長時間接收不到數(shù)據(jù)觸發(fā)超時，主從節(jié)點的數(shù)據(jù)同步同樣可能陷入全量復(fù)制->超時導(dǎo)致復(fù)制中斷->重連->全量復(fù)制->超時導(dǎo)致復(fù)制中斷……的循環(huán)。
此外，主節(jié)點單機內(nèi)存除了絕對量不能太大，其占用主機內(nèi)存的比例也不應(yīng)過大：最好只使用50%-65%的內(nèi)存，留下30%-45%的內(nèi)存用于執(zhí)行bgsave命令和創(chuàng)建復(fù)制緩沖區(qū)等。
6.7 info Replication
在Redis客戶端通過info Replication可以查看與復(fù)制相關(guān)的狀態(tài)，對于了解主從節(jié)點的當前狀態(tài)，以及解決出現(xiàn)的問題都會有幫助。
主節(jié)點：
從節(jié)點：
對于從節(jié)點，上半部分展示的是其作為從節(jié)點的狀態(tài)，從connectd_slaves開始，展示的是其作為潛在的主節(jié)點的狀態(tài)。
info Replication中展示的大部分內(nèi)容在文章中都已經(jīng)講述，這里不再詳述。
7 總結(jié)
下面回顧一下本文的主要內(nèi)容：
1.主從復(fù)制的作用：宏觀的了解主從復(fù)制是為了解決什么樣的問題，即數(shù)據(jù)冗余、故障恢復(fù)、讀負載均衡等。
2.主從復(fù)制的操作：即slaveof命令。
3.主從復(fù)制的原理：主從復(fù)制包括了連接建立階段、數(shù)據(jù)同步階段、命令傳播階段；其中數(shù)據(jù)同步階段，有全量復(fù)制和部分復(fù)制兩種數(shù)據(jù)同步方式；命令傳播階段，主從節(jié)點之間有PING和REPLCONF ACK命令互相進行心跳檢測。
4.應(yīng)用中的問題：包括讀寫分離的問題（數(shù)據(jù)不一致問題、數(shù)據(jù)過期問題、故障切換問題等）、復(fù)制超時問題、復(fù)制中斷問題等，然后總結(jié)了主從復(fù)制相關(guān)的配置，其中repl-timeout、client-output-buffer-limit slave等對解決Redis主從復(fù)制中出現(xiàn)的問題可能會有幫助。
主從復(fù)制雖然解決或緩解了數(shù)據(jù)冗余、故障恢復(fù)、讀負載均衡等問題，但其缺陷仍很明顯：故障恢復(fù)無法自動化；寫操作無法負載均衡；存儲能力受到單機的限制；這些問題的解決，需要哨兵和集群的幫助，我將在后面的文章中介紹，歡迎關(guān)注。
轉(zhuǎn)自https://www.cnblogs.com/kismetv/p/9236731.html
