1.主從配置：
3種配置主從的方式：
a.配置文件slaveof {masterHost} {masterPort}
b. redis-server --slaveof {masterHost} {masterPort}
c. slaveof {masterHost} {masterPort} 命令
斷開主從複製關係：從節點執行slaveof no one
切主操作流程：斷開與舊主節點的複製關係→與新主節點建立複製關係→刪除從節點當前所以數據→對新節點進行復制操作
數據傳輸延遲repl-disable-tcp-nodelay參數：用於控制是否關閉tcp-nodelay,默認關閉；關閉時,主節點產生的命令數據無論大小都會及時發送給從節點,主從延遲變小,網絡帶寬消耗增加,開啓時,主節點會合並較小的TCP數據包,默認間隔40毫秒發送一次,主從延遲變大,網絡帶寬消耗減少
2.三種複製拓撲結構：
A.一主一從：用於主節點出現故障時從節點提供故障轉移,當應用寫命令併發量較高且需要持久化時,可以只在從節點上開啓aof,當主節點關閉持久化功能時,要避免自動重啓操作,因爲主節點沒開啓持久化功能自動重啓後數據集爲空,這是從節點如果繼續複製主節點將導致從節點數據也被清空,安全的做法是先在從節點上執行slaveof no one命令,與主節點斷開復制關係,再重啓主節點
B.一主多從：可利用多個從節點實現讀寫分離,對於讀佔比較大的場景,可以把讀命令發送到從節點來分擔主節點壓力,同時在日常開發中如果需要執行一些比較耗時的讀命令,如：keys、sort等,可以在其中一臺從節點上執行,防止慢查詢對主節點造成阻塞從而影響線上服務的穩定性；但對於寫併發量較高的場景，多個從節點會導致主節點寫命令的多次發送從而過度消耗網絡帶寬,同時也加重了主節點的負載影響服務穩定性
C.樹狀結構：從節點不但可以複製主節點數據,同時可以作爲其他從節點的主節點繼續向下層複製,通過引入複製中間層,可以有效降低主節點負載和需要傳送給從節點的數據量, 數據實現了一層一層的向下複製,當主節點需要掛載多個從節點時爲了避免對主節點的性能干擾,可以採用樹狀主從結構降低主節點壓力
3.複製流程：
A.複製的大體流程：
a.保存主節點信息：執行完slaveof命令後從節點只保存主節點的信息地址便返回,此時建立複製流程還未開始
b.主從建立socket連接：從節點內部通過每秒運行定時任務維護複製相關邏輯,當定時任務發現存在新的主節點後,會嘗試與該節點建立網絡連接,若無法建立連接,定時任務會無限重試直到連接成功或執行slaveof no one命令爲止
c.發送ping命令：用於檢測主從之間網絡套接字是否可用和主節點當前是否可接受處理命令,若從節點沒收到主節點的pong回覆或超時,則斷開復制連接,下次定時任務會發起重連
d.權限驗證：若主節點設置了requirepass參數,則需要密碼驗證,從節點必須配置masterauth參數保證與主節點相同的密碼才能通過驗證,若驗證失敗則複製終止,從節點重新發起復制流程
e.數據集同步：主從複製連接正常通信後,對於首次建立複製的場景,主節點會把持有的數據全部發送給從節點,這步操作耗時最長(全量複製)
f.命令持續複製：當主節點把當前的數據同步給從節點後,便完成複製的建立流程,接下來主節點會持續把寫命令發送給從節點,保證主從數據一致性
B.數據同步(基於psync命令)：
全量複製：用於初次複製場景(不可避免),主節點將全部數據一次性發送給從節點,當數據量較大時,會對主從節點與網絡造成很大開銷
部分複製：用於處理在主從複製中因網絡閃斷等原因造成的數據丟失的場景,當從節點再次連上主節點後,如果條件允許,主節點會補發丟失數據給從節點,因爲補發的數據遠遠小於全量數據,可以有效避免全量複製的過高開銷
psync命令：需複製偏移量、複製積壓緩衝區、主節點運行id支持
複製偏移量：用於記錄主從節點數據同步偏差的量,可用info replication查看
複製積壓緩衝區：保存在主節點上的一個固定長度的隊列,默認大小1M,當主節點有連接的從節點被創建時,主節點響應寫命令時,不但會把命令發送給從節點，還會寫入複製積壓緩衝區,可用info replication查看,用於數據補救
主節點運行id：每個主節點的唯一標識,運行id變化,則從節點發生全量複製,可使用info server查看(PS：若只是用ip+port方式進行標識,當主節點重啓變更整體數據集(如替換RDB/AOF文件),從節點再基於偏移量複製數據將不再安全,redis重啓,運行id也會改變)
不改變運行ID的情況下重啓：使用debug reload命令(PS：該命令會阻塞當前redis節點主線程,阻塞期間會生成本地RDB快照並清空數據後再加載RDB文件,對於大數據量的主節點和無法容忍阻塞的場景,慎用！)
psync命令流程：psync runId(主節點運行id) offset(從節點複製偏移量)
a.從節點(slave)發送psync命令給主節點,若是第一次參與複製則offset爲-1
b.主節點(master)根據psync參數和自身數據情況決定響應結果：
若回覆+FULLRESYNC {runId} {offset}，則從節點將觸發全量複製流程
若回覆+CONTINUE，則從節點將觸發部分複製流程
若回覆+ERR，說明主節點版本低於Redis2.8,無法識別psync命令,從節點將發送舊版的sync命令觸發全量複製流程
C.全量複製流程：
1.發送psync命令進行數據同步,是第一次進行復制,從節點沒有複製 偏移量和主節點的運行id,所以發送psync-1
2.主節點解析出爲全量複製,回覆+FULLRESYNC響應
3.從節點接收主節點的響應數據保存運行id和偏移量offset
4.主節點執行bgsave保存RDB文件到本地
5.主節點發送RDB文件給從節點,從節點把接收的RDB文件保存在本地並直接作爲從節點的數據文件
6.從節點接收RDB快照期間,主節點仍響應讀寫命令,因此主節點會把這期間寫命令數據保存在複製客戶端緩衝區,從節點加載完RDB文件後,主節點再把緩衝區內數據發送給從節點,保證主從數據一致性,若主節點創建和傳輸RDB的時間過長,在高流量寫入場景非常容易造成 主節點複製客戶端緩衝區溢出,默認配置爲clientoutput-buffer-limit slave 256MB 64MB 60,若60秒內緩衝區消耗持續大於64MB或直接 超過256MB時,主節點將直接關閉複製客戶端連接,全量同步失敗
7.從節點接收完主節點傳送來的全部數據後會清空自身舊數據
8.從節點清空數據後開始加載RDB文件
9.從節點加載完RDB後,若當前節點開啓aof功能,會立刻做 bgrewriteaof操作,保證全量複製後aof持久化文件立刻可用
PS：RDB文件大於6G的主節點,複製要格外注意,若複製的總時間超 過repl-timeout所配置的值(默認60s),從節點將放棄接受RDB文件並 清理已下載的臨時文件,全量複製將失敗,對於數據量較大的節點,建 議跳大repl-timeout參數防止超時 全量複製主要時間開銷=主節點bgsave+RDB文件網絡傳輸+從節點清空數據+從節點記載RDB+可能的aof重寫
D.部分複製流程：
1.當主從節點之間網絡出現中斷時,若超過repl- timeout時間,主節點會認爲從節點故障並中斷複製連接
2.主從連接中斷期間主節點依然響應命令,但因複製連接中斷命令無法發送給從節點,但主節點內部 存在複製積壓緩衝區,可保存最近一段時間的寫命令數據
3.當主從節點網絡恢復,從節點將再次連上主節點
4.當主從連接恢復後,由於從節點之前保存了自身 已複製的偏移量和主節點的運行id,因此會把它們 當作psync參數發送給主節點,要求進行部分複製 操作
5.主節點接到psync命令後首先覈對參數runId是否與自身一致,若一致,說明之前複製的是當前主節點,之後根據參數offset在自身複製積壓緩衝區查找,如果偏移量之後的數據存在緩衝區中,則對從節點發送+CONTINUE響應, 表示可進行部分複製
6.主節點根據偏移量把複製積壓緩衝區裏的數據發送給從節點,保證主從複製進入正常狀態
4.主從常見問題：
A.讀寫分離：
a.數據延遲：取決於網絡網絡帶寬與命令阻塞情況
處理方式：編寫外部監控程序監聽主從節點的複製偏移量,當延遲較大時觸發報警或通知客戶端避免讀取延遲過高的節點,可採用Zookeeper的監聽回調機制實現客戶端通知,成本較高
b.讀到過期數據：當主節點存儲大量設置超時的數據,且在某一時間點數據大量超時,主節點採樣速度跟不上過期速度且主節點沒讀取過期鍵的操作,則從節點無法收到del命令,此時從節點可以讀取到超時過期的數據
惰性刪除：主節點每次處理讀取命令時,都會檢查鍵是否超時,若超時則執行del命令刪除鍵對象,之後del命令異步發送給從節點(爲保證複製一致性,從節點不會主動刪除超時數據),有可能存在內存泄漏問題,當過期鍵一直沒被訪問將無法及時刪除,從而導致內存不能及時釋放,或者在從節點上可能會讀取到已過期的數據
定時刪除：redis主節點在內部定時任務會循環採樣一定數量的鍵,當發現採用的鍵過期時執行del命令,之後再同步給從節點(後面詳細介紹) 處理方式：從節點讀取數據前檢查鍵的過期時間來決定是否返回數據,可升級到3.2版本來規避
c.從節點故障：
處理方式：客戶端維護可用的從節點列表,當從節點故障時切換到其他從節點或主節點上
B.主從配置不一致：
對於內存方面的配置,主從必須一致,如maxmemory,hash-max-ziplist-entries等參數；當配置的maxmemory從節點小於主節點,如果複製的數據量超過從節點maxmemory時,它會根據maxmemory-policy策略進行內存溢出控制,此時從節點數據已經丟失,但主從複製流程依然正常進行,複製偏移量也正常,修復此類問題只能手動進行全量複製
C.避免全量複製：
a.第一次建立複製,此場景無法避免
b.運行id不匹配,主節點重啓後運行id將改變
c.複製積壓緩衝區不足,當主從節點網絡中斷後,從節點再次連上主節點時會發送psync {offset} {runId}命令請求部分複製,若請求的偏移量不在主節點的積壓緩衝區內,則無法提供給從節點數據,此時部分複製會退化爲全量複製,需根據網絡中斷時長,寫命令數據量分析出合理的積壓緩衝區大小,寫命令數據量可統計高峯期主節點每秒info replication的master_repl_offset差值獲取
D.複製風暴：
指大量從節點對同一主節點或者對同一臺機器的多個主節點短時間內發起全量複製的過程
a.單節點複製風暴：一主多從場景下,主節點重啓後,從節點發起全量複製,主節點創建rdb快照,且多個從節點共享該快照,主節點同時向多個從節點發送rdb快照,可能使主節點網絡帶寬消耗嚴重,主節點延遲變大,甚至發送主從節點連接斷開,複製失敗
解決法案：減少主節點掛載從節點的數量,或採用樹狀複製結構(運維複雜,手動與自動處理故障轉移難度增加)
b.單機器複製風暴：當一臺機器同時部署多個主節點時,若該機器出現故障或網絡長時間中斷,重啓恢復後,會有大量從節點針對這臺機器的主節點進行全量複製,導致當前機器網絡帶寬耗盡
解決方案：應該將主節點儘量分散在多臺機器上,避免單機部署多主節點