目录
一、主从复制中相关概念介绍
1.1、服务器运行ID(runid)
1.1.1、概念
服务器运行ID是每一台服务器每次运行的身份识别码，一台服务器多次运行每次都会生成一个新的运行ID.
1.1.2、组成
运行ID由40位字符组成，是一个随机的十六进制字符串。
例如：d3b533982f93bd8de30f58bf9a66093fe158d32c
1.1.3、作用
运行ID被用于在服务间进行传输，识别身份。
如果想两次操作均对同一台服务器进行，那么每次操作必须携带对应的运行ID，用于对方识别。
1.1.4、实现方式
运行ID在每台服务器启动时自动生成，主机(master)在首次连接(slave)时，会将自己的运行ID发送给从机(slave)，从机(slave)保存此ID，通过info Server命令，可以查看节点的runid。
1.2、复制缓冲区
1.2.1、概念
复制缓冲区，又名复制积压缓冲区，是一个先进先出(FIFO)的队列，用于存储服务器执行过的命令，每次传播命令，主机(mater)都会将传播的命令记录下来，并存储在复制缓冲区。
复制缓冲区默认数据存储空间大小是1M，由于存储空间大小是固定的，当入队元素的数量大于队列长度时，最先入队的元素会被弹出，而新元素会被放入队列。
1.2.2、由来
每台服务器启动时，如果开启有AOF或被连接成为主机(master)节点，即创建复制缓冲区。
1.2.3、作用
用于保存主机(master)收到的所有指令(仅影响数据变更的指令，例如set、select)。
1.2.4、数据来源
当主机(master)接收到主客户端的指令时，除了将指令执行，也会将该指令存储到缓冲区中。
1.3、主从服务器复制偏移量(offset)
1.3.1、概念
描述复制缓冲区中的指令字节位置的一个数字。
1.3.2、分类
· 主机(master)复制偏移量：记录发送给所有从机(slave)的指令字节对应的位置(多个)；
· 从机(slave)复制偏移量：记录从机(slave)接收主机(master)发送过来的指令字节对应的位置(一个)。
1.3.3、数据来源
· 主机(master)端：发送一次记录一次；
· 从机(slave)端：接收一次记录一次。
1.3.4、作用
同步信息，对比主机(master)和从机(slave)的差异，当从机(slave)断线后，恢复数据使用。
1.4、心跳机制
1.4.1、概念
主从复制进入命令传播阶段时，主机(master)与从机(slave)之间需要进行信息交换，使用心跳机制进行维护，实现双方连接保持在线。
1.4.2、工作机制
master心跳：
· 指令：ping
· 周期：由repl-ping-slave-period决定，默认10秒
· 作用：判断从机(slave)是否在线
· 查询：info Replication # 获取从机最后一次连接时间，lag项维持在0或1视为正常
slave心跳：
· 指令：REPLCONF ACK {offset}
· 周期：1秒
· 作用1：汇报从机(slave)自己的复制偏移量，获取最新的数据变更指令
· 作用2：判断主机(master)是否在线
1.4.3、心跳阶段注意事项
a、当从机(slave)多数掉线，或者延迟过高时，主机(master)为保障数据稳定性，将拒绝所有信息同步操作；
# 从机(slave)数量少于2个，或者所有从机(slave)的延迟都大于等于10秒时，强制关闭主机(master)写功能，停止数据同步
min-slaves-to-write 2
min-slaves-max-lag 10b、从机(slave)数量由从机(slave)发送REPLCONF ACK命令做确认；
c、从机(slave)延迟也是由从机(slave)发送REPLCONF ACK命令做确认；
二、主从复制常见问题
2.1、频繁的全量复制
2.1.1、频繁全量复制(问题一)
问题现象：
伴随着系统的运行，主机(master)的数据量会越来越大，一旦主机(master)重启，服务器运行ID(runid)将会发生变化，会导致全部的从机(slave)都进行全量复制。
解决方案(内部优化调整)：
a、主机(master)内部创建master-replid变量，使用与runid相同的策略生成，长度为40位，并发送给所有从机(slave)；
b、当主机(master)关闭时执行命令shutdown save，进行RDB持久化，将runid与offset保存到RDB文件中；
注：repl-id、repl-offset可以通过redis-check-rdb命令查看。
c、主机(master)重启后加载RDB文件，恢复数据，重启后，将RDB文件中保存的repl-id与repl-offset加载到内存中。
注：master_repl_id = repl-id、master_repl_offset = repl-offset，可以通过info命令查看该信息。
作用：
本及保存上次服务器运行ID(runid)，重启后恢复该值，使所有从机(slave)认为还是之前的主机(master)，继续从记录的复制偏移量(offset)复制数据，避免全量复制。
2.1.2、频繁全量复制(问题二)
问题现象：
网络环境不佳，出现网络中断，从机(slave)不提供服务。
问题原因：
复制缓冲区过小，断网后从机(slave)的复制偏移量(offset)越界，触发全量复制。
最终结果：
从机(slave)反复进行全量复制。
解决方案：
修改复制缓冲区大小。
repl-backlog-size建议设置如下：
1、测算从主机(master)到从机(slave)的重连平均时长second；
2、获取主机(master)平均每秒产生写命令数据总量write_size_per_second；
3、最优复制缓冲区空间 = 2 * second * write_size_per_second。
2.2、频繁的网络中断
2.2.1、频繁网络中断(问题一)
问题现象：
主机(master)的CPU占用过高或从机(slave)频繁断开连接。
问题原因：
· 从机(slave)每1秒发送REPLCONF ACK命令到master；
· 当从机(slave)执行慢查询时(keys *，hgetall等)，会大量占用CPU性能；
· 主机(master)每1秒调用复制定时函数replicationCron()，比对从机(slave)发现长时间没有进行响应。
最终结果：
主机的各种资源(输出缓冲区、带宽、连接等)被严重占用。
解决方案：
通过设置合理的超时时间，确认是否释放从机(slave)。
repl-timeout注：该参数定义了超时时间的阈值(默认60秒)，一旦超过该值，即释放从机(slave)。
2.2.2、频繁网络中断(问题二)
问题现象：
从机(slave)与主机(master)断开连接。
问题原因：
· 主机(master)发送ping指令频度较低；
· 主机(master)设定的超时时间较短；
· ping指令在网络中存在丢包的情况。
解决方案：
提高ping指令的发送频度。
repl-ping-slave-period注：超时时间repl-time的时间至少值ping指令频度的5至10倍，否之从机(slave)很容易被判定超时，从而导致被释放。
2.3、数据不一致
2.3.1、数据不一致(问题一)
问题现象：
多个从机(slave)获取相同数据不同步。
问题原因：
网络信息不同步，数据发送有延迟。
解决方案:
· 优化主从间的网络环境，通常放置在同一个机房部署(同一个局域网内)，如使用阿里云等云服务器时要注意此现象；
· 监控主从节点延迟(通过offset)判断，如果从机(slave)延迟过大，暂时屏蔽程序对该从机(slave)的数据访问。
slave-serve-stale-data yes|no注：开启后仅响应info、slaveof等少数命令(慎用，除非对数据一致性要求很高)。
