主從同步原理
- 剛開始 mater 與 salve 數(shù)據(jù)是不不同步的 過一段時(shí)間后就同步了 就是所謂的最終一致性
- 第一次同步 主節(jié)點(diǎn)做一次bgsave 同時(shí)將后續(xù)操作記錄到內(nèi)存buffer中去 待完成后 將rdb文件全量同步到從節(jié)點(diǎn)，從節(jié)點(diǎn)接收后驹吮，將數(shù)據(jù)加載到內(nèi)存中，加載完成后，再通知主節(jié)點(diǎn)將期間修改的操作以及數(shù)據(jù)同步到從節(jié)點(diǎn)
按照同步內(nèi)容的多少 分為全同步 與增量同步
全同步
- Slave發(fā)送sync命令到Master
- master啟動(dòng)一個(gè)后臺(tái)進(jìn)程，將redis中的快照數(shù)據(jù)保存到文件中 就是bgsave
- master將保存快照數(shù)據(jù)期間接收到的寫命令緩存起來(lái)
- master完成寫文件操作后稳析，將文件發(fā)送給savle
- savle接收到新的文件后驴一，使用新的aof文件替換掉舊的aof文件
- master將期間收集的增量命令發(fā)送給salve端
全量同步完成后 后續(xù)的寫命令都是在master上 讀命令都是在savle上 讀寫分離場(chǎng)景 當(dāng)然 master也可以讀 一般為了提升性能 都只寫 所以用戶的寫操作要及時(shí)的擴(kuò)散到savle 以便保持?jǐn)?shù)據(jù)最大程度上的同步
增量同步
- master接收到用戶的操作命令 判斷是否需要傳播到salve
- 如果是寫命令 追加到aof文件
- 將操作傳播到其他savle 1. 對(duì)齊主從庫(kù) 確保數(shù)據(jù)庫(kù)是該操作數(shù)據(jù)庫(kù) 2. 往相應(yīng)緩存寫入指令
- 將緩存中的數(shù)據(jù)發(fā)送給salve
主從模式的弊端就是 不具備高可用 當(dāng)master掛掉之后 redis將不能對(duì)外提供服務(wù)
Redis Sentinel 解決master宕機(jī)后主從切換問題 監(jiān)控：檢查主服務(wù)器是否運(yùn)行正常 提醒：通過api向管理員或其他應(yīng)用程序發(fā)送故障通知 自動(dòng)故障遷移：主從切換
流言協(xié)議 Gossip 在雜亂無(wú)章中尋求一致
- 每個(gè)節(jié)點(diǎn)都隨機(jī)的與對(duì)方通信 最終所有節(jié)點(diǎn)的狀態(tài)達(dá)成一致
- 種子節(jié)點(diǎn)定期隨機(jī)的向其他節(jié)點(diǎn)列表發(fā)送節(jié)點(diǎn)列表以及需要傳播的信息
- 不保證所有信息一定可以傳遞到所有節(jié)點(diǎn)，但是最終會(huì)趨于一致
