详细讲解Redis主从结构配置以及复制原理(二)

我在这篇博客详细讲解Redis主从结构配置以及复制原理(一)中讲了Redis2.6版本的主从结构和全量主从复制原理，接下来我会继续讲讲Redis2.8版本之后引入的增量主从复制原理。在Redis2.8版本之前的主从结构中，如果主从关系断开重连，从都要发送SYNC命令进行全量复制，当主内存数据量很大时，RDB机制要消耗大量i/o操作，主从之间传输RDB文件也要消耗网络带宽，为了解决这种低效的主从数据同步方式，在Redis2.8中引入了增量同步(Partial resynchronization)复制。

(一)增量复制机制依赖如下三个重要的元素。

(1) 主节点的复制缓冲区（replication backlog）

(2) 主从节点的复制偏移量(replication offset)

(3) 主从节点的runId

我们按照前一篇博客讲的方式部署主从节点，然后使用客户端登陆主从节点使用info命令查看节点信息：

我们可以看到主节点记录了从节点的偏移量信息。

我把配置文件redis.conf中关于主从复制的一些配置参数进行了翻译说明：

################################# REPLICATION #################################

# 将当前节点设置为运行在机器127.0.0.1上的6379端口实例的从节点
# slaveof <masterip> <masterport>
slaveof 127.0.0.1 6379

# 主节点设置验证密码，从节点在进行复制请求时，需要通过auth进行验证
# masterauth <master-password>
masterauth hello

# 从节点和主节点失去连接或者从节点正处于复制数据过程中，从节点响应客户端的方式
# “yes” 从节点使用旧数据响应客户端请求
# “no”  从节点给客户端反馈一个错误信息"SYNC with master in progress"
slave-serve-stale-data yes

# 从Redis 2.6开始 从节点默认只读模式。有时可以将从节点配置为可写模式，但是只能存储临时的数据，因为主从同步会很快删除这些临时数据。
# 同时注意从节点不能暴露给不安全的网络环境下
slave-read-only yes


# 从机器会每隔10秒钟 向主发送ping命令 以保住主节点活着
# repl-ping-slave-period 10

# 这是个响应超时的时间，需要从两个角度来看
# 从的角度来看，批量传输数据、从ping主等
# 主的角度来看，REPLCONF ACK pings等 
# 这个值一定要大于repl-ping-slave-period 这个值
# repl-timeout 60


# 若配置为yes，则禁用NO_DELAY，则TCP协议栈会合并小包统一发送，这样可以减少主从节点间的包数量并节省带宽，但会增加数据同步到slave的时间。
# 若配置为no，表明启用NO_DELAY，则TCP协议栈不会延迟小包的发送时机，这样数据同步的延时会减少，但需要更大的带宽。
# 通常情况下，应该配置为no以降低同步延时，但在主从节点间网络负载已经很高的情况下，可以配置为yes。
repl-disable-tcp-nodelay no


# 主节点的复制缓冲区大小，默认是1M,根据实际情况可以调大这个数值
# repl-backlog-size 1mb


# 当主失去所有从节点时，默认经过3600秒回释放复制缓冲区中的值
# 当设置为0时，意味着从不释放
# repl-backlog-ttl 3600


#Redis哨兵Sentinel会根据slave的优先级选举一个master。最低的优先级的slave，当选master。
#而配置成0，永远不会被选举。默认为100
slave-priority 100


#表示只有当3个（或以上）的从库连接到主库时，主库才是可写的，否则会返回错误
# min-slaves-to-write 3
#表示允许从库最长失去连接的时间，如果从库最后与主库联系（即发送“replconf  ack”命令）的时间小于这个值，则认为从库还在保持与主库的连接。
# min-slaves-max-lag 10

(二)增量复制的流程

主从增量复制可以分为两个阶段，一个阶段是主从的握手确认阶段，第二阶段是主执行rdb持久化机制，第三个阶段是rdb文件以及命令传播阶段

下面我们详细讲一下主从的增量复制是如何进行的

(1)  从节点向主节点发送ping命令，如果主节点状态正常会返回+PONG

(2)  从节点向主节点进行权限认证阶段，认证成功返回成功

(3)  从节点向主节点发送replconf listening-port 6380 

(4)  从节点向主节点发送psync 父节点runid offset

(5) 主节点验证runid是否是自己的runid，offset偏移量是否在自己的复制缓冲区中可以找到，如果都满足这个条件返回+CONTINUE表示可以进行增量复制，如果从之前没有进行过主从复制，主节点返回+FULLRESYNC 父节点runId offset进行全量复制，从节点保存父节点的runid并且增加自己的offset,如果返回-ERR表示出错或者不支持psync命令。

(三) 什么时候会发生增量复制

(1)  主从版本>=2.8

(2) 从节点发送psync  父节点runid  offset，主节点验证了runid正确，offset在复制缓冲区之内

(3) 从节点未重启情况下的tcp断线重连(如果从节点重启了，从保存的父节点runid就会丢失)

(四)使用telnet模拟增量复制

我们使用上一篇博客中的RedisTest 类向主节点写入数据

(1) 登录主节点使用info命令查看主节点的runid

(2) telnet 127.0.0.1 6379 连接redis主节点 执行如下图命令

(3) 我们查看主节点的日志log

可以看到从节点发起增量复制请求 并且发送从offset=20开始的数据

(4)我们使用info命令查看主节点的复制信息

红框里面这个从节点就是我们使用telnet模拟的客户端，注意看到lag=3，其实这个值只不断增加的，telnet 没有向主发送ping命令