?

这俩个参数表示从节点的数量就剩余2个，或者从节点的延迟大于8秒时，主节点就会强制关闭maste功能，停止数据同步。

那么主节点是如何知道从节点挂掉的数量和延迟时间呢！ 在心跳机制里边slave 会每隔一秒发送perlconf ack 这个指令，这个指令可携带偏移量，也可以携带从节点的延迟时间和从节点的数量。

八、部分复制的三个核心要素

1. 服务器的运行id （run id）

我们先看一下这个run id是什么，执行info命令即可看到。在上文中我们查看启动日志信息也可以看到。

redis在启动时会自动生成一个随机的id（这里需要注意的是每次启动的id都会不一样），是由40个随机的十六进制字符串组成，用来唯一识别一个redis节点。

在主从复制初次启动时，master会把自己的runid发送给slave，slave会保存master的这个id，我们可以使用info命令查看

在这里插入图片描述

当断线重连时，slave把这个id发送给master，如果slave保存的runid与master现在的runid相同，master会尝试使用部分复制（这块能否复制成功还有一个因素就是偏移量）。如果slave保存的runid与master现在的runid不同，则会直接进行全量复制。

2. 复制积压缓冲区

复制缓冲积压区是一个先进先出的队列，用户存储master收集数据的命令记录。复制缓冲区的默认存储空间是1M。

可以在配置文件修改 repl-backlog-size 1mb 来控制缓冲区大小，这个比例可以根据自己的服务器内存来修改，咔咔这边是预留出了30%左右。

「复制缓冲区到底存储的是什么？」

当执行一个命令为 set name kaka 时，我们可以查看持久化文件查看 那么复制积压缓冲区就是存储的aof持久化的数据，并且以字节分开，并且每个字节都有自己的偏移量。这个偏移量也就是复制偏移量（offset） 「那为什么会说复制缓冲积压区有可能会导致全量复制呢」

在命令传播阶段，主节点会把收集的数据存储到复制缓冲区中，然后在发送给从节点。就是这里出现了问题，当主节点数据量在一瞬间特别大的时候，超出了复制缓冲区的内存，就会有一部分数据会被挤出去，从而导致主节点和从节点的数据不一致。从而进行全量复制。如果这个缓冲区大小设置不合理那么很大可能会造成死循环，从节点就会一直全量复制，清空数据，全量复制。

3. 复制偏移量（offset）

主节点复制偏移量是给从节点发送一次记录一次，从节点是接收一次记录一次。

用于同步信息，对比主节点和从节点的差异，当slave断联时恢复数据使用。

这个值也就是来自己于复制缓冲积压区里边的那个偏移量。

九. 主从复制常见的问题

1. 主节点重启问题（内部优化）

当主节点重启后，runid的值将发生变化，会导致所有的从节点进行全量复制。

这个问题我们无需考虑，知道系统是怎么优化的即可。

在建立完主从复制后主节点会创建master-replid变量，这个生成的策略跟runid一样，长度是41位，runid长度是40位，然后发送给从节点。

在主节点执行shutdown save命令时，进行了一次RDB持久化会把runid 和 offset保存到RDB文件中。可以使用命令redis-check-rdb查看该信息。

主节点重启后加载RDB文件，将文件中的repl-id 和repl-offset加载到内存中。纵使让所有从节点认为还是之前的主节点。

2. 从节点网络中断偏移量越界导致全量复制

由于网络环境不佳，从节点网络中断。复制积压缓冲区内存过小导致数据溢出，伴随着从节点偏移量越界，导致全量复制。有可能会导致反复的全量复制。

解决方案：修改复制积压缓冲区的大小：repl-backlog-size

设置建议：测试主节点连接从节点的时间，获取主节点每秒平均产生的命令总量write_size_per_second

复制缓冲区空间设置 = 2 * 主从连接时间 * 主节点每秒产生的数据总量

查看更多关于Redis主从复制原理以及常见问题的详细内容...

声明：本文来自网络，不代表【好得很程序员自学网】立场，转载请注明出处：http://www.haodehen.cn/did77497