1. 主从复制工作流程

1.1 主从复制的工作流程(三个阶段)

1.1.1 建立连接阶段（即准备阶段）

建立slave到master的连接，使master能够识别slave,并保存slave端口号

建立连接阶段工作流程：

步骤1:设置master的地址和端口，保存master信息（1,2,3响应完才会进行保存）
步骤2:建立socket连接（4，socket：信息通道，传递信息用）
步骤3:发送ping命令(5,6，定时器任务，确认网络是否通畅)
步骤4:身份验证（7,8，如果master设置的有密码的话，这个过程不是必须的）
步骤5:发送slave端口信息（9,10）
到此，主从连接成功!
当前状态:

1. slave: 保存master的地址与端口
2. master: 保存slave的端口
3. 总体:之间创建了连接的socket

图例：

1.1.1.1 主从连接(slave连接master)

方式一:客户端发送命令
slaveof masterip masterport

slaveof 192.168.40.130 6381

方式二:启动服务器参数
redis-server -slaveof masterip masterport

redis-server /redis/conf/redis-6383.conf --slaveof 192.168.40.130 6391

方式三: 服务器配置
slaveof masterip masterport
在配置文件里面加入这句话就可以了，这里面是主的ip地址和其端口号

slave系统信息

1. master_ link_ down since_ seconds
2. masterhost & masterport
3. 在slave的控制端口里面输入info，回车就会出现上面的这些信息
   

master系统信息

1. slave_ listening_ port (多个)
2. 在master的控制端口里面输入info，回车就会出现上面的这些信息
   

1.1.1.2 断开连接

断开slave与master的连接, slave断开连接后，不会删除3有数据，只是不再接受master发送的数据，这一段话是在slave里面输入
slaveof no one

1.1.1.3 授权访问

1.1.2 数据同步阶段

在slave初次连接master后，复制master中的所有数据到slave

将slave的数据库状态更新成master当前的数据库状态

工作流程：

步骤1:请求同步数据（1）：

1. 首先发起一个指令psync2（升级后的版本）

步骤2:创建RDB同步数据（2,3,4，）

1. marster收到指令过后，执行rdb过程，后台执行bgsave（将数据储存打包）
2. 当第一个slave连接进行的时候，将会创建一个复制缓冲区
3. 通过上面步骤生成的rdb文件，通过socket发送到slave

步骤3:恢复RDB同步数据（5,）

1. 首先将数据进行清空，将接收到的rdb文件执行恢复过程

步骤4:请求部分同步数据（6,）

1. 发送指令告诉master，恢复过程已经做完了
2. 从第一步到第三步，这些过程称为全量复制（复制rdb文件里面的所有信息）
3. 在全量复制的阶段会有新的指令进入到复制缓冲区里面

步骤5:恢复部分同步数据:（7,8）

1. 在步骤四过后，slave告诉masterrdb文件里面的内容已经复制完了，现在需要复制缓冲区里面的数据
2. master将复制缓冲区里面的数据发送给slave
3. slave接收到master发送的指令后，执行bgrewriteaof（里面的所有数据都是以aof的形式储存发送的），恢复数据
4. 接下来再发送指令，向master要复制缓冲区后面的数据
5. master响应指令
6. 将第四步到第五步的过程就是部分复制

到此，数据同步工作完成!

当前状态:

1. slave:具有master端全部数据，包含RDB过程接
   收的数据
2. master:保存slave当前数据同步的位置
3. 总体:之间完成了数据克隆

实例图：

1.1.2.1 数据同步阶段master说明

1.如果master数据量巨大，数据同步阶段应避开流量高峰期，避免造成naster阻塞, 影响业务正常执行（晚上的时候最好）

2.复制缓冲区大小设定不合理，会导致数据溢出（将前面的数据冲掉）。如进行全量复制周期太长，进行部分复制时发现数据已经存在丢失的情况，必须进行第二次全量复制， 致使slave陷入死循环状态。

将这句话放到master的配置文件中，设置其复制缓冲区的大小
repl-backlog-size ?mb

3.master单机内存占用主机内存的比例不应过大，建议使用50% ~ 70%的内存,留下30% ~ 50%的内存用于执行bgsave命令和创建复制缓冲区

1.1.2.2 数据同步阶段slave说明

1.为避免slave进行全量复制、部分复制时服务器响应阻塞或数据不同步，建议关闭此期间的对外服务

