主從同步簡介
redis集群的搭建方式有一主一從粘都，一主多從寨典，多主多從等方式联予，目前我們介紹主從的方式瓣履，就從一主一從開始切入率翅。
主從復制的作用如下：
- 數(shù)據(jù)備份：主從同步實現(xiàn)了redis數(shù)據(jù)的熱備份，是持久化之外的另一種數(shù)據(jù)冗余方式袖迎。增強了數(shù)據(jù)安全性。
- 故障恢復：從節(jié)點備份了主節(jié)點數(shù)據(jù)的所有數(shù)據(jù)腺晾，當主節(jié)點宕機時燕锥，從節(jié)點可以即刻頂上，無縫銜接悯蝉，實現(xiàn)故障的快速恢復归形，也算是一種服務冗余。
- 讀寫分離：在主從復制的基礎上上鼻由，通過負載均衡等方式暇榴，可以由主節(jié)點負責寫入，從節(jié)點提供讀服務蕉世。在讀多寫少的場景下蔼紧，選擇一主多從的集群方式，大大提高redis的服務器的并發(fā)量狠轻。
- 高可用奸例、高并發(fā)基石：主從復制，主從通信是redis集群和哨兵模式的實現(xiàn)的基礎向楼。
redis集群搭建
主從復制的開啟查吊，完全是從節(jié)點上的發(fā)起的，無需主節(jié)點做任何操作湖蜕。
開啟主從復制的方式
- 配置文件：在redis的配置文件中增加配置：slaveof 主節(jié)點ip:port
- redis啟動命令：redis-server 啟動命令加入 -- slaveof
- 客戶端發(fā)送命令：slaveof ip port
總結(jié)：上邊三種方式是等效的逻卖，只是后兩種方式在從節(jié)點重啟后需再次執(zhí)行。
客戶端命令主從復制示例
準備工作：啟動兩個redis節(jié)點
端口規(guī)劃：6379 6380
啟動時兩個都是主節(jié)點昭抒，啟動后計劃6379實例為主節(jié)點评也，6380設置為從節(jié)點虚茶。
6379為默認端口。6380端口實例需要在配置文件中修改端口號仇参。
# Accept connections on the specified port,default is 6379.
# If port 0 is specified Redis will not listen on a TCP socket.
port 6380
建立主從復制關系
從節(jié)點執(zhí)行命令：
redis-cli 6380 #連接客戶端
127.0.0.1:6380> slaveof 127.0.0.1 63729 #建立主從復制關系
主從同步演示效果
- 從節(jié)點查詢一個不存在的key(mykey)
- mykey不存在
- 主節(jié)點增加mykey
- 從節(jié)點查詢mykey
- 從節(jié)點同樣可以查詢到mykey的值嘹叫，說明數(shù)據(jù)已經(jīng)從主節(jié)點同步過來了。
- 主節(jié)點刪除mykey
- 從節(jié)點查詢mykey
- 從節(jié)點數(shù)據(jù)也不存在了诈乒，說明從節(jié)點刪除數(shù)據(jù)也同步成功了罩扇。
斷開復制
通過slaveof命令建立的主從同步關系，可以通過slaveof no one 命令斷開怕磨。
:::color5
?? 從節(jié)點與主節(jié)點斷開以后喂饥，從節(jié)點的已存在數(shù)據(jù)不會被刪除，只是不再接收主節(jié)點同步的數(shù)據(jù)肠鲫。
:::
主從復制的核心原理
redis主從同步方式
redis集群可以使用主從同步和從從同步员帮，主要的同步方式有全量復制和部分復制。
- <font style="color:rgb(51,51,51);">全量復制：</font><font style="color:rgb(51,51,51);">用于初次復制或其他無法進行部分復制的情況导饲，將主節(jié)點中的所有數(shù)據(jù)都發(fā)送給從節(jié)點捞高，是一個非常重型的操作。 </font>
- <font style="color:rgb(51,51,51);">部分復制：</font><font style="color:rgb(51,51,51);">用于網(wǎng)絡中斷等情況后的復制渣锦，只將中斷期間主節(jié)點執(zhí)行的寫命令發(fā)送給從節(jié)點硝岗，與全量復制相比更加高效。需要注意的是袋毙，如果網(wǎng)絡中斷時間過長型檀，導致主節(jié)點沒有能夠完整地保存中斷期間執(zhí)行的寫命令，則無法進行部分復制听盖，仍要使用全量復制胀溺。</font>
初次建立主從復制關系（全量復制）：
- 從節(jié)點發(fā)送slaveof命令旅择，主節(jié)點接收到命令辨宠，做一次bgsave,將全量數(shù)據(jù)寫入到rdb文件，同時把后續(xù)的操作記錄寫到復制緩沖區(qū)中西轩。
- rdb寫入完成后全量同步到從節(jié)點悬蔽。從節(jié)點接受完成后將rdb文件全量加載到內(nèi)存中扯躺。
- 加載完成后，再通知主節(jié)點將操作記錄緩沖區(qū)中的數(shù)據(jù)也同步到從節(jié)點蝎困，進行重放就完成了同步過程录语。
- 后續(xù)的增量數(shù)據(jù)都是通過同步數(shù)據(jù)的操作記錄完成的，類似mysql的binlog日志禾乘。
建立主從同步關系后異常斷開（部分復制）：
- 從節(jié)點每秒嘗試與主節(jié)點建立socker連接澎埠。
- 建立連接時發(fā)送命令 psync {runId} {offset}，需要帶上runid和offser信息始藕。
- 主節(jié)點接收到offset信息后蒲稳，判斷offset是否在復制積壓緩沖區(qū)內(nèi)氮趋？
- 在緩沖區(qū)內(nèi)則將緩沖區(qū)中的數(shù)據(jù)發(fā)送到從節(jié)點，從節(jié)點完成增量數(shù)據(jù)同步江耀。
- 不在緩沖區(qū)內(nèi)剩胁，則執(zhí)行全量復制步驟。
名詞解釋
:::color2
?? redis sever的runId
每個redis實例啟動時祥国，都會生成一個隨機ID（每次啟動都是不同的）昵观，由40個隨機的十六進制字符組成，runId用來標識唯一的redis節(jié)點舌稀。
:::
# 通過info server命令查詢run_id
redis-cli info server | grep run_id
<font style="color:rgb(51,51,51);">主從節(jié)點初次復制時啊犬，主節(jié)點將自己的runid發(fā)送給從節(jié)點，從節(jié)點將這個runid保存起來壁查；當斷線重連時觉至，從節(jié)點會將這個runid發(fā)送給主節(jié)點；主節(jié)點根據(jù)runid判斷能否進行部分復制： </font>
- <font style="color:rgb(51,51,51);">如果從節(jié)點保存的runid與主節(jié)點現(xiàn)在的runid相同睡腿，說明主從節(jié)點之前同步過语御，主節(jié)點會繼續(xù)嘗試使用部分復制(到底能不能部分復制還要看offset和復制積壓緩沖區(qū)的情況)； </font>
- <font style="color:rgb(51,51,51);">如果從節(jié)點保存的runid與主節(jié)點現(xiàn)在的runid不同嫉到，說明從節(jié)點在斷線前同步的Redis節(jié)點并不是當前的主節(jié)點沃暗，只能進行全量復制。</font>
:::color2
?? 復制偏移量offset
- 主節(jié)點和從節(jié)點分別維護一個復制偏移量（offset）何恶，代表的是主節(jié)點向從節(jié)點傳遞的字節(jié)數(shù)。
- 主節(jié)點每次向從節(jié)點傳輸N個字節(jié)數(shù)據(jù)時嚼黔，主節(jié)點的offset就增加N细层。
- 從節(jié)點每次從主節(jié)點接收到N個字節(jié)數(shù)據(jù)時，從節(jié)點的offset就增加N唬涧。
:::
offset的復制偏移量用途
offset用于判斷主從節(jié)點的數(shù)據(jù)是否一致疫赎，如果兩者offset相同，則數(shù)據(jù)相同碎节；如果不同捧搞，則不一致，此時則可以依據(jù)offset判斷兩者數(shù)據(jù)相差的部分狮荔。
例如：如果主節(jié)點的offset是1000胎撇，從節(jié)點的offset是500，則部分復制就可以將501-100字節(jié)的數(shù)據(jù)傳輸?shù)阶止?jié)點即可同步不一致的數(shù)據(jù)殖氏。
:::color2
?? 復制積壓緩沖區(qū)（repl-backlog-buffer）
復制積壓緩沖區(qū)是由主節(jié)點進行維護的晚树、固定隊列的、先進先出的隊列雅采，默認為1MB爵憎；
當主從關系建立時慨亲，master創(chuàng)建一個積壓緩沖區(qū)，其作用是備份主節(jié)點最近接收到的redis命令,后續(xù)會發(fā)送給從節(jié)點的數(shù)據(jù)宝鼓。
無論主節(jié)點有一個從節(jié)點還是有多個從節(jié)點刑棵，主節(jié)點都只需要一個復制緩沖區(qū)。
:::
在命令傳輸階段愚铡，主節(jié)點除了將寫命令發(fā)送給從節(jié)點之外蛉签，還會在復制緩沖區(qū)內(nèi)備份寫命令。
除了儲存寫命令茂附，復制緩沖區(qū)中還存儲了其中的每個命令對應的復制偏移量（offset）正蛙。
由于復制緩沖區(qū)長度是固定有限的，因此可以備份的寫命令也十分有限营曼，當主從節(jié)點offset的差距超過緩沖區(qū)的長度時乒验，將無法執(zhí)行部分復制，只能執(zhí)行全量復制蒂阱。
主從同步流程
slaveof命令執(zhí)行流程
主節(jié)點接收到的從節(jié)點發(fā)送的slaveof命令后锻全，首先決定是使用全量復制還是部分復制。
- 從節(jié)點根據(jù)當前狀態(tài)录煤，決定如何調(diào)用 psync命令：
- 如果從節(jié)點從未執(zhí)行過 slaveof 或者 執(zhí)行過 slaveof no one ,從節(jié)點發(fā)送命令為 psync ? -1;使用全量復制鳄厌。
- 如果從節(jié)點執(zhí)行slaveof，則發(fā)送命令為 psync {runId} {offset} ,其中 runid為上次復制的主節(jié)點的 runid妈踊，offset 為從節(jié)點保存的復制偏移量了嚎。
- 主節(jié)點接收到從節(jié)點發(fā)送的 psync 命令后，根據(jù)命令數(shù)據(jù)和當前服務狀態(tài)廊营，判斷執(zhí)行全量復制還是部分復制歪泳。
- 主要主節(jié)點版本低于 Redis2.8 ，則回復 -ERR 露筒，此時從節(jié)點重新發(fā)送 psync命令執(zhí)行全量復制呐伞，因為 Redis2.8 版本之前只有全量復制的模式，沒有部分復制的模式慎式。
- 如果主節(jié)點在2.8版本之后伶氢，且判斷runid和主節(jié)點的runid是否相同，且判斷offset是否在主節(jié)點的復制緩沖區(qū)內(nèi)瘪吏，如果都滿足癣防，則回復+COUTINUE，表示使用部分復制模式肪虎，從主節(jié)點發(fā)送部分未同步數(shù)據(jù)即可劣砍。
- 如果上述條件存在未滿足的，則回復+FULLRESYNC {runid} {offset},表示進行全量復制扇救，runid為主節(jié)點的runid刑枝，offset為主節(jié)點的當前offset香嗓。從節(jié)點需要存儲這兩個值，供同步數(shù)據(jù)使用装畅。
主從復制流程
主從復制大致可以分三個流程
- 主從連接建立階段
- 數(shù)據(jù)同步階段
- 命令傳輸階段
連接建立階段
-
保存主節(jié)點信息
- 從節(jié)點執(zhí)行slaveof命令后靠娱，先將主節(jié)點的host 和 port信息保存，用于之后到主從節(jié)點通信掠兄，然后既返回OK像云，復制操作是異步執(zhí)行的。
-
建立socket連接
- <font style="color:rgb(51,51,51);">slaveof 命令執(zhí)行后蚂夕，從節(jié)點每秒1次調(diào)用復制定時函數(shù)replicationCron()迅诬，如果發(fā)現(xiàn)了有主節(jié)點可信息，便會根據(jù)主節(jié)點的ip和port婿牍，創(chuàng)建socket連接侈贷。</font>
- <font style="color:rgb(51,51,51);">創(chuàng)建socket連接時，如果主節(jié)點存在密碼等脂，則需要從節(jié)點中設置masterauth選項俏蛮，從節(jié)點需要向主節(jié)點進行身證；沒有配置該選項上遥，則不需要驗證搏屑。如果身份驗證通過，復制過程繼續(xù)粉楚；如果不一致辣恋，則從節(jié)點斷開socket連接，并重連模软。</font>
- <font style="color:rgb(51,51,51);">socket連接創(chuàng)建成功</font>
- <font style="color:rgb(51,51,51);">從節(jié)點</font><font style="color:rgb(51,51,51);">: 為該socket建立一個專門處理復制工作的文件事件處理器抑党，負責后續(xù)的復制工作，如接收RDB文件撵摆、接收主節(jié)點傳輸?shù)拿畹取?lt;/font>
- 主節(jié)點：socket建立連接（即完成accept操作）后，主節(jié)點會為這個連接創(chuàng)建一個專門的客戶端狀態(tài)害晦。此時特铝，從節(jié)點就是連接至主節(jié)點的一個客戶端。后續(xù)交互都是以從節(jié)點向主節(jié)點發(fā)送命令請求的方式進行壹瘟。
- <font style="color:rgb(51,51,51);">從節(jié)點成為主節(jié)點的客戶端之后鲫剿，發(fā)送ping命令進行首次請求，目的是：檢查socket連接是否可用稻轨，以及主節(jié)點當前能否處理請求灵莲。 </font>
- <font style="color:rgb(51,51,51);">從節(jié)點發(fā)送ping命令后，可能出現(xiàn)3種情況： </font>
- <font style="color:rgb(51,51,51);">返回pong：說明socket連接正常殴俱，且主節(jié)點當前可以處理請求政冻，復制過程繼續(xù)枚抵。</font>
- <font style="color:rgb(51,51,51);">超時：一定時間后從節(jié)點仍未收到主節(jié)點的回復，說明socket連接不可用明场，則從節(jié)點斷開socket連接汽摹，并重連。 </font>
- <font style="color:rgb(51,51,51);">返回pong以外的結(jié)果：如果主節(jié)點返回其他結(jié)果苦锨，如正在處理超時運行的腳本逼泣，說明主節(jié)點當前無法處理命令，則從節(jié)點斷開socket連接舟舒，并重連拉庶。</font>
- <font style="color:rgb(51,51,51);">從節(jié)點發(fā)送ping命令后，可能出現(xiàn)3種情況： </font>
- 發(fā)送從節(jié)點端口信息
<font style="color:rgb(51,51,51);">socket成功建立之后，從節(jié)點會向主節(jié)點發(fā)送其監(jiān)聽的端口號（前述例子中為6380）秃励，主節(jié)點將該信息保存到從節(jié)點對應的客戶端的slave_listening_port字段中氏仗； </font>
:::tips
??<font style="color:rgb(51,51,51);">該端口信息除了在主節(jié)點中執(zhí)行info Replication時顯示以外，沒有其他作用莺治。</font>
:::
數(shù)據(jù)同步階段
<font style="color:rgb(51,51,51);">主從節(jié)點之間的連接建立以后廓鞠，便可以開始進行數(shù)據(jù)同步，該階段可以理解為從節(jié)點數(shù)據(jù)的初始化谣旁。同步方式需要判斷全量復制還是部分復制床佳，判斷過程見4.1所示。下邊詳細介紹全量復制過程和部分復制過程榄审。</font>
全量復制過程
<font style="color:rgb(51,51,51);">Redis通過psync命令進行全量復制的過程如下： </font>
- <font style="color:rgb(51,51,51);">從節(jié)點判斷無法進行部分復制砌们，向主節(jié)點發(fā)送全量復制的請求；或從節(jié)點發(fā)送部分復制的請求搁进， 但主節(jié)點判斷無法進行部分復制浪感； </font>
- <font style="color:rgb(51,51,51);">主節(jié)點收到全量復制的命令后，執(zhí)行bgsave饼问，在后臺生成RDB文件影兽，并使用一個緩沖區(qū)（稱為復制緩沖區(qū)）記錄從現(xiàn)在開始執(zhí)行的所有寫命令。</font>
- <font style="color:rgb(51,51,51);">主節(jié)點的bgsave執(zhí)行完成后莱革，將RDB文件發(fā)送給從節(jié)點峻堰；</font><font style="color:rgb(51,51,51);">從節(jié)點接收完成之后，首先清除自己的舊數(shù)據(jù)盅视，然后載入接收的RDB</font><font style="color:rgb(51,51,51);">文件捐名，將數(shù)據(jù)庫狀態(tài)更新至主節(jié)點執(zhí)行bgsave時的數(shù)據(jù)庫狀態(tài) </font>
- <font style="color:rgb(51,51,51);">主節(jié)點將前述復制緩沖區(qū)中的所有寫命令發(fā)送給從節(jié)點，從節(jié)點執(zhí)行這些寫命令闹击，將數(shù)據(jù)庫狀態(tài)更新至主節(jié)點的最新狀態(tài) </font>
- <font style="color:rgb(51,51,51);">如果從節(jié)點開啟了AOF镶蹋，則會觸發(fā)bgrewriteaof的執(zhí)行，從而保證AOF文件更新至主節(jié)點的最新狀態(tài) </font>
<font style="color:rgb(51,51,51);">下面是執(zhí)行全量復制時，主從節(jié)點打印的日志贺归；可以看出日志內(nèi)容與上述步驟是完全對應的淆两。 </font>
<font style="color:rgb(51,51,51);">主節(jié)點的打印日志如下： </font>
<font style="color:rgb(51,51,51);">從節(jié)點打印日志如下圖所示： </font>
:::warning
?? <font style="color:rgb(51,51,51);">從節(jié)點接收了來自主節(jié)點的89260個字節(jié)的數(shù)據(jù)，在載入主節(jié)點的數(shù)據(jù)之前要先將老數(shù)據(jù)清除牧氮； </font>
:::
:::color1
?? <font style="color:rgb(51,51,51);">從節(jié)點在同步完數(shù)據(jù)后琼腔，調(diào)用了bgrewriteaof。通過全量復制的過程可以看出踱葛，全量復制是非常重型的操作： </font>
- <font style="color:rgb(51,51,51);">性能損耗</font><font style="color:rgb(51,51,51);">：主節(jié)點通過bgsave命令fork子進程進行RDB持久化丹莲，該過程是非常消耗CPU、內(nèi)存(頁 表復制)尸诽、硬盤IO的甥材。</font>
- <font style="color:rgb(51,51,51);">帶寬占用：</font><font style="color:rgb(51,51,51);">主節(jié)點通過網(wǎng)絡將RDB文件發(fā)送給從節(jié)點，對主從節(jié)點的帶寬都會帶來很大的消耗性含。</font>
- <font style="color:rgb(51,51,51);">停服載入：</font><font style="color:rgb(51,51,51);">從節(jié)點清空老數(shù)據(jù)洲赵、載入新RDB文件的過程是阻塞的，無法響應客戶端的命令商蕴；如果從節(jié)點執(zhí)行bgrewriteaof叠萍，也會帶來額外的消耗。</font>
:::
:::danger
?? <font style="color:rgb(51,51,51);">全量復制的弊端：</font>
<font style="color:rgb(51,51,51);">觸發(fā)場景：</font>
- <font style="color:rgb(51,51,51);">新創(chuàng)建的slave绪商，從主機master同步數(shù)據(jù)苛谷。</font>
- <font style="color:rgb(51,51,51);">剛宕機一小會的slave，從主機master同步數(shù)據(jù)格郁。 </font>
<font style="color:#117CEE;">前者新建的slave則從主機master全量同步數(shù)據(jù)腹殿，這沒啥問題。但是后者slave可能只與master存在小量的數(shù)據(jù)差異例书，要是全量同步肯定沒有只同步差異（部分復制）少量數(shù)據(jù)的性能高锣尉。</font>
:::
部分復制過程
部分復制是Redis為了降低全量復制高成本而采取的優(yōu)化方法，通過使用psync {runId} {offset}命令來實現(xiàn)决采。當從節(jié)點復制主節(jié)點數(shù)據(jù)期間發(fā)生網(wǎng)絡中斷或命令丟失等異常自沧，從節(jié)點會請求主節(jié)點補充丟失的數(shù)據(jù)。如果主節(jié)點的復制緩沖區(qū)保存了這些丟失的數(shù)據(jù)树瞭，它將直接傳送至從節(jié)點暂幼，確保主從數(shù)據(jù)一致性。相比全量復制移迫，這種只補充差異數(shù)據(jù)的方式大大減少了數(shù)據(jù)傳輸量，從而降低了開銷管行。
部分復制步驟：
- 出現(xiàn)網(wǎng)絡中斷超時（超過repl-timeout）厨埋，主節(jié)點與從節(jié)點的復制連接斷開，視為從節(jié)點故障捐顷。
- socket連接中斷期間荡陷，主節(jié)點正常服務雨效，但命令無法傳至從節(jié)點。主節(jié)點最近寫操作可暫存在復制積壓緩沖區(qū)<font style="color:rgb(51,51,51);">( repl-backlog-buffer )</font>中废赞，默認大小1MB徽龟，以備連接恢復后進行部分復制。
- 網(wǎng)絡恢復后唉地，從節(jié)點主動重連主節(jié)點据悔。
- 主從節(jié)點重新建立連接后，從節(jié)點用之前記錄的偏移量和主節(jié)點runId作為psync指令耘沼，請求缺失數(shù)據(jù)補發(fā)极颓。
- 主節(jié)點確認psync指令中的runId匹配且所需偏移量后的數(shù)據(jù)仍在其緩沖區(qū)中，則同意部分復制群嗤，發(fā)送+CONTINUE響應菠隆。
- 主節(jié)點依據(jù)偏移量提供緩沖區(qū)數(shù)據(jù)給從節(jié)點，確保主從節(jié)點數(shù)據(jù)一致狂秘，主從復制流程恢復正常骇径。
命令傳輸階段
<font style="color:rgb(51,51,51);">數(shù)據(jù)同步階段完成后，主從節(jié)點進入命令傳輸階段者春；</font>
<font style="color:rgb(51,51,51);">在這個階段主節(jié)點將自己執(zhí)行的寫命令發(fā)送給從節(jié)點破衔，從節(jié)點接收命令并執(zhí)行，從而保證主從節(jié)點數(shù)據(jù)的一致性碧查。 </font>
<font style="color:rgb(51,51,51);">在命令傳輸階段运敢，除了發(fā)送寫命令，主從節(jié)點還維持著心跳機制：PING和REPLCONF ACK忠售。 心跳機制對于主從復制的超時判斷传惠、數(shù)據(jù)安全等有作用。</font>
- 主節(jié)點向從節(jié)點發(fā)送ping命令
<font style="color:rgb(51,51,51);">每隔指定的時間稻扬，</font><font style="color:rgb(51,51,51);">主節(jié)點會向從節(jié)點發(fā)送PING命令</font><font style="color:rgb(51,51,51);">卦方，這個PING命令的作用，主要是為了讓從節(jié)點進行網(wǎng)絡超時判斷泰佳。 PING發(fā)送的頻率由 repl-ping-slave-period 參數(shù)控制盼砍，單位是秒，默認值是10s逝她。 </font>
:::tips
?? 關于該PING命令究竟是由主節(jié)點發(fā)給從節(jié)點浇坐，還是從節(jié)點發(fā)到主節(jié)點，有一些爭議黔宛；
因為在Redis的官方文檔中近刘，對該參數(shù)的注釋中說明是從節(jié)點向主節(jié)點發(fā)送PING命令，如下所
示：
:::
# Slaves send PINGs to server in a predefined innterval.It'spossibletochange
#this interval with the repl_ping_slave_period option.Thedefault value is 10
#seconds.
#
# repl-ping-slave-period 10
:::tips
但是通過源碼可以看到， PING命令是主節(jié)點會向從節(jié)點發(fā)送.
可能的原因是：代碼的迭代和注釋的迭代觉渴，沒有完全同步介劫。 可能早期是從發(fā)給主，后面改成了主
發(fā)從案淋，而并沒有配套修改注釋座韵。
從理論層面看，大部份組件的集群模式都是一主多副本踢京，通信方式也是從節(jié)點請求主節(jié)點誉碴，主從節(jié)點耦合度更低，是否同步漱挚、何時同步都由從節(jié)點控制翔烁。
從實際效果來看，應該主節(jié)點發(fā)到從節(jié)點這種方案更好一些旨涝，因為命令延遲更低蹬屹，同步速度更快。
:::
- 從節(jié)點向主節(jié)點發(fā)送REPLCONF ACK命令
<font style="color:rgb(51,51,51);">在命令傳播階段白华，</font><font style="color:rgb(51,51,51);">從節(jié)點會向主節(jié)點發(fā)送REPLCONF ACK命令慨默，</font><font style="color:rgb(51,51,51);">頻率是每秒1次； 命令格式為：REPLCONF ACK {offset}弧腥，其中offset指從節(jié)點保存的復制偏移量厦取。 </font>
<font style="color:rgb(51,51,51);">REPLCONF ACK命令的作用包括： </font>
- <font style="color:rgb(51,51,51);">實時監(jiān)測主從節(jié)點網(wǎng)絡狀態(tài)：該命令會被主節(jié)點用于復制超時的判斷。此外管搪，在主節(jié)點中使用info Replication虾攻，可以看到其從節(jié)點的狀態(tài)中的lag值，代表的是主節(jié)點上次收到該REPLCONF ACK命令的時間間隔更鲁，在正常情況下霎箍，該值應該是0或1，： </font>
- <font style="color:rgb(51,51,51);">檢測命令丟失：從節(jié)點發(fā)送了自身的offset澡为，主節(jié)點會與自己的offset對比漂坏，如果從節(jié)點數(shù)據(jù)缺失 （如網(wǎng)絡丟包），主節(jié)點會推送缺失的數(shù)據(jù)（這里也會利用復制積壓緩沖區(qū)）媒至。 </font>
:::tips
?? <font style="color:rgb(119,119,119);"> </font>**offset和復制積壓緩沖區(qū)顶别，不僅可以用于部分復制，也可以用于處理命令丟失等情形拒啰；區(qū)別在于前者是在斷線重連后進行的驯绎，而后者是在主從節(jié)點沒有斷線的情況下進行的。 **
:::
- <font style="color:rgb(51,51,51);">輔助保證從節(jié)點的數(shù)量和延遲：Redis主節(jié)點中使用min-slaves-to-write和min-slaves-max-lag參 數(shù)谋旦，來保證主節(jié)點在不安全的情況下不會執(zhí)行寫命令条篷；所謂不安全骗随，是指從節(jié)點數(shù)量太少，或延遲過 高赴叹。</font>
:::tips
?? 例如min-slaves-to-write和min-slaves-max-lag分別是3和10，含義是如果從節(jié)點數(shù)量小于3個指蚜，或所有從節(jié)點的延遲值都大于10s乞巧，則主節(jié)點拒絕執(zhí)行寫命令。而這里從節(jié)點延遲值的獲取摊鸡，就是通過主節(jié)點接收到REPLCONF ACK命令的時間來判斷的绽媒，即前面所說的info Replication中的lag值。
:::
本文由博客一文多發(fā)平臺 OpenWrite 發(fā)布免猾！
