本篇文章給大家了解一下redis中的主從復制，介紹一下主從基本配置、主從配置的作用和原理，希望對大家有所幫助！
redis支持主從復制功能，可以通過執行slaveof（Redis5版本以后改成replicaof）或者在配置文件中設置slaveof（Redis5版本以后改成replicaof）來開啟復制功能。【相關推薦：Redis視頻教程】
- 一主兩叢
- 一主多從
主從基本配置
主Redis配置
主Redis配置基本不用修改，重點部分在從Redis配置
從Redis配置
1、復制一份redis.conf文件
2、相關配置修改
#?salve的端口號 port?6380? #把pid進程號寫入pidfile配置的文件 pidfile?/var/run/redis_6380.pid? logfile?"6380.log"?? #指定數據存放目錄 dir?/usr/local/redis‐5.0.3/data/6380? #需要注釋掉bind #bind127.0.0.1（bind綁定的是自己機器網卡的ip，如果有多塊網卡可以配多個ip，代表允許客戶端通過機器的哪些網卡ip去訪問，內網一般可以不配置bind，注釋掉即可）
3、配置主從復制
#從本機master6379的redis實例復制數據，Redis5.0之前使用slaveof replicaof?192.168.0.60?6379 #配置從節點只讀 replica‐read‐only?yes
4、啟動從節點
redis‐server?redis.conf
5、連接從節點
redis‐cli?‐p?6380
6、測試在6379實例上寫數據，6380實例是否能及時同步新修改數據
docker?run??--name?redis-6381?-v?/Users/yujiale/docker/redis/conf/redis6381.conf:/etc/redis/redis.conf?-v?/Users/yujiale/docker/redis/conf/sentinel6381.conf:/etc/redis/sentine.conf?-v?/Users/yujiale/docker/redis/data6381:/data?--network?localNetwork?--ip?172.172.0.14?-p?16381:6379?-d?redis:6.2.6?redis-server?/etc/redis/redis.conf?--appendonly?yes
主從配置的作用
讀寫分離
- 一主多從，主從同步
- 主負責寫，從負責讀
- 提升Redis的性能和吞吐量
- 主從的數據一致性問題
數據容災
- 從機是主機的備份
- 主機宕機，從機可讀不可寫
- 默認情況下主機宕機后，從機不可為主機利用
- 哨兵可以實現主從切換，做到高可用
Redis主從工作原理
主從復制之全量復制
只有第一次從Redis連接主Redis時發生的是全量復制，如果是短點續傳可能是全量復制，也可能是部分復制。
- 流程圖
1、與主Redis建立Socker長連接
slaver與master建立socket連接
slaver關聯文件事件處理器
- 該處理器接收RDB文件（全量復制）、接收Master傳播來的寫命令（增量復制）
- 主服務器accept從服務器Socket連接后，創建相應的客戶端狀態。相當于從服務器是主服務器的Client端。
-
發送ping命令
-
Slaver向Master發送ping命令
-
1、檢測socket的讀寫狀態
-
2、檢測Master能否正常處理
-
-
Master的響應：
-
1、發送“pong” ,說明正常
-
2、返回錯誤，說明Master不正常
-
3、timeout，說明網絡超時
-
-
- 權限驗證
主從正常連接后，進行權限驗證
主未設置密碼（requirepass=“”），從也不用設置密碼（masterauth=“”）
主設置密碼(requirepass!=””),從需要設置密碼(masterauth=主的requirepass的值)
或者從通過auth命令向主發送密碼
2、主Redis接收到PSYNC命令
主Redis接收到PSYNC命令后執行bgsave命令會生成最新的rdb快照，
3、主Redis把rdb快照發送給從Redis
主Redis發送rdb快照給從Redis時，master會繼續接收客戶端的請求，它會把這些可能修改數據集的請求緩存在內存中存儲到relp buffer緩存中
- 同步快照階段：Master創建并發送快照RDB給Slave，Slave載入并解析快照。Master同時將此階段所產生的新的寫命令存儲到緩沖區。
4、從節點接收到rdb快照
從節點接收到rdb快照后清空老數據，并加載rdb文件
5、主Redis發送buffer緩存文件到從Redis
同步寫緩沖階段：Master向Slave同步存儲在緩沖區的寫操作命令。
6、從節點接收buffer緩存文件
從節點接收buffer緩存文件，并加載buffer緩存文件到內存中
7、主Redis通過Socker長連接連續把命令發送到從節點
從Redis接收到主Redis發送過來的命令，執行當前命令
總述
如果你為master配置了一個slave，不管這個slave是否是第一次連接上Master，它都會發送一個PSYNC命令給master請求復制數據。master收到PSYNC命令后，會在后臺進行數據持久化通過bgsave生成最新的rdb快照文件，持久化期間，master會繼續接收客戶端的請求，它會把這些可能修改數據集的請求緩存在內存中。當持久化進行完畢以后，master會把這份rdb文件數據集發送給slave，slave會把接收到的數據進行持久化生成rdb，然后再加載到內存中。然后，master再將之前緩存在內存中的命令發送給slave。當master與slave之間的連接由于某些原因而斷開時，slave能夠自動重連Master，如果master收到了多個slave并發連接請求，它只會進行一次持久化，而不是一個連接一次，然后再把這一份持久化的數據發送給多個并發連接的slave。
主從復制之部分復制
大體流程跟全量復制差不多，就不過多講解
簡述
當master和slave斷開重連后，一般都會對整份數據進行復制。但從redis2.8版本開始，redis改用可以支持部分數據復制的命令PSYNC去master同步數據，slave與master能夠在網絡連接斷開重連后只進行部分數據復制(斷點續傳)。master會在其內存中創建一個復制數據用的緩存隊列，緩存最近一段時間的數據，master和它所有的slave都維護了復制的數據下標offset和master的進程id，因此，當網絡連接斷開后，slave會請求master繼續進行未完成的復制，從所記錄的數據下標開始。如果master進程id變化了，或者從節點數據下標offset太舊，已經不在master的緩存隊列里了，那么將會進行一次全量數據的復制。主從復制(部分復制，斷點續傳)流程圖：
主從復制之增量同步
-
Redis增量同步主要指Slave完成初始化后開始正常工作時，Master發生的寫操作同步到Slave的過程。
-
通常情況下，Master每執行一個寫命令就會向Slave發送相同的寫命令，然后Slave接收并執行。
主從復制之心跳檢測
1.檢測主從的連接狀態
檢測主從服務器的網絡連接狀態通過向主服務器發送INFO replication命令，可以列出從服務器列表，可以看出從最后一次向主發送命令距離現在過了多少秒。lag的值應該在0或1之間跳動，如果超過1則說明主從之間的連接有故障。
2.輔助實現min-slaves
Redis可以通過配置防止主服務器在不安全的情況下執行寫命令min-slaves-to-write 3（min-replicas-to-write 3）min-slaves-max-lag 10（min-replicas-max-lag 10）上面的配置表示：從服務器的數量少于3個，或者三個從服務器的延遲（lag）值都大于或等于10秒時，主服務器將拒絕執行寫命令。這里的延遲值就是上面INFOreplication命令的lag值。
3.檢測命令丟失
如果因為網絡故障，主服務器傳播給從服務器的寫命令在半路丟失，那么當從服務器向主服務器發送REPLCONF ACK命令時，主服務器將發覺從服務器當前的復制偏移量少于自己的復制偏移量，然后主服務器就會根據從服務器提交的復制偏移量，在復制積壓緩沖區里面找到從服務器缺少的數據，并將這些數據重新發送給從服務器。（補發）網絡不斷增量同步：網斷了，再次連接時
如何判斷全量復制還是部分復制
客戶端發送saveof后主節點會判斷是否第一次復制，如果是則進行全量復制，如果不是通過runid offset偏移量進行判斷是否一致，如果一致則進行部分復制，否則進行全量復制。
更多編程相關知識，請訪問：Redis視頻教程！！
