一、Redis主從複製原理與優化：
1、主從複製原理
1.1：單機弊端：機器故障、容量瓶頸、QPS瓶頸
1.2：主節點（1）、子節點（n）===》一主多從；一從只能對一主；數據流向時單項的：主=>從
1.3：主從複製作用（數據部分、擴展性性能）
2、主從複製配置
2.1：客戶端命令實現（不需要重啓服務、但是不便於管理）
2.1.1、客戶端[從服務器]命令實現綁定主節點（slaveof 主IP 主端口號），異步返回給客戶端信息
2.1.2、客戶端[從服務器]命令實現取消複製主節點（slaveof no one），異步返回給客戶端信息【從服務器舊的節點數據不會刪除】
2.2：修改配置文件實現（統一配置便於管理，但需要重啓服務才生效）
2.2.1、slaveof 主ip 主端口號 （綁定主節點）
2.2.2、slave-read-noly yes|no（是否設置爲只讀）
3、全量複製和偏移量
3.1：全量複製（全部複製所有數據備份）
3.1.1：從節點發送psync run_id offset==》主節點接到請求，確認全量複製，發送fullsync run_id offset==》從節點保存信息==》主節點執行bgsave同時處理新寫入請求，並刷新到buffer==》主節點發送rdb==》主節點發送buffer的新數據==》從節點刷新舊數據==》從節點load 新rdb數據
3.2：偏移量（info replication=》master_repl_offset:1888|slave_repl_offset:1978）
4、全量複製開銷
4.1：bgsave（對主節點的cpu、內存、硬盤都有一定的開銷）
4.2：RDB文件網絡傳輸時間
4.3：從節點清空數據時間
4.4：從節點加載RDB時間
4.5：可能的AOF重寫時間
4.6：部分複製（從節點失去連接==》主節點在此區間寫一份數據到緩存中==》從節點重新連接==》發送pysnc run_id offset==》主節點根據偏移量continue複製緩存中的數據==》發送數據給從節點
5、主從複製故障處理（哨兵機制）
5.1：slave宕機
5.2：master宕機
6、開發與運維中的問題
6.1、讀寫分離
6.1.1：讀流量分攤到從節點
6.1.2：可能遇到問題（複製數據延遲、讀到過期的數據、從節點故障）
6.2、主從配置不一致
6.2.1：maxmemory不一致：丟失數據
6.2.2：數據結構優化參數（hash-max-ziplist-entries）：內存不一致
6.3、規避全量複製
6.3.1：第一次全量複製（不可避免、小主節點，低峯）
6.3.2：節點運行ID不匹配（主節點重啓[運行ID變化]、故障轉移。例如哨兵和集羣）
6.3.3：複製積壓緩衝區不足（網絡中斷，部分複製無法滿足；增大複製緩衝區配置rel_backlog_size，網絡"增強"）
6.4、規避複製風暴（出現大量的全量複製）
6.4.1：單主節點複製風暴（問題：主節點重啓，多從節點複製；解決：更換複製拓補）
6.4.2：單機器複製風暴（機器宕機，大量全量複製；主節點分散多機器）