【Redis】Redis高级：主从

Redis高级：主从

由于Redis是单线程的，因此其拥有很强的并发能力，但是单节点的Redis并发能力始终还是有上限的，如果需要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。

在Redis主从集群中，一般提供一台主节点负责Redis的写操作，提供多台从节点负责Redis的读操作。之所以这样布局，是因为Redis通常情况下面对的读数据的压力要远远大于写数据

1 搭建主从架构

接下来我们会在同一台虚拟机中开启3个redis实例（包括1个主节点，2个从节点。）来模拟主从集群，这些实例的信息分别如下：

IP	PORT	角色
192.168.211.100	7001	master
192.168.211.100	7002	slave
192.168.211.100	7003	slave

1.1 准备实例和配置

要在同一台虚拟机开启3个实例，必须准备三份不同的配置文件和目录，配置文件所在目录也就是工作目录。

我的Redis的安装目录是在 /usr/local/redis-6.2.6，在接下来的操作中会以这个目录为例进行演示

0）取消redis密码认证

首先很重要的一件事（笔者在这里踩了不少坑），我们需要取消redis的密码认证，不然后续操作会出现很多问题。修改redis安装目录下的redis.conf文件，将其中的requirepass 密码这一行配置给注释掉，然后重启redis服务

1）创建目录

首先创建三个文件夹，名字分别叫7001、7002、7003：

# 进入/usr/local目录
cd /usr/local
# 创建目录
mkdir 7001 7002 7003

如图所示：

2）恢复原始配置

如果之前修改过 redis-6.2.4/redis.conf 文件中的持久化模式，则需要将持久化模式修改成默认的RDB模式，AOF保持关闭状态。如果并未修改过可以跳过这一步

# 开启RDB
# save ""
save 3600 1
save 300 100
save 60 10000

# 关闭AOF
appendonly no

3）拷贝配置文件到每个实例目录

将 redis-6.2.6/redis.conf 文件拷贝到三个目录中（在/local目录执行下列命令）：

# 方式一：逐个拷贝
cp redis-6.2.6/redis.conf 7001
cp redis-6.2.6/redis.conf 7002
cp redis-6.2.6/redis.conf 7003

# 方式二：管道组合命令，一键拷贝
echo 7001 7002 7003 | xargs -t -n 1 cp redis-6.2.6/redis.conf

4）修改每个实例的端口、工作目录

修改每个文件夹内的配置文件，将端口分别修改为7001、7002、7003，将rdb文件保存位置都修改为自己所在目录（在/local目录执行下列命令）：

sed -i -e 's/6379/7001/g' -e 's/dir .\//dir \/usr\/local\/7001\//g' 7001/redis.conf
sed -i -e 's/6379/7002/g' -e 's/dir .\//dir \/usr\/local\/7001\//g' 7002/redis.conf
sed -i -e 's/6379/7003/g' -e 's/dir .\//dir \/usr\/local\/7001\//g' 7003/redis.conf

5）修改每个实例的声明IP

虚拟机本身有多个IP，为了避免将来混乱，我们需要在redis.conf文件中指定每一个实例的绑定ip信息，格式如下：

# redis实例的声明 IP为自己虚拟机的IP
replica-announce-ip 192.168.211.100

由于每个目录都的要redis.conf文件都要修改，我们也可以通过以下命令一键完成修改（在/local目录执行下列命令）：

# 逐一执行
sed -i '1a replica-announce-ip 192.168.211.100' 7001/redis.conf
sed -i '1a replica-announce-ip 192.168.211.100' 7002/redis.conf
sed -i '1a replica-announce-ip 192.168.211.100' 7003/redis.conf

# 或者一键修改
printf '%s\n' 7001 7002 7003 | xargs -I{} -t sed -i '1a replica-announce-ip 192.168.211.100' {}/redis.conf

1.2 启动

为了方便查看日志，我们在额外打开3个ssh窗口（目前使用的窗口先不要关闭），分别启动3个redis实例，启动命令：

