【Redis】15.Redis主从复制
主從復制簡介
互聯網“三高”架構
你的"Redis"是否高可用
單機redise風險與問題
- 問題1 機器故障
現象：硬件故障、系統崩潰
本質：數據丟失，很可能對業務造成災難性打擊
結論：基本上會放棄使用redis - 問題2 容量瓶頸
現象：內存不足，從16G升級到64G，無限升級內存
本質：窮，硬件條件跟不上
結論：放棄使用redis - 結論：
為了避免單點redis服務器故障，準備多臺服務器，互相連通。將數據復制多個副本保存在不同的服務器上，連接在一起，并保證數據是否同步的，即使有其中一臺服務器宕機，其他服務器依然可以繼續提供服務，實現Redis的高可用，同時實現數據冗余備份。
多臺服務器連接方案
- 提供多數據方：master
主服務器，主節點，主庫
主客戶端 - 接受數據方：slave
從服務器，從節點，從庫
從客戶端 - 需要解決的問題
數據同步 - 核心工作
master的數據復制到slave中
主從復制
主從復制即將master中的數據即時，有效的復制到slave中
特征：一個master可以擁有多個slave,一個slave只對應一個master
職責：
- master:
寫數據
執行寫操作時，將出現變化的數據自動同步到slave
讀數據（可忽略） - slave:
讀數據
寫數據（禁止）
高可用集群
主從復制的作用
- 讀寫分離：master寫，slave讀，提高服務器的讀寫負載能力
- 負載均衡：基于主從結構，配合讀寫分離，由slave分擔master負載，并根據需求的變化，改變slave的數量，通過多個從節點分擔數據讀取負載，大大提高Redis服務器并發量與數據吞吐量
- 故障恢復：當master出現問題時，由slave提供服務，實現快速的故障恢復
- 數據冗余：實現數據熱備份，時持久化之外的一種數據冗余方式
- 高可用基石：基于主從復制，構建哨兵模式與集群，實現Redis的高可用方案
主從復制工作流程
總述
- 主從復制過程大體可以分為3個階段
建立連接階段（即準備階段）
數據同步階段
命令傳播階段
階段一：建立鏈接 - 建立slave到master的鏈接，使master能夠識別slave，并保存slave端口號
至此，主從鏈接成功！
狀態：
slave：保存master的地址和端口
master：保存slave的端口
總體：之間創建了鏈接的socket
主從鏈接(slave鏈接master)
- 方式一：客戶端發送命令
slaveof< masterip>< masterport>
- 方式二：啟動服務器參數
redis-server --slaveof < masterip>< masterport>
- 方式三：服務器配置(主流方式：通過配置文件配置)
slaveof < masterip>< masterport>
- slave信息系統
master_link_down_since_second
masterhost
masterport - master信息系統
slave_listening_port(多個)
主從斷開鏈接
- 客戶端發送命令
slaveof no one
授權訪問
階段二、數據同步階段工作流程
- 在slave初次鏈接master后，復制master中的所有數據到slave
- 將slave的數據庫狀態更新成master當前數據庫狀態
步驟1：請求同步
步驟2：創建RDB同步數據
步驟3：恢復RDB同步數據
步驟4：請求部分同步數據
步驟5：恢復部分同步數據
至此，數據同步工作完成
狀態：
slave：具有master端全部數據，包含RDB過程接收的數據
master：保存slave當前數據同步的位置
總體：之間完成了數據克隆
數據同步階段master說明
repl-backlog-size 1mb(默認1mb)
數據同步階段slave說明
slave-server-stale-data yes|no
階段三：命令傳播階段
- 當master數據庫狀態被修改后，導致主從服務器數據庫狀態不一致，此時需要讓主從數據同步到一致的狀態，同步的動作成為命令傳播
- master將接受到的數據變更命令發送給slave，slave接受命令后執行命令。
命令傳播階段的部分復制
- 命令傳播階段出現了斷網的現象
網絡閃斷閃連 忽略
短時間網絡中斷 部分復制
長時間網絡中斷 全量復制 - 部分復制的三個要素
服務器的運行id (run id)
主服務器的復制積壓緩沖區
主從服務器的復制偏移量
服務器運行id
復制緩沖區
- 概念：復制緩沖區，又名復制積壓緩沖區，時一個先進先出（FIFO）的隊列，用于存儲服務器執行過的命令，每次傳播命令，master會將傳播的命令記錄下來，并存儲在復制緩沖區
復制緩沖區默認存儲空間大小是1M，由于存儲空間大小是固定的，當入隊元素的數量大于隊列長度時，最先入隊的元素會被彈出，而新元素會被放入隊列 - 由來：每臺服務器啟動時，如果開啟有AOF或被鏈接成為master節點，即創建復制緩沖區。
- 作用：用來保存master收到的所有指令（僅影響數據變更的指令，例如set,select）
- 數據來源：
當master接收到主客戶端的指令時，除了將指令執行，會將該指令存儲到緩沖區中。
master端：發送一次記錄一次
slaver端：接受一次記錄一次 - 組成
偏移量
字節值 - 工作原理
主從服務器復制偏移量（offset）
- 概念：一個數字，描述復制緩沖區中的指令字節位置
- 分類：
master復制偏移量：記錄發送給所有slave的指令字節對應的位置（多個）
slave復制偏移量：記錄slave接受master發送過來的指令字節對應的位置（一個） - 數據來源：
master端：發送一次記錄一次
slave端：接收一次記錄一次 - 作用：同步信息，對比master與slave的差異，當slave斷線后，恢復數據使用
數據同步+命令傳播階段工作流程
心跳機制
- 進入命令傳播階段后，master與slave間需要進行信息交換，使用心跳機制進行維護，實現雙方連接保持在線
- master心跳
指令：PING
周期：由repl-ping-slave-period決定，默認10秒
作用：判斷slave是否在線
查詢： INFO replication 獲取slave最后一次鏈接時間間隔,lag項維持在0或1視為正常 - slave心跳指令
指令：REPLCONF ACK{offset}
周期：1秒
作用1：匯報slave自己的復制偏移量，獲取最新的數據變更指令
作用2：判斷master是否在線
心跳階段注意事項 - 當slave多數掉線，或延遲過高時，master為保障數據穩定性，將拒絕所有信息同步操作
min-slave-to-write 2
min-slave-max-lag 8
slave數量少于2個或者多有slave延遲都大于等于10秒時，強制關閉master寫功能，停止數據同步
- slave數量由slave發送REPLCONF ACK命令做確認
- slave延遲由slave發送REPLCONF ACK命令做queen
主從復制完整工作流程
主從復制常見問題
頻繁的全量復制（1）
伴隨著系統的運行,master的數據量會越來越大，一旦master重啟，runid將發生變化，會導致全部salve的全量復制操作
頻繁的全量復制（2）
- 問題現象
網絡環境不佳，出現網絡中斷，slave不提供服務 - 問題原因
復制緩沖區過小，斷網后slave的offset越界，觸發全量復制 - 最終結果
slave反復進行全量復制 - 解決方案
修改復制緩沖區大小
repl-backlog-size
- 建議設置如下
1.測算從master到slave的重連平均時長second
2.獲取master平均每秒產生寫命令數據總量write_size_per_second
3.最優復制緩沖區空間=2 * second * write_size_per_second
頻繁的網絡中斷（1）
- 問題現象
master的CPU占用過高或slave頻繁斷開連接 - 問題原因
slave每1秒發送REPLCONF ACK命令到master
當slave連接了慢查詢時（keys * , hgetall等），會大量占用CPU性能
master每1秒調用復制定時函數replicationCron（）輪尋時，對比slave發現長時間沒有進行響應 - 最終結果
master各種資源（輸出緩沖區、寬帶、連接等）被嚴重占用 - 解決方案
通過設置合理的超時時間，確認是否釋放slave
repl-timeout
該參數定義了超時時間的閾值（默認60秒），超過該值，釋放slave
頻繁的網絡中斷（2）
- 問題現象
slave與master連接斷開 - 問題原因
master發送ping指令頻度較低
master設定超時時間較短
ping指令在網絡中存在丟包 - 解決方案
提高ping指令發送的頻度
repl-ping-slave-period
超時時間repl-time的時間至少是ping指令頻度的5-10倍，否則slave很容易判定超時
數據不一致
- 問題現象
多個slave獲取相同數據不同步 - 問題原因
網絡信息不同步，數據發送有延遲 - 解決方案
優化主從間的網絡環境，通常防止在同一個機房部署，如使用阿里云等云服務器時要注意此現象
監控主從節點延遲（通過offset）判斷，如果slave延遲過大，暫時屏蔽程序對該slave的數據訪問
slave-server-stale-data yes|no
開啟后僅響應info、slaveof等少數命令（慎用，除非對數據一致性要求很高）
總結
以上是生活随笔為你收集整理的【Redis】15.Redis主从复制的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【Redis】14.Redis高级数据类
- 下一篇： 【Redis】16.Redis哨兵