心跳检测
概述
在命令传播阶段,从服务器默认会以每秒一次的频率,向主服务器发送命令:
REPLCONF ACK < replication_offset >
其中replication_offset是从服务器当前的复制偏移量。
发送REPLCONF ACK命令对于主从服务器有三个作用:
- 1.检测主从服务器的网络连接状态
- 2.辅助实现min-slaves选项
- 3.检测命令丢失
检测主从服务器的网络连接状态。
主从服务器可以通过发送和接收REPLCONF ACK命令来检查两者之间的
网络连接是否正常:如果主服务器超过一秒钟没有收到从服务器发来的REPLCONF ACK命令,那么主服务器旧知道主从服务器之间的连接出现问题了。通过向主服务器发送INFO replication命令,在列出的从服务器列表的lag一栏中可以看到相应从服务器最后一次向主服务器发送REPLCONFACK 命令距离现在过了多少秒:
127.0.0.1:6379> INFO replication
# Replication
role:master
connected_slaves:1
# 刚刚发送过REPLCONF ACK命令
slave0:ip=127.0.0.1,port=12345,state=online,offset=11596,lag=1
master_repl_offset:11596
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:8853
repl_backlog_histlen:2744
在一般情况下,lag的值应该在0秒或者1秒之间跳动,如果超过1秒,那么说明主从服务器之间的连接出现了故障。
辅助实现min-slaves配置选项
Redis的min-slaves-to-write和min-slaves-max-lag两个选项可以防止主服务器在不安全的情况下执行写命令。
例子
举个例子。我们向主服务器提供以下配置:
min-slaves-to-write 3
min-slaves-max-lag 10
那么在从服务器的数量少于3个,或者三个从服务器的延迟(lag)值
都大于或等于10秒时,主服务器将拒绝执行写命令,这里的延迟值就是
INFO replication命令的lag值
检测命令丢失。
如果因为网络故障,主服务器传播个i从服务器的写命令在半路丢失,那么当从服务器向主服务器发送REPLCONF ACK命令时,主服务器将发觉从服务器当前的复制偏移量少于自己的复制偏移量,然后主服务器
就会根据从服务器提交的复制偏移量,在复制积压缓冲区里面找到从服务器缺少的数据,并将这些数据重新送给从服务器。
例子
举个例子。假设有两个处于一致状态的主从服务器,它们的复制偏移量都是200,如图所示…如果这时主服务器执行了命令SET key value(协议格式的长度为33字节),将自己的复制偏移量更新到了233,并尝试向从服务器传播命令SET key value,但这条命令却因为网络故障而在传播的途中丢失,那么主从服务器之间的复制偏移量就会出现不一致,主服务器的偏移量会被更新为233,而从服务器的复制偏移量仍然为200,如图所示。
在这之后,当从服务器向主服务器发送REPLCONF ACK命令的时候,主服务器会察觉从服务器的复制偏移量依然为200,而自己的复制偏移量为233,这说明复制积压缓冲区里面复制偏移量为201至233的数据(也即是命令SET key value)在传播过程中丢失了,于是主服务器会再次向
从服务器传播命令SET key value,从服务器通过接收并执行这个命令,可以将自己更新至主服务器当前所处的状态,如图所示。
注意。
主服务器向从服务器补发缺失数据这一操作的原理和部分重同步操作的原理非常相似,这两个操作的区别在于,补发缺失数据操作在主从服务器没有断线的情况下进行,而部分重同步操作则在主从服务器断线并重连之后执行。
Redis2.8版本以前的命令丢失。
REPLCONF ACK命令和复制积压缓冲区都是Redis2.8版本新增的,在Redis2.8版本以前,即是命令在传播过程中丢失,主服务器和从服务器都不会注意到,主服务器更不会向从服务器补发丢失的数据,所以为了保证复制时主从服务器的数据一致性,最好使用Redis2.8版本以上的