redis系列：主从复制

1 简介

这篇文章主要讲述Redis的主从复制功能。会依次从环境搭建、功能测试和原理分析几个方面进行介绍。

2 准备工做

服务器架构图以下

启动主服务器101，使用info replication命令查看状态，能够看到role为master（也就是角色为主主服务器），connected_salaves的值为0（从服务器数量为0）

接下来用修改配置文件的方式将102机器加入的主从复制当中

而后再用命令的方式一样将103机器加入的主从复制当中。

2.1 用修改配置文件的方式将102机器加入到主从

ip地址为192.168.17.102的机器的Redis配置文件增长slaveof 192.168.17.101 6379
启动102的redis，状态以下

能够看到role变为slave（角色为从服务器），master_host（主服务器IP地址）为192.168.17.101，master_port（主服务器端口）为6379。
此时101主服务器的主从状态以下,能够看到connected_salaves的值变为1，以及增长了一行slave0（从服务器的状态）

2.2 用命令的方式将103机器加入到主从

未执行slaveof命令的主从状态以下

开始执行slaveof命令

192.168.17.103:6379> slaveof 192.168.17.101 6379
OK

再次查看状态，能够看到角色已经变成从服务器

如今再来看看主服务器的状态，能够看到从服务器数量变成2，又多了一条从服务器的信息

到这里主从环境就搭好了，如今来测试一波

2.3 测试

如今主服务器101输入命令

192.168.17.101:6379> set 101 101
OK

而后在从服务器102上查看全部的键，发现有键101，接着设置键102

192.168.17.102:6379> keys *
1) "101"
192.168.17.102:6379> get 101
"101"
192.168.17.102:6379> set 102 102
(error) READONLY You can't write against a read only slave.

发现出现错误(error) READONLY You can't write against a read only slave. 后面在讲述出错缘由

如今在从服务器103上查看全部的键，发现也有101

192.168.17.103:6379> keys *
1) "101"

再向主服务器101输入命令

192.168.17.101:6379> set ip ip
OK

而后到从服务器103上查看全部的键

192.168.17.103:6379> keys *
1) "101"
2) "ip"

能够看到多了一个键，说明主服务的数据同步到了从服务器上，操做过程看下图

2.4 其余

2.4.1 (error) READONLY You can't write against a read only slave.

出现错误(error) READONLY You can't write against a read only slave. 是由于
从节点默认是只读的，如需修改能够再配置文件中修改下面这个属性

slave-read-only yes

2.4.2 主服务器设置密码

当主服务设置密码时，配置文件须要增长如需参数

masterauth <master-password>

3 实现原理

当我在从服务器103上输入slaveof命令时，出现以下日志

总的来讲主从复制功能的详细步骤能够分为7个步骤：

1. 设置主服务器的地址和端口
2. 创建套接字链接
3. 发送PING命令
4. 身份验证
5. 发送端口信息
6. 同步
7. 命令传播

接下来分别叙述每一个步骤

3.1设置主服务器的地址和端口

主从复制的第一步就是设置主服务器的地址和端口，当输入slaveof命令或者在配置文件中配置信息时，从服务器会将主服务器的ip地址和端口号保存到服务器状态的属性里面。

3.2 创建套接字链接

在slaveof命令执行以后，从服务器会根据设置的ip和端口，向主服务器简历socket链接。

3.3 发送PING命令

socket链接成功后，从服务器会发送一PING命令给主服务器。

这时候PING命令能够检查socket的读写状态是否正常，还能够检查主服务器可否正常处理命令请求。

从服务器在发送PING命令时可能赶上的状况以下图

3.4 身份验证

从服务器收到主服务器的PONG回复后，会检查从服务器是否设置masterauth，设置则进行身份验证，未设置则跳过该步骤。从服务器在身份验证时可能赶上的状况以下

3.5 发送端口信息

身份验证经过后，从服务器会向主服务器发送本身的监听端口号。主服务器收到以后会将端口号记录到从服务器对应的状态属性中。在主服务器调用info replication能够看到从服务器的port，以下

3.6 同步

发送端口信息以后，从服务器会向主服务器发送PSYNC命令，执行同步操做，并将本身的数据库同步至主服务器数据库当前的状态。

同步这块内容会在后面详细描述

3.7 命令传播

当完成同步操做以后，主从服务器便会进入命令传播阶段。这时候主从服务器的数据是一致的，当主服务器有新的写命令时，会将改命令发送给从服务器，从服务器接收命令并执行即可以保证与主服务器的数据保持一致。
那么Redis是如何保证主从服务器一致处于链接状态以及命令是否丢失？
答：命令传播阶段，从服务器会利用心跳检测机制定时的向主服务发送消息。
从服务器发送的命令以下

REPLCONF ACK <replication_offset>

replication_offset表示从服务器当前的复制偏移量
接下来看看心跳机制

3.7.1 心跳检测机制

心跳检测机制的做用有三个：

1. 检查主从服务器的网络链接状态
2. 辅助实现min-slaves选项
3. 检测命令丢失

3.7.1.1 检查主从服务器的网络链接状态

主服务器信息中能够看到所属的从服务器的链接信息，state表示从服务器状态，offset表示复制偏移量，lag表示延迟值（几秒以前有过心跳检测机制）

