redis 优化系列（二）Redis 主从原理、主从常用配置

一、主从复制原理

主从复制过程大体可以分为 3 个阶段：连接建立阶段（即准备阶段）、数据同步阶段、命令传播阶段。

在从节点执行 slaveof 命令后，复制过程便开始运作，下面图示大概可以看到，从图中可以看出复制过程大致分为 6 个过程

主从配置之后的日志记录也可以看出这个流程（看主 redis 或从 redis 日志都可以）：

vi` `/var/log/redis/redis``.log

1）保存主节点（master）信息：

执行 slaveof 后 Redis 会打印如下日志：

2）从节点（slave）底层内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接

从节点与主节点建立网络连接示例图：

从节点会建立一个 socket 套接字，从节点建立了一个端口为 51234 的套接字，专门用于接受主节点发送的复制命令。从节点连接成功后打印如下日志：

如果从节点无法建立连接，定时任务会无限重试直到连接成功或者手动执行 slaveof no one 取消复制（断开主从）

注：对一个从 redis 节点服务器执行命令 slaveof no one 将使得这个从 redis 节点服务器关闭复制功能，并从 从 redis 节点服务器转变回主 redis 节点服务器，原来同步所得的数据集不会被丢弃。

关于连接失败，可以在从节点执行 info replication 查看 master_link_down_since_seconds 指标，它会记录与主节点连接失败的系统时间。从节点连接主节点失败时也会每秒打印如下日志，方便发现问题：

# Error condition on socket for SYNC: {socket_error_reason}

3）发送 ping 命令

连接建立成功后从节点发送 ping 请求进行首次通信，ping 请求主要目的如下：****

①、检测主从之间网络套接字是否可用。

②、检测主节点当前是否可接受处理命令。

③、如果发送 ping 命令后，从节点没有收到主节点的 pong 回复或者超时，比如网络超时或者主节点正在阻塞无法响应命令，从节点会断开复制连接，下次定时任务会发起重连。

从节点发送的 ping 命令成功返回，Redis 打印如下日志，并继续后续复制流程：

**4）权限验证。**如果主节点设置了 requirepass 参数，则需要密码验证，从节点必须配置 masterauth 参数保证与主节点相同的密码才能通过验证；如果验证失败复制将终止，从节点重新发起复制流程。

**5）同步数据集。**主从复制连接正常通信后，对于首次建立复制的场景，主节点会把持有的数据全部发送给从节点，这部分操作是耗时最长的步骤。

****

**6）命令持续复制。**当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来主节点会持续地把写命令发送给从节点，保证主从数据一致性。

二、全量复制和部分复制

2.1 相关概念

全量复制：用于初次复制或其它无法进行部分复制的情况，将主节点中的所有数据都发送给从节点，是一个非常重型的操作，当数据量较大时，会对主从节点和网络造成很大的开销

部分复制：用于处理在主从复制中因网络闪断等原因造成的数据丢失场景，当从节点再次连上主节点后，（如果条件允许，后面会说到具体那些条件需要被满足），主节点会补发丢失数据给从节点。因为补发的数据远远小于全量数据，可以有效避免全量复制的过高开销，需要注意的是，如果网络中断时间过长，造成主节点没有能够完整地保存中断期间执行的写命令，则无法进行部分复制，仍使用全量复制

复制偏移量：参与复制的主从节点都会维护自身复制偏移量。主节点（master）在处理完写入命令后，会把命令的字节长度做累加记录，统计信息在 info replication 中的 master_repl_offset 指标中：

提醒：记得进入 redis 客户端执行该命令

#在从节点的redis中执行以下命令``redis-cli``info replication

截图如下：

从节点（slave）每秒钟上报自身的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量，统计指标如下：

再次提醒：记得进入 redis 客户端执行 info replication 命令

#在主节点的redis中执行以下命令``redis-cli``info replication

截图如下：

从节点在接收到主节点发送的命令后，也会累加记录自身的偏移量。统计信息在 info replication 中的 slave_repl_offset 中

复制积压缓冲区：复制积压缓冲区是保存在主节点上的一个固定长度的队列，默认大小为 1MB（可以调整大小，具体调整多大看各自需求业务来调整），当主节点有连接的从节点（slave）时被创建，这时主节点（master）响应写命令时，不但会把命令发送给从节点，还会写入复制积压缓冲区。

在命令传播阶段（也可以说是 同步数据阶段），主节点除了将写命令发送给从节点，还会发送一份给复制积压缓冲区，作为写命令的备份；除了存储写命令，复制积压缓冲区中还存储了其中的每个字节对应的复制偏移量(offset) 。由于复制积压缓冲区定长而且先进先出，所以它保存的是主节点最近执行的写命令；时间较早的写命令会被挤出缓冲区。

2.2 Redis 全量复制的过程如下图所示：

如上图所示：

1、Redis 内部会发出一个同步命令，刚开始是 Psync 命令，Psync ? -1 表示要求 master 主机同步数据

2、主机会向从机发送 runid 和 offset，因为 slave 并没有对应的 offset，所以是全量复制

3、从机 slave 会保存 主机 master 的基本信息 save masterInfo

