共計 3717 個字符，預計需要花費 10 分鐘才能閱讀完成。
這篇文章主要為大家展示了“Redis 中的主從復制是什么”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓丸趣 TV 小編帶領大家一起研究并學習一下“Redis 中的主從復制是什么”這篇文章吧。
Redis 支持主從復制功能，可以通過執行 slaveof（Redis5 版本以后改成 replicaof）或者在配置文件中設置 slaveof（Redis5 版本以后改成 replicaof）來開啟復制功能。
一主兩叢
一主多從
主從基本配置主 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 yes4、啟動從節點
redis‐server redis.conf5、連接從節點
redis‐cli ‐p 63806、測試在 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 命令
1、發送“pong”, 說明正常
2、返回錯誤，說明 Master 不正常
3、timeout，說明網絡超時
1、檢測 socket 的讀寫狀態
2、檢測 Master 能否正常處理
Slaver 向 Master 發送 ping 命令
Master 的響應：
權限驗證
主從正常連接后，進行權限驗證
主未設置密碼（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 中的主從復制是什么”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注丸趣 TV 行業資訊頻道！