在slave里面添加以下的配置
slave-serve-stale-data yes |no

2.数据同步阶段，master发送给slave信息可以理解naster是slave的一个客户端，主动向slave发送命令

3.多个slave同时对master请求数据同步, master发送的RDB文件增多,会对带宽造成巨大冲击,如果master带宽不足，因此数据同步需要根据业务需求，适量错峰

4.slave过多时，建议调整拓扑结构,由-主多从结构变为树状结构，中间的节点既是master,也是slave。注意使用树状结构时，由于层级深度,导致深度越高的slave与最顶层master间数据同步延迟较大，数据致性变差,应谨慎选择（了解）

1.1.3 命令传播阶段

1.当master数据库状态被修改后，导致主从服务器数据库状态不一致,此时需要让主从数据同步到一致的状态， 同步的动作称为命令传播

2.master将接收到的数据变更命令发送给slave, slave接收命令后执行命令

1.1.3.1 命令传播阶段的部分复制

命令传播阶段出现了断网现象

1. 网络闪断闪连 ------ 忽略

2. 短时间网络中断 ------ 部分复制

3. 长时间网络中断 ------ 全量复制

1.1.4 部分复制的三个核心要素

1.1.4.1 服务器的运行id (run id)

概念:服务器运行ID是每一台服务 器每次运行的身份识别码，- -台服务器多次运行可以生成多个运行id

组成:运行id由40位字符组成,是一个随机的十六进制字符

例如: fdc9ff13b9bbaab28db42b3d50f8 52bb5e3fcdce

作用:运行id被用于在服务器间进行传输，识别身份

如果想两次操作均对同一台服务器进行,必须每次操作携带对应的运行id,用于对方识别

实现方式:运行id在每台服务器启动时自动生成的，master在首次连接slave时，会将自己的运行ID发送给slave,slave保存此ID，通过info server命令， 可以查看节点的runid

1.1.4.2 主服务器的复制积压缓冲区（复制缓冲区）

概念:复制缓冲区,又名复制积压缓冲区，是一个先进先出 (FIFO) 的队列，用于存储服务器执行过的命令,每次传播命令, master都会将传播的命令记录下来,并存储在复制缓冲区

master在发送指令的时候，是通过命令传播程序将指令发送给slave，在发送的时候会将指令再放到复制缓冲区（队列：先进先出）里面，如果断网的话，也是会在后面依次执行指令

复制缓冲区内部工作原理：
组成

1. 偏移量
2. 字节值

工作原理：

1. 通过offset区分不同的slave当前数据传播的差异
2. master记录已发送的信息对应的offset
3. slave记录已接收的信息对应的offset

组成：当master接收到命令（set name yy）后，会将命令存储起来（存储在复制缓冲区里面），存储的的时候不是将命令直接存储进去，它是将命令转换为aof的格式，在复制缓冲区里面将转换后的结果按字符的方式一个一个的放进去（这一块区域叫做字节值），在上面还要加一个编号（偏移量）
发送的时候除了发送数据，还是把对应的偏移量也进行了发送，master和slave都要记录，

复制缓冲区特点：

1. 复制缓冲区默认数据存储空间大小是1M
2. 当入队元素的数量大于队列长度时，最先入队的元素会被弹出，而新元素会被放入队列

作用:用于保存master收到的所有指令(仅影响数据变更的指令,例如set, select)

比如get就不用存进去，不通过数据查服务，只是提供写服务

数据来源:当master接收到主客户端的指令时，除了将指令执行，会将该指令存储到缓冲区中

1.1.4.3 主从服务器的复制偏移量

概念: 一个数字,描述复制缓冲区中的指令字节位置

分类:

1. master复制偏移量:记录发送给所有slave的指令字节对应的位置(多个)
2. slave复制偏移量:记录slave接收master发送过来的指令字节对应的位置(- 个)

作用:同步信息，比对naster与slave的差异，当slave断线后， 恢复数据使用

数据来源:

1. master端:发送一次记录一次
2. slave端:接收一次记录一次

1.2 数据同步+命令传播阶段工作流程

在进行全量复制的时候，会继续并且不停的接收客户端的命令 ，去判断offset是否方式了变化

1.2.1 主从复制工作流程（完整）

主从复制分为下面的三个阶段，如下图所示：