# 第1个
redis-server /usr/local/7001/redis.conf
# 第2个
redis-server /usr/local/7002/redis.conf
# 第3个
redis-server /usr/local/7003/redis.conf

如果要一键停止，可以运行下面命令：

printf '%s\n' 7001 7002 7003 | xargs -I{} -t redis-cli -p {} shutdown

1.3 开启主从关系

现在三个实例还没有任何关系，要配置主从可以使用replicaof 或者slaveof（5.0以前）命令。

主从关系之间的配置有临时和永久两种模式：

• 修改配置文件（永久生效）在redis.conf中添加一行配置：

  slaveof <masterip> <masterport>
  

• 使用redis-cli客户端连接到redis服务，执行slaveof命令（重启后失效）：

  slaveof <masterip> <masterport>
  

这里我们为了方便演示，使用方式二：

通过redis-cli命令连接7002，执行下面命令：

# 连接7002
redis-cli -p 7002
# 执行slaveof
slaveof 192.168.211.100 7001

通过redis-cli命令连接7003，执行下面命令：

# 连接 7003
redis-cli -p 7003
# 执行slaveof
slaveof 192.168.211.100 7001

然后连接 7001节点，查看集群状态：

# 连接 7001
redis-cli -p 7001 -a 123456
# 查看状态
info replication

整体流程图示如下：

1.4 测试

执行下列操作以测试：

• 利用redis-cli连接7001，执行set num 123

• 利用redis-cli连接7002，执行get num，再执行set num 666

• 利用redis-cli连接7003，执行get num，再执行set num 888

可以发现，只有在7001这个master节点上可以执行写操作，7002和7003这两个slave节点只能执行读操作。

2 主从数据同步原理

2.1 全量同步

主从第一次建立连接时，会执行全量同步，将master节点的所有数据都拷贝给slave节点，具体流程如下：

主从第一次建立连接后，slave会向master发送数据同步的请求。master在接收到slave的请求后，首先会判断slave是不是第一次请求，如果是第一次请求，master则会将其版本信息返回给slave，而slave在接收到master的版本信息后，会将其保存下来。

master在向slave同步数据时，会执行bgsave命令，异步开辟独立进程来生成RDB文件。RDB文件一旦生成，master就会将RDB文件发送给slave。slave在接收到master发送过来的RDB文件后，首先会清空本地数据，然后再去将RDB文件加载到本地。这样slave中的数据就与master中的数据基本一致了。

为什么说基本一致呢？这是因为RDB文件是异步生成的，在生成RDB文件的过程中，master可能会执行新的命令，从而产生新的数据，而这些新数据已经无法通过RDB来同步给slave了，为了解决这个问题，在生成RDB期间，master所接收的所有命令都会被记录到 一个名为repl_baklog 文件中。在向salve同步完RDB且repl_baklog记录结束后，master就会将repl_baklog文件发送给 slave，slave接收到文件后，就会执行repl_baklog中记录的命令。
若后续仍有新的命令执行，则新的命令依旧会被记录到repl_baklog中，然后再由独立进程发送给slave，slave接收后再执行repl_baklog 中的命令。循环往复，以此来保证slave与master的数据一致性。

在这一过程中，master会将内存中的数据全部同步给slave，所以叫全量同步，这一过程是比较消耗性能的。

这里有一个问题，master如何得知salve是否为第一次来连接的呢？有几个概念可以作为判断依据：

• Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集，每一个节点都会有唯一的replid，而slave第一次连接master并发送同步数据请求时，master会将自己的replid发送给slave，slave拿到这个replid会将自己的原本的replid覆盖
• offset：偏移量，在master中，offset记录的是repl_baklog已经写入的位置，下一次写入记录时会从offset开始写入，slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

因此slave在向master发送数据同步请求时，必须同时携带replication id和offset两项信息，master才可以判断该slave到底需要同步哪些数据。

一个节点在变成slave前，都会有自己独立的replid和offset，当第一次变成slave，与master建立连接时，发送的replid和offset是自己的replid和offset，master判断发现slave发送来的replid与自己的不一致，说明这是一个全新的slave，那么主节点需要做的就是全量同步。同步结束后，master会将自己的replid和offset都发送给这个slave，slave保存这些信息。下一次来访问时，slave的replid就与master保持一致了。

