共计 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 行业资讯频道！
