本文主要是介绍Redis 主从复制该如何配置？从机配置与主从复制使用 redis 复制流程，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
参与复制的Redis实例划分为主节点（master） 和从节点（slave） 。 默认情况下， Redis都是主节点。 每个从节点只能有一个主节点， 而主节点可以同时具有多个从节点。 复制的数据流是单向的， 只能由主节点复制到从节点。
从节点配置
-
在配置文件中加入
slaveof{masterHost}{masterPort}随Redis启动生效。 -
在redis-server启动命令后加入
--slaveof{masterHost}{masterPort}生效。 -
直接使用命令：
slaveof{masterHost}{masterPort}生效
查看主从信息
127.0.0.1:6379> info replication # Replication role:slave #角色 master_host:172.18.0.2 master_port:6379 master_link_status:down master_last_io_seconds_ago:-1 master_sync_in_progress:0 slave_read_repl_offset:0 slave_repl_offset:0 master_link_down_since_seconds:-1 slave_priority:100 slave_read_only:1 replica_announced:1 connected_slaves:0 #从机个数 master_failover_state:no-failover master_replid:cfb75de90c1e774b9eda4fc0bb793d20dfc443b6 master_replid2:f637f1d252689c394c69e9003fcb1ac243100360 master_repl_offset:0 second_repl_offset:1 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0
断开主节点
slaveof no one
断开复制主要流程： 1） 断开与主节点复制关系。 2） 从节点晋升为主节点。 从节点断开复制后并不会抛弃原有数据， 只是无法再获取主节点上的数据变化。
切换主节点
slaveof {newMasterIp}{newMasterPort}
切主操作流程如下： 1） 断开与旧主节点复制关系。 2） 与新主节点建立复制关系。 3） 删除从节点当前所有数据。 4） 对新主节点进行复制操作。
切主后从节点会清空之前所有的数据
密码验证
对于数据比较重要的节点， 主节点会通过设置requirepass参数进行密码验证， 这时所有的客户端访问必须使用auth命令实行校验。 从节点与主节点的复制连接是通过一个特殊标识的客户端来完成， 因此需要配置从节点的masterauth参数与主节点密码保持一致， 这样从节点才可以正确地连接到主节点并发起复制流程。
只读
从节点使用slave-read-only=yes配置为只读模式 ，默认开启
拓扑
Redis的复制拓扑结构可以支持单层或多层复制关系， 根据拓扑复杂性可以分为以下三种： 一主一从、 一主多从、 树状主从结构
redis 集群的作用
-
提高系统的可用性和可靠性： 通过将数据复制到一个或多个从节点，即使主节点发生故障，也可以继续提供服务。当主节点不可用时，可以将一个从节点提升为新的主节点，从而避免服务中断，并快速恢复数据的可用性。
-
数据备份和灾难恢复： 从节点保存了主节点的完整数据集的副本，因此可以用作数据备份。在发生数据丢失或灾难情况时，可以使用从节点来恢复数据，减少数据丢失和业务中断的风险。
-
读写分离和负载均衡： 主节点负责处理写入操作，而从节点负责处理读取操作。通过将读取操作分发到多个从节点，可以分担主节点的读取负载，提高系统的整体性能和吞吐量。
-
提高数据可靠性和一致性： 通过复制数据到多个节点，可以提高数据的可靠性和一致性。即使在主节点发生故障或数据损坏时，仍然可以通过从节点提供可靠的数据访问。
-
扩展读取操作的性能： 通过添加多个从节点，可以实现读取操作的水平扩展，从而提高系统的读取性能和并发能力。从节点可以分担主节点的读取压力，并提供更快的响应时间。
一主一从
一主一从结构是最简单的复制拓扑结构， 用于主节点出现宕机时从节点提供故障转移支持
当应用写命令并发量较高且需要持久化时， 可以只在从节点上开启AOF， 这样既保证数据安全性同时也避免了持久化对主节点的性能干扰。
一主多从
一主多从结构（又称为星形拓扑结构） 使得应用端可以利用多个从节点实现读写分离
对于读占比较大的场景， 可以把读命令发送到从节点来分担主节点压力。
对于写并发量较高的场景， 多个从节点会导致主节点写命令的多次发送从而过度消耗网络带宽， 同时也加重了主节点的负载影响服务稳定性
树状主从
树状主从结构（又称为树状拓扑结构） 使得从节点不但可以复制主节点数据， 同时可以作为其他从节点的主节点继续向下层复制。
配置单机多集群案例
复制配置文件
root@da9676fe8449:/tool/redis# cp redis.conf redis80.conf root@da9676fe8449:/tool/redis# cp redis.conf redis81.conf
修改配置文件
修改 port pidfile logfile dumpfile
启动从机
redis-cli redis80.conf
redis-cli redis81.conf
redis-cli -p 6380
redis-cli -p 6381
复制流程
部分复制
部分复制主要是Redis针对全量复制的过高开销做出的一种优化措施，使用psync{runId}{offset}命令实现。
当从节点（slave） 正在复制主节点（master） 时， 如果出现网络闪断或者命令丢失等异常情况时， 从节点会向主节点要求补发丢失的命令数据
流程
-
当主从节点之间网络出现中断时， 如果超过repl-timeout时间， 主节点会认为从节点故障并中断复制连接
-
主从连接中断期间主节点依然响应命令， 但因复制连接中断命令无法发送给从节点， 不过主节点内部存在的复制积压缓冲区， 依然可以保存最近一段时间的写命令数据， 默认最大缓存1MB
-
当主从节点网络恢复后， 从节点会再次连上主节点，由于从节点之前保存了自身已复制的偏移量和主节点的运行ID。 因此会把它们当作psync参数发送给主节点， 要求进行部分复制操作。
-
主节点接到psync命令后首先核对参数runId是否与自身一致， 如果一致， 说明之前复制的是当前主节点； 之后根据参数offset在自身复制积压缓冲区查找， 如果偏移量之后的数据存在缓冲区中， 则对从节点发送+CONTINUE响应， 表示可以进行部分复制。
-
主节点根据偏移量把复制积压缓冲区里的数据发送给从节点， 保证主从复制进入正常状态。 发送的数据量可以在主节点的日志获取
主从心跳判断机制
-
主从节点彼此都有心跳检测机制， 各自模拟成对方的客户端进行通信， 通过client list命令查看复制相关客户端信息， 主节点的连接状态为flags=M， 从节点连接状态为flags=S。
-
主节点默认每隔10秒对从节点发送ping命令， 判断从节点的存活性和连接状态。 可通过参数
repl-ping-slave-period控制发送频率。 -
从节点在主线程中每隔1秒发送replconf ack{offset}命令， 给主节点上报自身当前的复制偏移量。
replconf命令主要作用如下：-
实时监测主从节点网络状态。
-
上报自身复制偏移量， 检查复制数据是否丢失， 如果从节点数据丢失， 再从主节点的复制缓冲区中拉取丢失数据。
-
实现保证从节点的数量和延迟性功能， 通过
min-slaves-to-write、minslaves-max-lag参数配置定义。
-
异步复制
主节点不但负责数据读写， 还负责把写命令同步给从节点。 写命令的发送过程是异步完成， 也就是说主节点自身处理完写命令后直接返回给客户端， 并不等待从节点复制完成 。
由于主从复制过程是异步的， 就会造成从节点的数据相对主节点存在延迟。 具体延迟多少字节， 我们可以在主节点执行info replication命令查看
-
应该把主节点尽量分散在多台机器上， 避免在单台机器上部署过多的主节点。
-
当主节点所在机器故障后提供故障转移机制， 避免机器恢复后进行密集的全量复制
参考资料：《Redis 开发与运维》
这篇关于Redis 主从复制该如何配置？从机配置与主从复制使用 redis 复制流程的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
