Replication

概述

Redis 支持简单且易用的主从复制（master-slave replication）功能，该功能可以让从服务器(slave server)成为主服务器(master server)的精确复制品。

旧版复制功能的实现(2.8版本之前)

Redis的复制功能分为同步(sync)和命令传播（command propagate）两个操作。

同步

从服务器对主服务器的同步操作需要通过向主服务器发送SYC命令来完成:

从服务器向主服务器发送SYNC命令。
收到SYMC命令的主服务器执行BGSAVE命令,在后台生成一个RDB文件,并使用一个缓冲区记录从现在开始执行的所有写命令。
BGSAVE命令执行完毕时,主服务器会将生成的RDB文件发送给从服务器,从服务器接收并载入这个RDB文件
主服务器将记录在缓冲区里面的所有写命令发送给从服务器

命令传播

主服务器接受到写命令后，会执行写命令，同时异步地将写命令发送给从服务器。(期间存在主从不一致的情况，从服务器可以正常响应未被修改的数据。)

旧版复制功能的缺陷

最大缺陷就是从服务器断线重连以后，会导致重新同步，而SYNC命令又是一个非常消耗资源的命令。

生成RDB文件操作会耗费主服务器大量的CPU、内存和磁盘IO资源。
RDB文件发送给从服务器,耗费主从服务器大量的网络资源(带宽和流量),并对主服务器响应命令请求的时间产生影响。
从服务器在载入RDB期间,会因为阻塞而没办法处理命令请求。

新版复制功能的实现

Redis从2.8版本开始使用PSYNC命令代替SYC命令来执行复制时的同步操作。
PSYNC命令具有完整重同步(full resynchronization)和部分重同步(partial resynchronization)两种模式:

完整重同步:初次复制使用，和sync命令相同。
部分重同步：用于处理断线后重复制,如果条件允许,主服务器可以将主从服务器连接断开期间执行的写命令发送给从服务器,从服务器只要接收并执行这些写命令。

无盘复制(主节点不产生RDB文件)

**Redis 2.8.18 版开始支持无盘复制。**所谓无盘复制是指主服务器直接通过套接字将快照内容发送到从节点，生成快照是一个遍历的过程，主节点会一边遍历内存，一遍将序列化的内容发送到从节点。

部分重同步的实现

部分重同步功能由以下三个部分构成:

主服务器的复制偏移量( replication offset)和从服务器的复制偏移量。
主服务器的复制积压缓冲区( replication backlog)
服务器的运行ID( run Id)

复制偏移量(replication offset)

执行复制的双方，主、从服务器会分别维护一个复制偏移量。
如果主从服务器复制偏移量不同，则需要从主服务器进行复制。

复制积压缓冲区

复制积压缓冲区是由主服务器维护的一个固定长度( fixed-size)先进先出(FIFO)队列,默认大小为1MB。

主服务器的复制积压缓冲区里面会保存着一部分最近传播的写命令,并且复制积压缓冲区会为队列中的每个字节记录相应的复制偏移量。

如果offset偏移量之后的数据，还在复制积压缓冲区，则会进行部分同步。如果数据已经没有了，从服务器落后太多，则进行整库同步。

服务器运行ID

每个 Redis服务器,都会有自己的运行ID,运行ID在服务器启动时自动生成

当进行初次复制时,主服务器会将自己的运行ID传送给从服务器,而从服务器会将这个运行ID保存起来。

当从服务器断线并重新连上一个主服务器时,从服务器将向当前连接的主服务器发送之前保存的运行ID,如果从服务器保存的运行ID和当前连接的主服务器的运行ID并不相同,将执行完整重同步操作。

心跳检测

在命令传播阶段,从服务器默认会以每秒一次的频率,向主服务器发送命令:

1	REPLCONF ACK <replication offset>

replication offset是从服务器当前的复制偏移量。
发送 REPLCONF ACK命令对于主从服务器有三个作用

检测主从服务器的网络连接状态。
辅助实现min-slaves选项。
检测命令丢失。

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

辅助实现min-slaves选项

主服务器只在有至少 N 个从服务器的情况下，才执行写操作

从 Redis 2.8 开始，为了保证数据的安全性，可以通过配置，让主服务器只在有至少 N 个当前已连接从服务器的情况下，才执行写命令。

不过，因为Redis 使用异步复制，所以主服务器发送的写数据并不一定会被从服务器接收到，因此数据丢失的可能性仍然是存在的。

以下是这个特性的运作原理：

从服务器以每秒一次的频率 PING 主服务器一次，并报告复制流的处理情况。
主服务器会记录各个从服务器最后一次向它发送 PING 的时间。
用户可以通过配置，指定网络延迟的最大值 min-slaves-max-lag ，以及执行写操作所需的至少从服务器数量 min-slaves-to-write。

如果至少有 min-slaves-to-write 个从服务器，并且这些服务器的延迟值都少于 min-slaves-max-lag 秒，那么主服务器就会执行客户端请求的写操作。

你可以将这个特性看作 CAP 理论中的 C 的条件放宽版本：尽管不能保证写操作的持久性，但起码丢失数据的窗口会被严格限制在指定的秒数中。

另一方面， 如果条件达不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的条件，那么写操作就不会被执行， 主服务器会向请求执行写操作的客户端返回一个错误。

检测命令丢失

检测offet，如果不相同，则进行部分同步。

如果因为网络故障,主服务器传播给从服务器的写命令在半路丢失,那么当从服务器向主服务器发送 REPLCONF ACK命令时,主服务器将发觉从服务器当前的复制偏移量少于自己的复制偏移量,然后主服务器就会根据从服务器提交的复制偏移量,在复制积压缓冲区里面找到从服务器缺少的数据,并将这些数据重新发送给从服务器。

参考

redis官网文档1
redis官网文档2

Chenaa's Notes

redis06_Replication