4、主节点收到全量复制的命令后，执行 bgsave 命令（异步执行），在后台生成 RDB 文件（快照文件），并使用一个缓冲区（称为复制缓冲区）记录从现在开始执行的所有写命令

5、主机发送 RDB 文件给从机

6、主机发送缓冲区数据到从机

7、刷新旧的数据，从节点在载入主节点的数据之前要先将老数据清除

8、加载 RDB 文件将数据库状态更新至主节点执行 bgsave 时的数据库状态和缓冲区数据的加载。

全量复制开销，主要有以下几项：

1、bgsave 时间

2、RDB 文件网络传输时间

3、从节点清空数据的时间

4、从节点加载 RDB 的时间

注：生成一个几 GB 十几 GB 的 RDB 快照文件 大概是需要 2-5 分钟的样子

2.3 部分复制（又称 增量复制）

部分复制是 Redis 2.8 以后出现的，之所以要加入部分复制，是因为全量复制会产生很多问题，比如像上面的时间开销大、无法隔离等问题， Redis 希望能够在 master 出现抖动（相当于断开连接）的时候，可以有一些机制将复制的损失降低到最低。

部分复制的过程如下图所示：

如上图所示：

1、如果网络抖动（连接断开 connection lost）

2、主机 master 还是会写 replbackbuffer（复制缓冲区）

3、从机 slave 会继续尝试连接主机

4、从机 slave 会把自己当前 runid 和偏移量传输给主机 master，并且执行 pysnc 命令同步

5、如果 master 发现从节点的偏移量是在缓冲区的范围内，就会返回 continue（在指的是继续复制的意思） 命令，如果从节点的偏移量不在缓冲区的范围之内，就不会进行部分复制操作了，这样就意味着它会执行全量复制，所以我们要尽量避免这种情况的发生。

6、同步了 offset 的部分数据，所以部分复制的基础就是偏移量 offset

正常情况下 redis 是如何决定是全量复制还是部分复制？

从节点将 offset（偏移量）发送给主节点后，主节点根据 offset（偏移量）和缓冲区大小决定能否执行部分复制；

如果 offset 偏移量之后的数据，仍然都在复制积压缓冲区里，则执行部分复制；

如果 offset 偏移量之后的数据已不在复制积压缓冲区中（数据已被挤出），则执行全量复制；

缓冲区大小调节：

由于缓冲区长度固定且有限，因此可以备份的写命令也有限，当主从节点 offset 的差距过大超过缓冲区长度时，将无法执行部分复制，只能执行全量复制。反过来说，为了提高网络中断时部分复制执行的概率，可以根据需要增大复制积压缓冲区的大小(通过配置 repl-backlog-size)来设置；例如如果网络中断的平均时间是 60s，而主节点平均每秒产生的写命令(特定协议格式)所占的字节数为 100KB，则复制积压缓冲区的平均需求为 6MB，保险起见，可以设置为 12MB，来保证绝大多数断线情况都可以使用部分复制。

服务器运行 ID(runid)：

每个 Redis 节点(无论主从)，在启动时都会自动生成一个随机 ID(每次启动都不一样)，由 40 个随机的十六进制字符组成；runid 用来唯一识别一个 Redis 节点。 通过 info server 命令，可以查看节点的 runid：****

主从节点初次复制时，主节点将自己的 runid 发送给从节点，从节点将这个 runid 保存起来；当断线重连时，从节点会将这个 runid 发送给主节点；主节点根据 runid 判断能否进行部分复制：

如果从节点保存的 runid 与主节点现在的 runid 相同，说明主从节点之前同步过，主节点会继续尝试使用部分复制（到底能不能部分复制还要看 offset 和复制积压缓冲区的情况）

如果从节点保存的 runid 与主节点现在的 runid 不同，说明从节点在断线前同步的 Redis 节点并不是当前的主节点，只能进行全量复制。

三、主从复制的常用相关配置

1、从 redis 节点配置：

①、slaveof <masterip> <masterport>

slave 实例需要配置该项，指向 master 的（ip, port）

②、masterauth <master-password>

如果 master 实例启用了密码保护，则该配置项需填 master 的启动密码，若 master 未启用密码，该配置项需要注释掉

③、slave-serve-stale-data

指定 slave 与 master 连接中断时的动作。默认为 yes，表明 slave 会继续应答来自 client 的请求，但这些数据可能已经过期（因为连接中断导致无法从 master 同步）。若配置为 no，则 slave 除正常应答"INFO"和"SLAVEOF"命令外，其余来自客户端的请求命令均会得到"SYNC with master in progress"的应答，直到该 slave 与 master 的连接重建成功或该 slave 被提升为 master

④、slave-read-only

指定 slave 是否只读，默认为 yes。若配置为 no，这表示 slave 是可写的，但写的内容在主从同步完成后会被删掉

⑤、repl-disable-tcp-nodelay

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

注：主从节点进行数据传输是基于 tcp 协议进行传输的

⑥、slave-priority

指定 slave 的优先级。在不只 1 个 slave 存在的部署环境下，当 master 宕机时，Redis Sentinel 会将 priority 值最小的 slave 提升为 master。需要注意的是，若该配置项为 0，则对应的 slave 永远不会被 Redis Sentinel 自动提升为 master