- 主從復制
(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集群同時提高讀負載能力和寫負載能力等。如果使用讀寫分離，可以使用哨兵，使主從節點的故障切換盡可能自動化，並減少對應用程序的入侵