- 主從複製
(1) 主從複製概述：主從複製是指將一臺redis服務器中的數據，複製到其它的redis服務器。前者稱爲主節點(master),後者稱爲從節點；數據的複製是單向的，只能是主節點到從節點
(2) 主從複製的作用
① 數據冗餘：主從複製實現了數據的熱備份，是持久化之外的一種數據冗餘方式
② 故障恢復
③ 負載均衡：在主從複製的基礎上，配合讀寫分離，可以由主節點提供寫服務，由從節點提供讀服務，分擔服務器負載；尤其是在寫多讀少的情況下，通過多個從節點分擔讀負載，可以大大提高redis服務器的併發量
④ 高可用基石
(3) 主從庫之間採用的是讀寫分離的方式
① 讀操作：主庫、從庫都可以接收
② 寫操作：首先到主庫執行，然後，主庫將寫操作同步給從庫
(4) 主從複製原理
① 全量(同步)複製：比如第一次被同步時
② 增量(同步)複製：只會把從庫網絡斷連期間主庫收到的命令，同步給從庫
(5) 全量複製：但我們啓動多個redis實例的時候，他們相互之間就可以通過replicaof命令形成主庫和從庫的關係，之後會按照三個階段完成數據的第一次同步
① 確立主從關係
1) 現在有實例1(ip:172.16 .19.3)和實例2(ip:172.16.19.5),在實例2上執行 命令，實例2就變成了實例1的從庫，並從實例1上覆制數據
2) 命令：replicaof 172.16.19.3 6379
② 全量複製三個階段圖示
③ 全量複製三個階段
1) 主從庫建立連接、協商同步的過程
2) 主庫將所有數據同步給從庫：從庫收到數據後在本地完成加載。整個過程依賴於內存快照生成的RDB文件
3) 主庫會把第二階段執行過程中新受到的寫命令，再發送給從庫：
(6) 增量複製
① 爲什麼會設計增量複製
1) 如果主從庫在命令傳播時出現網絡閃斷，那麼從庫就會和主庫重新進行一次全量複製，開銷非常大。從redis2.8開始，網絡斷了之後，主從庫會採用增量複製的方式繼續同步
② 增量複製的流程圖示
③ 如果在網絡斷開期間，repl_backlog_size環形緩衝區寫滿之後，從庫是會丟失掉那部分被覆蓋掉的數據，還是直接進行全量複製呢？（重點）
1) 一個從庫如果和主庫斷開時間過長，造成它在主庫repl_backlog_buffer的slave_repl_offset位置上的數據已經被覆蓋掉了，此時將會進行全量複製。
2) 每個從庫會記錄自己的slave_repl_offset,每個從庫的複製進度也不一定相同。在和主庫重新連接進行恢復時，從庫會通過psync命令把自己記錄的slave_repl_offset發給主庫，主庫會根據從庫各自的複製進度，來決定這個從庫可以進行增量複製，還是全量複製
(7) 當主服務器不進行持久化時複製的安全性
① 爲什麼不持久化的主服務器自動重啓非常危險呢？反例（後果：主服務器和從服務器中的數據庫都被刪除了）
1) 設置節點A爲主服務器，關閉持久化，節點B和節點C從節點A複製數據
2) 出現奔潰，但是redis具有自動重啓系統，重啓了進程，因爲關閉了持久化，節點重啓後只有一個空的數據集
3) 當在高可用系統中使用Redis Sentinel,關閉的主服務器的持久化，並且允許自動重啓，這種情況是很危險的。比如主服務器在短時間內就完成了重啓，以至於Sentinel都無法檢測到這次失敗，那麼上面所說的這種情況就發生了
4) 注意：如果數據比較重要，並且在使用主從複製時關閉了主服務器持久化功能的場景中，都應該禁止實例自動重啓
② 爲什麼主從全量複製使用RDB而不適用AOF?
1) RDB文件內容是經過壓縮的二進制數據，文件小可以儘量降低對主庫機器網絡帶寬的消耗，成本也比較低
2) 假設要使用AOF做全量複製，就必須打開AOF功能，打開AOF就要選擇文件刷盤的策略，選擇不當會嚴重影響Redis性能。而RDB只有在需要定時備份和主從全量複製數據時纔會觸發生成一次快照。而在很多丟失數據不敏感的業務場景中，其實是不需要開啓AOF的
(8) 讀寫分離及其中的問題
① 延遲與不一致問題
② 數據過期問題
③ 故障切換問題
④ 總結：在使用讀寫分離之前，可以考慮其他方法增加Redis的讀負載能力：如儘量優化主節點（減少慢查詢、減少持久化等其他問題帶來的阻塞）提高負載能力；使用redis集羣同時提高讀負載能力和寫負載能力等。如果使用讀寫分離，可以使用哨兵，使主從節點的故障切換儘可能自動化，並減少對應用程序的入侵