redis 主从复制详解

引言

我们之前操作 Redis 都是单机版，但是实际应用中没人使用单机版，都是搭建集群的方式。这篇文章要介绍的主从复制，是指将一台 Redis 服务器的数据，复制到其他 Redis 服务器，我们将前者称为主节点 master，将后者称为从节点 slave（replica）。在这个过程中，数据的复制是单向的，即只能从主节点到从节点。并且从节点只能读数据，不能写数据，实现读写分离。

一个主节点可以有多个从节点，一个从节点只能有一个主节点。所有的服务器默认都是主节点。
从节点下面还可以有从节点，形成一个图的结构

主从复制的优点

数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
负载均衡：在主从复制的基础上，配合读写分离，写数据时应用连接主节点，读数据时应用连接从节点，分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高 Redis 服务器的并发量。
高可用基础：主从复制是哨兵模式和集群能够实施的基础。

开启主从复制

主从复制的前提就是多个 Redis 服务器，因此要多个配置文件。

开启主从复制的方式有两种：

配置配置文件

从服务器配置master节点

# 主节点ip port

# replicaof <masterip> <masterport>

# 主节点的认证密码(可选)

# masterauth <master-password>

显示命令开启

客户端使用该命令slaveof [ip] [port]

INFO REPLLICATION命令可查看节点信息

主从复制的具体实现

主从复制的实现可以分为三个阶段：建立连接、数据同步、命令传播

1. 建立连接

发送 slaveof 异步命令
建立 socket 连接

连接成功后从节点会为该 socket 建立一个专门处理复制工作的文件事件处理器，负责后续的复制工作，如接收 RDB 文件、接收命令传播等；
发送 ping 命令

从节点成为主节点的客户端之后，发送 ping 命令进行首次请求，目的是检查 socket 连接是否可用，以及主节点当前是否能够处理请求。
身份验证

取决于从节点是否设置 masterauth 选项，而这个又取决于主节点是否设置 requirepass
发送从节点端口信息

2. 数据同步

连接建立完成后，要进行主从数据库的数据同步，这一步也可以看作从节点中数据的初始化。数据同步有旧版和新版两种。我们先来看看旧版 Redis 怎么实现数据同步的

旧版同步

旧版同步使用的命令是 sync，同步方式是全量复制。以下是sync命令的执行步骤：

从服务器向主服务器发送 sync 命令
主服务器收到后执行 BGSAVE 的rgb持久化命令，生成一个RDB文件。并用一个缓冲区记录生成rgb文件期间执行的所有写命令。
主服务器将 rgb 文件发送给从服务器，从服务器载入整个 rgb 文件，同步数据库状态至执行 BGSAVE 时主服务的状态
主服务器将记录在缓冲区的写命令发送给从服务器。至此从服务和主服务数据库状态达到一致。

旧版同步功能的缺陷：

断线后重连需要再次发送 sync 同步命令，主服务再次生成 rgb 文件，从服务器载入恢复数据库状态。简单来说就是断线后又要全量复制，但其实没有必要，我们只需要同步断线后到重新连接期间主服务器变化的数据即可。

并且，sync是一个非常耗费资源的操作，因此旧版同步是非常低效的。

新版同步

新版同步使用的命令是 psync ，同步方式是增量复制

psync 有完成重同步和部分重同步两种模式。完整重同步其实就是sync，主要用于处理初次服务的情况。部分重同步主要用于处理断线后重连的情况。部分重同步不需要重新生成、传送和载入整个rdb文件，只需要将从服务器缺少的写命令发送给从服务器执行即可。完美的解决了旧版同步效率低下的问题。

下面我们就来看看他是如何实现的？首先要了解几个概念

主节点和从节点的复制偏移量

主节点和从节点会各自维护一个复制偏移量 ( offset )，代表的是主节点向从节点传递的字节数。主节点每次向从节点传播 N 个字节数据时，主节点的 offset 增加 N；同理，当从节点每次收到主节点传来的 N 个字节数据时，从节点的 offset 增加 N。通过比较主节点和从节点的 offset 可以判断数据库状态是否一致，如果两者的 offset 相同，则一致，否则不一致；也可以根据两者的 offset 找出从节点缺少的数据。
主节点的复制积压缓冲区
主节点维护的一个固定长度的先进先出 ( FIFO) 队列，默认大小是 1MB。当主节点开始有从节点时，主节点创建复制积压缓冲区，其作用是备份主节点最近发送给从节点的数据。保存的数据有两方面：
- 最近传播的写命令。为什么最近呢？因为队列长度固定，老的命令会被新的取代
- 队列中每个字节对应的复制偏移量
当从服务器重新连接上主机时，会通过 psync 命令把自己的offset发给主节点
- 如果offset之后的数据全部在队列中，执行部分重同步（增量复制）
- 如果offset之后的数据不全在队列中，执行完整重同步（全量复制）
服务器的运行ID

每个redis服务器都有自己的运行ID，在启动时自动生成，由40个随机的十六进制字符组成

当从节点对主节点进行初次复制时，主节点会把自己的运行ID发给从节点，从节点保存并在断线重连上主节点时把次ID发送给主节点：
- 如果此ID和主节点当前连接的ID一致，说明是同一个状态，可以进行增量复制
- 如果不同，只能进行全量复制

总结：psync的执行流程：

命令传播

数据同步阶段完成后，主从节点进入命令传播阶段；在这个阶段主节点将自己执行的写命令发送给从节点，从节点接收命令并执行，从而保证主从节点数据的一致性。

这个阶段没啥可说的，就是把主节点执行的写命令发给从节点，让它们也执行一次，保证主从一致性

心跳检测

在命令传播阶段，从服务器默认会以每秒一次的频率向主服务器发送replconf ACK <replication_offset>,其中replication_offset是它当前的复制偏移量。心跳检测的目的有以下三个：

检测主从服务器的网络连接状态

如果主服务器超过一秒没有收到从服务的该命令，那么主服务器就知道主从连接出现问题了
辅助实现min-slaves

主服务我们可以配置以下两个参数来防止不安全写命令传播，如果从节点小于3或者lag大于10，主服务器都会拒绝执行写命令
```
# 从节点的最小个数

# min-replicas-to-write 3

# 从节点lag的最大值

# min-replicas-max-lag 10
```
检测命令丢失

上面说过心跳检测命令还发送了从节点自身保存的offset。主节点会与自己的 offset 进行对比，如果从节点数据缺失（如网络丢包），主节点会找到缺失的数据，并把这些数据重新推送给服务器（这里也会利用复制积压缓冲区）。

参考