一、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:單機器複製風暴(機器宕機,大量全量複製;主節點分散多機器)