在說到Redis主從同步之前先說說同步過程中會(huì)用到的Pipeline

Redis客戶端與Redis服務(wù)器之間使用TCP協(xié)議進(jìn)行連接，一個(gè)客戶端可以通過一個(gè)socket連接發(fā)起多個(gè)請求命令。每個(gè)請求命令發(fā)出后client通常會(huì)阻塞并等待redis服務(wù)器處理，redis處理完請求命令后會(huì)將結(jié)果通過響應(yīng)報(bào)文返回給client，因此當(dāng)執(zhí)行多條命令的時(shí)候都需要等待上一條命令執(zhí)行完畢才能執(zhí)行。
簡單的說普通模式單線程的，而Pipelin模式是類似于并發(fā)的

Pipeline

• Plpeline和Linux的管道類似
• Redis基于請求/響應(yīng)模型，單個(gè)請求處理需要一一應(yīng)答
• Pipeline批量執(zhí)行指令，節(jié)省多次IO往返的時(shí)間
• 有順序依賴的指令可以分批發(fā)送

一句話：pipeline是通過減少客戶端與redis的通信次數(shù)來實(shí)現(xiàn)降低往返延時(shí)時(shí)間，而且Pipeline 實(shí)現(xiàn)的原理是隊(duì)列，而隊(duì)列的原理是時(shí)先進(jìn)先出，這樣就保證數(shù)據(jù)的順序性。

Pipelin性能雖好但不使用與線上使用，因?yàn)榫€上的操作大都需要及時(shí)返還操作結(jié)果，但是用在主從的增量同步剛好?。?/p>

Redis主從同步可分為兩種：全量同步和增量同步

主從全量同步：一般發(fā)生在Slave初始化階段

1. Slave發(fā)送sync命令道Master
2. Master啟動(dòng)一個(gè)后臺(tái)進(jìn)程，將Redis中的數(shù)據(jù)快照保存到文件中（BGSAVE）
3. Master將保存數(shù)據(jù)快照期間指令收集到寫指令緩存起來
4. Master完成寫文件操作后，將該文件發(fā)送給Slave，并在發(fā)送期間繼續(xù)記錄被執(zhí)行的寫命令
5. Slave丟棄所有舊數(shù)據(jù)，載入新的快照

6. Slave完成快照載入，開始接受命令請求，并執(zhí)行Master發(fā)送的緩存指令

   
   
   image.png

主從增量同步：Slave初始化后開始正常工作時(shí)主服務(wù)器發(fā)生的寫操作同步到從服務(wù)器的過程

1. Master接收到用戶的操作指令，判斷是否需要傳播到Slave
2. 將操作記錄追加到AOF文件
3. 將操作傳播到其他Slave：a對齊主從庫；b往相應(yīng)緩存寫入指令
4. 將緩存數(shù)據(jù)發(fā)送給Slave
5. Slave執(zhí)行Master發(fā)送的緩存指令

Redis主從可以用來讀寫分離，Master用來處理寫操作，Slave處理讀操作（可能會(huì)有延遲），但畢竟是單點(diǎn)，萬一Master宕機(jī)了怎么辦？那么就有了哨兵機(jī)制的出現(xiàn)，通過自動(dòng)完成故障發(fā)現(xiàn)和轉(zhuǎn)移保證服務(wù)的高可用。

Redis Sentinel：解決主從同步Master宕機(jī)后主從切換問題

監(jiān)控：檢查主從服務(wù)器是否正常運(yùn)行
* 每個(gè)哨兵節(jié)點(diǎn)每10秒會(huì)向主節(jié)點(diǎn)和從節(jié)點(diǎn)發(fā)送info命令獲取最拓?fù)浣Y(jié)構(gòu)圖，哨兵配置時(shí)只要配置對主節(jié)點(diǎn)的監(jiān)控即可，通過向主節(jié)點(diǎn)發(fā)送info，獲取從節(jié)點(diǎn)的信息，并當(dāng)有新的從節(jié)點(diǎn)加入時(shí)可以馬上感知到；
* 每個(gè)哨兵節(jié)點(diǎn)每隔2秒會(huì)向redis數(shù)據(jù)節(jié)點(diǎn)的指定頻道上發(fā)送該哨兵節(jié)點(diǎn)對于主節(jié)點(diǎn)的判斷以及當(dāng)前哨兵節(jié)點(diǎn)的信息，同時(shí)每個(gè)哨兵節(jié)點(diǎn)也會(huì)訂閱該頻道，來了解其它哨兵節(jié)點(diǎn)的信息及對主節(jié)點(diǎn)的判斷，其實(shí)就是通過消息publish和subscribe來完成的
* 每隔1秒每個(gè)哨兵會(huì)向主節(jié)點(diǎn)、從節(jié)點(diǎn)及其余哨兵節(jié)點(diǎn)發(fā)送一次ping命令做一次心跳檢測，這個(gè)也是哨兵用來判斷節(jié)點(diǎn)是否正常的重要依據(jù)
提醒：通過API向管理員或其他應(yīng)用程序發(fā)送故障通知
自動(dòng)故障遷移：主從切換
* 選出一個(gè)Slave脫離原從節(jié)點(diǎn)升級(jí)為主節(jié)點(diǎn)
* 將其他Slave指向新的主節(jié)點(diǎn)
* 通知客戶端主節(jié)點(diǎn)已更換
* 將原Master變成從節(jié)點(diǎn)，指向新的Master

image.png

流言協(xié)議Goddip--在雜亂無章中需求一致

• 每個(gè)節(jié)點(diǎn)都隨機(jī)與對方通信，最終所有節(jié)點(diǎn)的狀態(tài)達(dá)成一致
• 種子節(jié)點(diǎn)定期隨機(jī)向其他節(jié)點(diǎn)發(fā)送節(jié)點(diǎn)列表以及需要傳播的消息
• 不保證信息一定會(huì)傳遞到所有節(jié)點(diǎn)，但保證最終的一致性