Redis主从复制原理详解(3)

Redis主从复制原理详解

全量复制。主服务器会执行 bgsave 命令，然后 fork 出一个子进程来遍历自己的数据集并生成一个 RDB 文件，将这个文件发送给从服务器。

在这期间，为了保证 Redis 的高性能，主节点的主进程不会被阻塞，依旧对外提供服务并接收数据写入缓冲区中。

从服务器接收到 RDB 文件后，会清空自身数据，然后加载这个文件，将自己的数据集替换成主服务器的数据集。

3）命令同步

在第一次同步过程中，由于是全量同步，所以用时可能比较长，这期间主库依旧会写入新数据。

但是，在数据同步一开始就生成的 RDB 文件中显然是没有这部分新增数据的，所以第一次数据同步后需要再发送一次这部分新增数据。

这样，主服务器需要在发送完 RDB 文件后，将期间的写操作重新发送给从服务器，以保证从服务器的数据集与主服务器保持一致。

3.3 增量同步

1）命令传播

在完成全量复制后，主从服务器之间会保持一个 TCP 连接，主服务器会将自己的写操作发送给从服务器，从服务器执行这些写操作，从而保持数据一致性，这个过程也称为基于长连接的命令传播（command propagation）。

增量复制的数据是异步复制的，但通过记录写操作，主从服务器之间的数据最终会达到一致状态。

2）网络断开后数据同步

命令传播的过程中，由于网络抖动或故障导致连接断开，此时主节点上新的写命令将无法同步到从库。

即便是抖动瞬间又恢复网络连接，但 TCP 连接已经断开，所以数据需要重新同步。

从 Redis 2.8 开始，从库已支持增量同步，只会把断开的时候没有发生的写命令，同步给从库。

详细过程如下：

1. 网络恢复后，从库携带之前主库返回的 runid，还有复制的偏移量 offset 发送 psync runid offset 命令给主库，请求数据同步；
2. 主库收到命令后，核查 runid 和 offset，确认没问题将响应 continue 命令；
3. 主库发送网络断开期间的写命令，从库接收命令并执行。

这时，有细心的小伙伴可能要问了，网络断开后，主库怎么知道哪些数据是新写入的呢？

这是个好问题，接下来我们详细说明一下。

3）增量复制的关键

Master 在执行写操作时，会将这些命令记录在 repl_backlog_buffer （复制积压缓冲区）里面，并使用