分析：Redis主從復(fù)制

分析：Redis主從復(fù)制

那么Redis2.4.16的全量復(fù)制與Redis2.8的部分復(fù)制是如何實現(xiàn)的呢?如下圖所示，這5個狀態(tài)是Slave在主從復(fù)制過程涉及到的幾個狀態(tài)，其中REDIS_REPL_NONE是Redis啟動時候默認(rèn)的狀態(tài)。圖1-2所示的四個狀態(tài)表示站在Master的角度來看，Slave所處于的狀態(tài)，因為Slave在Master端看來就是一個特殊的client(同理Master在Slave端看來也是一個特殊的client)。/*Slavereplicationstate–Slaveside*/#defineREDIS_REPL_NONE0/*Noactivereplication*/#defineREDIS_REPL_CONNECT1/*MustconnecttoMaster*/#defineREDIS_REPL_CONNECTING2/*ConnectingtoMaster*/#defineREDIS_REPL_TRANSFER3/*Receiving.rdbfromMaster*/#defineREDIS_REPL_CONNECTED4/*ConnectedtoMaster*/Slave自身的狀態(tài)#defineREDIS_REPL_WAIT_BGSAVE_START3/*Masterwaitsbgsavetostartfeedingit*/#defineREDIS_REPL_WAIT_BGSAVE_END4/*MasterwaitsbgsavetostartbulkDBtransmission*/#defineREDIS_REPL_SEND_BULK5/*MasterissendingthebulkDB*/#defineREDIS_REPL_ONLINE6/*bulkDBalreadytransmitted，receiveupdates*/Master端的Slave狀態(tài)Redis在接收到“slaveofipport”命令以后，首先會將自身的狀態(tài)置為REDIS_REPL_CONNECT，表示需要與自己的Master連接，此時Slave并沒有與Master做連接。Redis每隔100ms會調(diào)用serverCron()函數(shù)一次，每10次serverCron()的調(diào)用會調(diào)用replicationCron()一次，即每1s會調(diào)用一次replication()函數(shù)。在replication()函數(shù)中，會檢查Slave的狀態(tài)，如果是處于REDIS_REPL_CONNECT狀態(tài)，就會建立syncWithMaster()的事件處理函數(shù)，并將Slave的狀態(tài)改成REDIS_REPL_CONNECTING。syncWithMaster()函數(shù)主要是向Master發(fā)送sync命令，當(dāng)該事件處理函數(shù)被觸發(fā)以后會將Slave的狀態(tài)改成REDIS_REPL_TRANSFER，表示Slave已經(jīng)準(zhǔn)備就緒要接收Master生成的rdb文件?；氐組aster的角色，Master發(fā)現(xiàn)有一個Slave連接上來，如果此時的Master一個Slave都沒有且沒有后臺快照進程，則啟動一個后臺進程將當(dāng)前內(nèi)存中的數(shù)據(jù)生成一個rdb文件，同時將Slave的狀態(tài)置為REDIS_REPL_WAIT_BGSAVE_END狀態(tài)，表示該Slave等待Master的快照進程結(jié)束。在后臺進行生成rdb文件的時候，如果有對redis的更新命令，Master會將這些更新命令存到該Slave的buffer中，如果buffer滿了會另外開辟list來存儲這些更新命令。當(dāng)后臺快照進程結(jié)束，Master會將該Slave的狀態(tài)改為REDIS_REPL_SEND_BULK，同時注冊sendBulkToSlave()事件處理函數(shù)用于將生成的rdb文件傳輸給Slave。等rdb傳輸結(jié)束以后，sendBulkToSlave()事件函數(shù)會被刪除，Slave的狀態(tài)會被更改為REDIS_REPL_ONLINE，另外再注冊sendReplyToClient()事件函數(shù)，將Master在快照內(nèi)過程中的所有更新操作(Slave的buffer里存的命令)發(fā)給Slave。再回到Slave的角色，當(dāng)Master向Slave傳輸完rdb文件以后，Slave自身會將狀態(tài)改為REDIS_REPL_CONNECTED，表示復(fù)制已完成，處于與Master保持實時同步的狀態(tài)。上述描述的狀態(tài)轉(zhuǎn)換如圖1-3所示，由圖中可知，站在Slave角色看，當(dāng)出現(xiàn)網(wǎng)絡(luò)中斷的時候不管Slave本身是處于REDIS_REPL_CONNECTING、REDIS_REPL_REPL_TRANSFER還是REDIS_REPL_CONNECTED，都會調(diào)用相應(yīng)的處理函數(shù)使Slave進入REDIS_REPL_CONNECT狀態(tài)，這就意味著Slave需要重新向Master發(fā)送sync命令，重新進行一次全量同步過程。圖中的REDIS_REPL_WAIT_BGSAVE_START狀態(tài)是在Slave連接上Master的時候(站在Master的角色看)，當(dāng)時Master剛好后臺有快照進程且該快照進程生成的rdb不適合直接傳給該Slave時出現(xiàn)的狀態(tài)，則將Slave的狀態(tài)置為REDIS_REPL_WAIT_BGSAVE_START。如果此時有快照進程且找到了另外的發(fā)起快照進程的Slave，只需要將另外的Slave的buffer內(nèi)容拷貝到該Slave的buffer中，然后直接進入REDIS_REPL_WAIT_BGSAVE_END狀態(tài)。如果此時沒有后臺快照進程，Slave直接進入REDIS_REPL_WAIT_BGSAVE_END狀態(tài)，同時啟動一個后臺快照進程。在上述狀態(tài)轉(zhuǎn)圖中存在的最大問題在于任何網(wǎng)絡(luò)閃斷都會導(dǎo)致Slave與Master重連，然后重新進入快照過程，需要花費較長的時間重新傳輸rdb文件，而Slave在接收完rdb文件以后試圖將rdb文件恢復(fù)到內(nèi)存的過程中是不能服務(wù)的(除info命令外)。所以提供部分復(fù)制至少可以做到在網(wǎng)絡(luò)閃斷且更新命令不太多的情景下能夠盡量的避免全量復(fù)制的方案就顯得尤為重要。慶幸的是Redis2.8中里已經(jīng)能夠做到在網(wǎng)絡(luò)閃斷的情況下，Slave重新連接上Master以后，僅僅只傳輸閃斷期間的更新命令。在Redis2.8中redisServer結(jié)構(gòu)中增加了一個成員：charrunid[REDIS_RUN_ID_SIZE+1];/*IDalwaysdifferentateveryexec.*/該runid是由一個getRandomHexChars()函數(shù)生成的每次不同的一個唯一標(biāo)識，不同Redis實例之間該runid是不同的，同一個Redis重啟以后，其runid和之前的runid也是不同的。還增加了比較重要的幾項數(shù)據(jù)成員char*repl_backlog;/*Replicationbacklogforpartialsyncs*/longlongrepl_backlog_size;/*Backlogcircularbuffersize*/longlongrepl_backlog_histlen;/*Backlogactualdatalength*/longlongrepl_backlog_idx;/*Backlogcircularbuffercurrentoffset*/longlongrepl_backlog_off;/*Replicationoffsetoffirstbyteinthebacklogbuffer.*/time_trepl_backlog_time_limit;/*TimewithoutSlavesafterthebackloggetsreleased.*/time_trepl_no_Slaves_since;/*WehavenoSlavessincethattime.Onlyvalidifserver.Slaveslenis0.*/repl_backlog是redis用于存儲更新命令的一塊buffer，在部分復(fù)制的時候Slave會請求Master從這塊buffer中獲取閃斷情況下丟失的更新操作。repl_backlog在redis啟動的時候初始化為NULL，當(dāng)有Slave連接上來的時候，會被指向創(chuàng)建的buffer，默認(rèn)為1024*1024(即1Mb)。repl_backlog_size表示該buffer的大小(默認(rèn)1024*1024，即1Mb)。該buffer是作為一個環(huán)形緩存區(qū)使用的，當(dāng)有數(shù)據(jù)超過buffer的大小以后就會重新從buffer的頭部開始寫入。repl_backlog_idx表示當(dāng)前緩存數(shù)據(jù)的尾部(因為是環(huán)形buffer)。repl_backlog_off是全局緩存的偏移量，從開始緩存數(shù)據(jù)起一直在增長。如果Master一個Slave都沒有，則超過一段時間以后repl_backlog會被釋放，默認(rèn)超時時間是1小時。Redis2.8的主從復(fù)制如圖1-5所示，Slave如果與Master的連接超時了，Slave會將調(diào)用freeClient(server.Master)把連接關(guān)閉。該freeClient()函數(shù)與2.4版本的相比做了改動，會將Master對應(yīng)的數(shù)據(jù)結(jié)構(gòu)的一些信息存起來作為cacheMaster，其中后續(xù)被用于部分復(fù)制的最重要的兩個信息一個是Masterrunid，另一個是reploff。reploff是Slave端接收到Master端傳遞過來的命令以后不斷更新記錄的全局偏移量的值，該值和Master端的repl_backlog_off對應(yīng)，正常情況下reploff<=repl_backlog_off。如果Slave嘗試部分復(fù)制失敗以后，就會將該cacheMaster釋放。Redis2.8中主從復(fù)制的過程增加了REDIS_RECIVE_PONG狀態(tài)，該狀態(tài)作為試圖與Master同步的時候先ping一下的一個中間狀態(tài)。當(dāng)ping通以后，Slave首先會嘗試部分復(fù)制，從cacheMaster中拿出Masterrunid和reploff傳給Master，表示請求部分復(fù)制。第一次的時候，由于Slave端的cacheMaster是NULL，所以Slave向Master發(fā)送的runid是“?”，偏移量是“-1”，當(dāng)Master收到這兩個變量以后會將自身的runid和實際偏移量發(fā)送給Slave，同時讓Slave發(fā)起一次全量同步。Slave與Master完全同步以后，maste的更新命令會被存到repl_backlog中，同時不斷更新偏移量等相關(guān)變量。這些更