因此，master判断一个节点是否是第一次同步的依据，就是看replid是否一致。

主从第一次建立连接的完整流程描述如下：

• slave节点请求增量同步
• master节点判断replid，发现不一致，拒绝增量同步，进行全量同步
• master将完整内存数据生成RDB，发送RDB到slave
• slave清空本地数据，加载master的RDB
• master将RDB期间的命令记录在repl_baklog，并持续将log中的命令发送给slave
• slave执行接收到的命令，保持与master之间的同步

2.2 增量同步

主从第一次同步是全量同步，但是后续同步，包括slave进行了重启之后的同步，执行的基本上都是增量同步

由于全量同步需要先做RDB，然后将RDB文件通过网络传输给slave，因此进行一次全量同步会占用大量资源。因此除了第一次连接需要做全量同步以外，其它大多数时候slave与master都是做增量同步。

什么是增量同步？就是只更新slave与master存在差异的部分数据。

slave向master发送同步请求之后，请求中会携带有自己的replid与offset。由于slave并不是第一次请求，因此携带的replid和master的replid是一致的。master在判断得知slave并非第一次请求后，会获取svale请求中携带的offset，并从repl_baklog中获取该offset之后的数据，然后将其发送给slave，slave在接收到后执行相关命令。

master和slave之间会按照一定的频率进行增量同步，从而保证slave与master之间数据的一致性

关于上述过程中还有一些细节需要讲解，在这里我们需要了解一下repl_backlog的读写规则

2.3 repl_backlog原理

repl_baklog中记录着Redis已经处理过的命令日志及offset，包括master当前的offset，和slave已经拷贝到的offset。其底层是一个固定大小的数组，但是这个数组是环形的，也就是说角标到达数组末尾后，会再次从0开始读写，这样数组头部的数据就会被覆盖。

为了方便理解，我们可以结合以下图片来观察，图片中绿色部分表示master已经同步给slave的部分，而红色的部分表示master尚未同步给slave的部分：

红色部分的长度为master的offset减去slave的offset，这部分是salve需要进行增量同步的部分。随着不断有数据写入，master的offset逐渐变大，同时master和slave之间也会以一定的频率进行增量同步，从而保证slave的offset是在不断追赶master的offset的

直到数组被填满，master会从数组头部开始再次进行数据的写入：

此时，repl_baklog中的旧数据就被覆盖了。不过，这些旧的数据只要是绿色的，就说明是已经被同步到slave的数据，即便被覆盖了也没什么影响，因为未同步的仅仅只是红色部分。

但是，如果slave出现网络阻塞，导致master的offset远远超过了slave的offset：

如果master继续写入新数据，其offset就会覆盖旧的数据，直到将slave现在的offset覆盖：

棕色框中的红色部分，就是尚未同步，但是却已经被覆盖的数据。此时如果slave恢复正常，需要进行同步，就会发现自己的offset已经被覆盖了，这时主从之间就无法做增量同步了，只能选择做全量同步。

2.4 主从同步优化

主从同步可以保证主从数据的一致性，因此十分重要，我们可以从以下几个方面来优化Redis主从集群的可用性：

• 修改master的redis.conf配置，开启无磁盘复制

  repl-diskless-sync yes
  

  正常的主从同步时，master需要先写RDB文件到磁盘中，然后再将RDB通过网络发送给slave，而磁盘的读写是比较慢的，如果我们启动了无磁盘复制时，master在写RDB文件时就不会写入磁盘，而是直接写入网络然后发送给slave，这样也就减少了一次磁盘读写，提高了整体性能，但是对网络带宽有一定要求，如果带宽不够则很容易引起网络阻塞

• 尽量限制Redis单节点上的内存占用，减少RDB导致的过多磁盘IO

• 适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步

• 尽量限制一个master上的slave节点数量，如果slave数量过多，则可以采用主—从—从的链式结构，减少master压力，具体如下：