1. 数据同步阶段会发生全量复制和部分复制
2. 命令传播阶段：slave会不停的通过心跳的机制发自己的偏移量过去，master接收后会判断offset（偏移量）在不在复制缓冲区中

   如果不在缓冲区的话，执行全量复制，
   如果在复制缓冲区里面，且一样的话，什么都不用做，
   如果在复制缓冲区里面，并且不一样的时候，拿取这个数据，执行下一步，最后又执行部分复制

不仅slave会去探测master，master也会去探测slave（通过ping）

1.3 心跳机制

进入命令传播阶段候，master与slave间需要进行信息交换，使用心跳机制进行维护，实现双方连接保持在线

master心跳:

1. 内部指令:PING

2. 周期:由repl-ping-slave-period决定，默认10秒

3. 作用:判断slave是否在线

4. 查询命令：INFO replication

   获取slave最后一次连接时间间隔，lag项维持在0或1视为正常

slave心跳任务：

1. 内部指令: REPLCONF ACK {offset)

2. 周期:1秒

3. 作用1:汇报slave自己的复制偏移量，获取最新的数据变更指令
   作用2:判断master是否在线

1.3.1 心跳阶段注意事项

当slave多数掉线，或延迟过高时，master为保障数据稳定性，将拒绝所有信息同步操作

min-slaves-to-write 2
min-slaves-max-lag 8

slave数量少于2个，或者所有slave的延迟都大于等于8秒时，强制关闭master写功能，停止数据同步

slave数量由slave发送REPLCONF ACK命令做确认

slave延迟由slave发送REPLCONF ACK命令做确认

2. 主从复制常见问题

2.1 频繁的全量复制

2.1.1 （1）

伴随着系统的运行，master的数据星会越来越大，一旦master重启，runid将发生变化，会导致全部slave的全量复制操作内部优化调整方案:

1. master内部创建master_replid变量，使用runid相同的策略生成，长度41位，并发送给所有slave

2. 在master关闭时执行命令shutdown save，进行RDB持久化,将runid与offset保存到RDB文件中

   repl-idrepl-offset
   通过redis-check-rdb命令可以查看该信息

3. master重启后加载RDB文件，恢复数据

重启后，将RDB文件中保存的repl-id与repl-offset加载到内存中

1. master_repl_id = replmaster_repl_offset = repl-offset
2. 通过info命令可以查看该信息

作用:本机保存上次runid重启后恢复该值，使所有slave认为还是之前的master

2.1.2 （2）

问题现象:网络环境不佳，出现网络中断，slave不提供服务

问题原因:复制缓冲区过小，断网后slave的offset越界，触发全量复制

最终结果: slave反复进行全量复制

解决方案:修改复制缓冲区大小

repl-backlog-size ?mb

建议设置如下:

1. 测算从master到slave的重连平均时长second
2. 获取master平均每松产生写命令数据总量write_size _per_second
3. 最优复制缓冲区空间= 2 * second * write size per second

2.2 频繁的网络中断

2.2.1 （1）

问题现象: master的CPU占用过高或slave频繁断开连接

问题原因

1. slave每1秒发送REPLCONF ACK命令到master

2. 当slave接到了慢查询时(keys * , hgetall等)，会大量占用cPu性能

3. master每1秒调用复制定时函数replicationcron()，比对slave发现长时间没有进行响应

最终结果: master各种资源(输出缓冲区、带宽、连接等）被严重占用

解决方案:通过设置合理的超时时间，确认是否释放slave

repl-timeout seconds
该参数定义了超时时间的阈值（默认6o秒)，超过该值，释放slave

2.2.2 （2）

问题现象: slave与master连接断开
公
问题原因
master发送ping指令频度较低master设定超时时间较短
ping指令在网络中存在丢包解决方案:提高ping指令发送的频度
repl-ping-slave-period seconds
超时时间repl-time的时间至少是ping指令频度的5到1o倍，否则slave很容易判定超时

2.3 数据不一致

问题现象:多个slave获取相同数据不同步

问题原因:网络信息不同步，数据发送有延迟

解决方案

1. 优化主从间的网络环境，通常放置在同一个机房部署，如使用阿里云等云服务器时要注意此现象

2. 监控主从节点延迟(通过offset)判断，如果slave延迟过大，暂时屏蔽程序对该slave的数据访问

   slave-serve-stale-data yes | no
   开启后仅响应info、slaveof等少数命令（慎用，除非对数据一致性要求很高)