3.7.1.2 辅助实现min-slaves选项

Redis.conf配置文件中有下方两个参数

# 未达到下面两个条件时，写操做就不会被执行
# 最少包含的从服务器
# min-slaves-to-write 3
# 延迟值
# min-slaves-max-lag 10

若是将两个参数的注释取消，那么若是从服务器的数量少于3个，或者三个从服务器的延迟（lag）大于等于10秒时，主服务器都会拒绝执行写命令。

3.7.1.3 检测命令丢失

在从服务器的链接信息中能够看到复制偏移量，若是此时主服务器的复制偏移量与从服务器的复制偏移量不一致时，主服务器会补发缺失的数据。

4 同步原理

同步分为全量重同步和部分重同步。那么是什么决定采起全量重同步仍是部分重同步操做？

4.1 全量重同步

全量重同步的步骤以下

1. 主节点收到从服务器的全量重同步请求时，主服务器便开始执行bgsave命令，同时用一个缓冲区记录从如今开始执行的全部写命令。
2. 当主服务器的bgsave命令执行完毕后，会将生成的RDB文件发送给从服务器。从服务器接收到RDB文件时，会将数据文件保存到硬盘，而后加载到内存中。
3. 主服务器将缓冲区全部缓存的命令发送到从服务器，从服务器接收并执行这些命令，将从服务器同步至主服务器相同的状态。

4.2 部分重同步

要想了解部分重同步的步骤，须要先了解部分重同步所须要的几个属性

1. 复制偏移量
2. 复制缓冲区
3. 运行ID

4.2.1 复制偏移量

从主服务器的复制信息能够看到从服务器slave0和slave1都有一个参数offset，这个参数就是从服务器的复制偏移量。master_repl_offset这个参数就是主服务器的偏移量。以下图

主服务器的复制偏移量保存向从服务器发送过的字节数据。
从服务器的复制偏移量保存着从主服务器接收的字节数据。
经过对比主服务器和从服务器的复制偏移量就能够知道命令是否丢失，丢失则补发复制偏移量相差的字节命令。
那么这些字节数据是存放在哪里的呢？

4.2.2 复制缓冲区

这些字节数据都是存放在主服务器的复制缓冲区里的。复制缓冲区是一个固定长度（fixed-size）先进先出（FIFO）的队列，默认大小为1MB。默认大小能够对下方的参数进行修改

# repl-backlog-size 1mb

那么复制缓冲区的数据是何时加入进去的呢？

答：在命令传播阶段，主节点除了将写命令发送给从节点，还会发送一份给复制积压缓冲区。

复制缓冲区里面会保存着一部分最传播的写命令和每一个字节相应的复制偏移量。

因为复制缓冲区的大小是有限制的，因此保存的数据也是有限制的。若是从服务器与主服务器的复制偏移量相差的数据大于复制缓冲去存储的数据时，一样不会执行部分重同步。

举个例子，主服务器的复制偏移量为20000、缓冲区能保存的数据只有5000，从服务器的复制偏移量为10000。这时从服务器与主服务器复制偏移量10000，而缓冲区只有5000，那么仍是会执行全量重同步。若是相差的复制偏移量小于5000，才会执行部分重同步。

4.2.3 运行ID

每一个Redis服务器启动时，都会有自动生成本身的运行ID。
当从服务器对主服务器进行初次复制时，主服务器会发送本身的运行ID给从服务器。
当从服务器断线重连时，会将以前主服务器的运行ID发送给当前链接的主服务器。这时候会出现下面两种状况

1. 运行ID和主服务器一致，主服务器能够尝试执行部分重同步操做。
2. 运行ID和主服务器不一致，说明以前链接的主服务器与此次链接不一样，开始执行全量重同步操做。

5 相关配置

################################# REPLICATION #################################

# slaveof <主服务器ip> <主服务器端口>
# slaveof <masterip> <masterport>

# masterauth <主服务器Redis密码>
# masterauth <master-password>

# 当slave丢失master或者同步正在进行时，若是发生对slave的服务请求
# yes则slave依然正常提供服务
# no则slave返回client错误："SYNC with master in progress"
slave-serve-stale-data yes

# 指定slave是否只读
slave-read-only yes

# 无硬盘复制功能
repl-diskless-sync no

# 无硬盘复制功能间隔时间
repl-diskless-sync-delay 5

# 从服务器发送PING命令给主服务器的周期
# repl-ping-slave-period 10

# 超时时间
# repl-timeout 60

# 是否禁用socket的NO_DELAY选项
repl-disable-tcp-nodelay no

# 设置主从复制容量大小，这个backlog 是一个用来在 slaves 被断开链接时存放 slave 数据的 buffer
# repl-backlog-size 1mb

# master 再也不链接 slave时backlog的存活时间。
# repl-backlog-ttl 3600

# slave的优先级
slave-priority 100

# 未达到下面两个条件时，写操做就不会被执行
# 最少包含的从服务器
# min-slaves-to-write 3
# 延迟值
# min-slaves-max-lag 10

结语

主从的配置文件：[https://github.com/rainbowda/...，有须要能够下载。

Redis的主从复制功能就介绍到这里了。虽说主从解决了读写分离，读数据的负载均衡，可是一旦某个节点出现故障，不能自动回复，主从切换等功能。因此就有了哨兵的功能。