在說到Redis主從同步之前先說說同步過程中會用到的Pipeline
Redis客戶端與Redis服務器之間使用TCP協議進行連接，一個客戶端可以通過一個socket連接發起多個請求命令。每個請求命令發出后client通常會阻塞并等待redis服務器處理，redis處理完請求命令后會將結果通過響應報文返回給client，因此當執行多條命令的時候都需要等待上一條命令執行完畢才能執行。
簡單的說普通模式單線程的，而Pipelin模式是類似于并發的
Pipeline
- Plpeline和Linux的管道類似
- Redis基于請求/響應模型，單個請求處理需要一一應答
- Pipeline批量執行指令，節省多次IO往返的時間
- 有順序依賴的指令可以分批發送
一句話：pipeline是通過減少客戶端與redis的通信次數來實現降低往返延時時間，而且Pipeline 實現的原理是隊列，而隊列的原理是時先進先出，這樣就保證數據的順序性。
Pipelin性能雖好但不使用與線上使用，因為線上的操作大都需要及時返還操作結果，但是用在主從的增量同步剛好啊！
Redis主從同步可分為兩種：全量同步和增量同步
主從全量同步：一般發生在Slave初始化階段
- Slave發送sync命令道Master
- Master啟動一個后臺進程，將Redis中的數據快照保存到文件中（BGSAVE）
- Master將保存數據快照期間指令收集到寫指令緩存起來
- Master完成寫文件操作后，將該文件發送給Slave，并在發送期間繼續記錄被執行的寫命令
- Slave丟棄所有舊數據，載入新的快照
-
Slave完成快照載入，開始接受命令請求，并執行Master發送的緩存指令
image.png
主從增量同步：Slave初始化后開始正常工作時主服務器發生的寫操作同步到從服務器的過程
- Master接收到用戶的操作指令，判斷是否需要傳播到Slave
- 將操作記錄追加到AOF文件
- 將操作傳播到其他Slave：a對齊主從庫；b往相應緩存寫入指令
- 將緩存數據發送給Slave
- Slave執行Master發送的緩存指令
Redis主從可以用來讀寫分離，Master用來處理寫操作，Slave處理讀操作（可能會有延遲），但畢竟是單點，萬一Master宕機了怎么辦？那么就有了哨兵機制的出現，通過自動完成故障發現和轉移保證服務的高可用。
Redis Sentinel：解決主從同步Master宕機后主從切換問題
監控：檢查主從服務器是否正常運行
* 每個哨兵節點每10秒會向主節點和從節點發送info命令獲取最拓撲結構圖，哨兵配置時只要配置對主節點的監控即可，通過向主節點發送info，獲取從節點的信息，并當有新的從節點加入時可以馬上感知到；
* 每個哨兵節點每隔2秒會向redis數據節點的指定頻道上發送該哨兵節點對于主節點的判斷以及當前哨兵節點的信息，同時每個哨兵節點也會訂閱該頻道，來了解其它哨兵節點的信息及對主節點的判斷，其實就是通過消息publish和subscribe來完成的
* 每隔1秒每個哨兵會向主節點、從節點及其余哨兵節點發送一次ping命令做一次心跳檢測，這個也是哨兵用來判斷節點是否正常的重要依據
提醒：通過API向管理員或其他應用程序發送故障通知
自動故障遷移：主從切換
* 選出一個Slave脫離原從節點升級為主節點
* 將其他Slave指向新的主節點
* 通知客戶端主節點已更換
* 將原Master變成從節點，指向新的Master
流言協議Goddip--在雜亂無章中需求一致
- 每個節點都隨機與對方通信，最終所有節點的狀態達成一致
- 種子節點定期隨機向其他節點發送節點列表以及需要傳播的消息
- 不保證信息一定會傳遞到所有節點，但保證最終的一致性
