Redis-11-主从复制

1. 概念介绍

• 前面介绍Redis，我们都在一台服务器上进行操作的，也就是说读和写以及备份操作都是在一台Redis服务器上进行的，那么随着项目访问量的增加，对Redis服务器的操作也越加频繁，虽然Redis读写速度都很快，但是一定程度上也会造成一定的延时，那么为了解决访问量大的问题，通常会采取的一种方式是主从架构Master/Slave，Master 以写为主，Slave 以读为主，Master 主节点更新后根据配置，自动同步到从机Slave 节点。

最低需要一主二从（三台服务器）

主从复制的作用：

1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
4. 读写分离：可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量；
5. 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，**因此说主从复制是Redis高可用的基础。**

参考博客： https://blog.csdn.net/miss1181248983/article/details/90056960

2. 主从模式

主从模式特点

• 主数据库可以进行读写操作，当读写操作导致数据变化时会自动将数据同步给从数据库

• 从数据库一般都是只读的，并且接收主数据库同步过来的数据

• 一个master可以拥有多个slave，但是一个slave只能对应一个master

• slave挂了不影响其他slave的读和master的读和写，重新启动后会将数据从master同步过来

• master挂了以后，不影响slave的读，但redis不再提供写服务，master重启后redis将重新对外提供写服务

• master挂了以后，不会在slave节点中重新选一个master

工作机制：

• 当slave启动后，主动向master发送SYNC命令。master接收到SYNC命令后在后台保存快照（RDB持久化）和缓存保存快照这段时间的命令，然后将保存的快照文件和缓存的命令发送给slave。slave接收到快照文件和命令后加载快照文件和缓存的执行命令。

• 复制初始化后，master每次接收到的写命令都会同步发送给slave，保证主从数据一致性。

2.1 修改配置文件

1. 首先将redis.conf 配置文件复制三份，通过修改端口分别模拟三台Redis服务器。

①、修改 daemonize yes

表示指定Redis以守护进程的方式启动（后台启动）

②、配置PID文件路径 pidfile

表示当redis作为守护进程运行的时候，它会把 pid 默认写到 /var/redis/run/redis_6379.pid 文件里面

③、配置端口 port

④、配置log 文件名字

⑤、配置rdb文件名

依次将 6380redis.conf 、6381redis.conf 配置一次，则配置完毕。

接下来我们分别启动这三个服务。

通过命令查看Redis是否启动：

2.2 设置主从关系

默认情况下，每台REedis服务器都是主节点

① 通过 info replication 命令查看节点角色

我们发现这三个节点都是扮演的 Master 角色。那么如何将 6380 和 6381 节点变为 Slave 角色呢？

② 选择6380端口和6381端口，执行命令：SLAVEOF 127.0.0.1 6379

再看 6379 节点信息：

2.3 测试细节

• 主机可以写，从机不能写（从机只能读）

• 主机中的所有数据都会被从机保存

①、增量复制

主节点执行 set k1 v1 命令，从节点 get k1 能获取

②、全量复制

　通过执行 SLAVEOF 127.0.0.1 6379，如果主节点 6379 以前还存在一些 key，那么执行命令之后，从节点会将以前的信息也都复制过来吗？

答案也是肯定的

③、主从读写分离

主节点能够执行写命令，从节点能够执行写命令吗？

这里的原因是在配置文件 6381redis.conf 中对于 slave-read-only 的配置

如果我们将其修改为 no 之后，执行写命令是可以的。

但是从节点写命令的数据从节点或者主节点都不能获取的。

④、主节点宕机

主节点 Maste 挂掉，两个从节点角色会发生变化吗？

上图可知主节点 Master 挂掉之后，从节点角色还是不会改变的。

⑤、主节点宕机后恢复

主节点Master挂掉之后，马上启动主机Master，主节点扮演的角色还是 Master 吗？

也就是说主节点挂掉之后重启，又恢复了主节点的角色。

2.4 层层链路

一个节点上一个是Master,下一个是Slave(自己同时也是Slave)

这个时候也可以实现主从复制

如果主机断开了链接，可以通过命令(手动选择老大)

slaveof no one  ## 让自己变成主机
## 如果这个时候主机回来了，那么主机无法变回Master节点

3. 哨兵模式(Sentinel模式)

• 主从模式的弊端就是不具备高可用性，当master挂掉以后，Redis将不能再对外提供写入操作，因此sentinel应运而生。

• 通过前面的配置，主节点Master 只有一个，一旦主节点挂掉之后，从节点没法担起主节点的任务，那么整个系统也无法运行。如果主节点挂掉之后，从节点能够自动变成主节点，那么问题就解决了，于是哨兵模式诞生了。

• 哨兵模式就是不时地监控redis是否按照预期良好地运行（至少是保证主节点是存在的），若一台主机出现问题时，哨兵会自动将该主机下的某一个从机设置为新的主机，并让其他从机和新主机建立主从关系。

* sentinel模式是建立在主从模式的基础上，如果只有一个Redis节点，sentinel就没有任何意义

* 当master挂了以后，sentinel会在slave中选择一个做为master，并修改它们的配置文件，其他slave的配置文件也会被修改，比如slaveof属性会指向新的master

* 当master重新启动后，它将不再是master而是做为slave接收新的master的同步数据

* sentinel因为也是一个进程有挂掉的可能，所以sentinel也会启动多个形成一个sentinel集群

* 多sentinel配置的时候，sentinel之间也会自动监控

* 当主从模式配置密码时，sentinel也会同步将配置信息修改到配置文件中，不需要担心

* 一个sentinel或sentinel集群可以管理多个主从Redis，多个sentinel也可以监控同一个redis

* sentinel最好不要和Redis部署在同一台机器，不然Redis的服务器挂了以后，sentinel也挂了

工作机制：

* 每个sentinel以每秒钟一次的频率向它所知的master，slave以及其他sentinel实例发送一个 PING 命令 

* 如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被sentinel标记为主观下线。 

* 如果一个master被标记为主观下线，则正在监视这个master的所有sentinel要以每秒一次的频率确认master的确进入了主观下线状态

* 当有足够数量的sentinel（大于等于配置文件指定的值）在指定的时间范围内确认master的确进入了主观下线状态， 则master会被标记为客观下线 

* 在一般情况下， 每个sentinel会以每 10 秒一次的频率向它已知的所有master，slave发送 INFO 命令 

* 当master被sentinel标记为客观下线时，sentinel向下线的master的所有slave发送 INFO 命令的频率会从 10 秒一次改为 1 秒一次 

* 若没有足够数量的sentinel同意master已经下线，master的客观下线状态就会被移除；
  若master重新向sentinel的 PING 命令返回有效回复，master的主观下线状态就会被移除

• 然而一个哨兵进程对Redis监控，可能会出现问题，为此，我们使用多个哨兵进行监控。各个哨兵之间还会监控，这样形成了多哨兵模式。

哨兵模式搭建步骤：

①、在配置文件目录下新建 sentinel.conf 文件，名字绝不能错，然后配置相应内容

sentinel monitor 被监控机器的名字(自己起名字) ip地址 端口号 得票数

分别配置被监控的名字，ip地址，端口号，以及得票数。上面的得票数为1表示表示主机挂掉后salve投票看让谁接替成为主机，得票数大于1便成为主机

②、启动哨兵

redis-sentinel 哨兵地址/sentinel.conf

接下来，我们干掉主机 6379，然后看从节点有啥变化。

干掉主节点之后，我们查看后台打印日志，发现 6380投票变为主节点了。

PS：哨兵模式也存在单点故障问题，如果哨兵机器挂了，那么就无法进行监控了，解决办法是哨兵也建立集群，Redis哨兵模式是支持集群的。可以采用上述多哨兵模式

如果此时主机回来了，也只会变回哨兵。

3.1 原理分析

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

　　①、旧版同步

　　当从节点发出 SLAVEOF 命令，要求从服务器复制主服务器时，从服务器通过向主服务器发送 SYNC 命令来完成。该命令执行步骤：

　　1、从服务器向主服务器发送 SYNC 命令

　　2、收到 SYNC 命令的主服务器执行 BGSAVE 命令，在后台生成一个 RDB 文件，并使用一个缓冲区记录从开始执行的所有写命令

　　3、当主服务器的 BGSAVE 命令执行完毕时，主服务器会将 BGSAVE 命令生成的 RDB 文件发送给从服务器，从服务器接收此 RDB 文件，并将服务器状态更新为RDB文件记录的状态。

　　4、主服务器将缓冲区的所有写命令也发送给从服务器，从服务器执行相应命令。

　　②、命令传播

　　当同步操作完成之后，主服务器会进行相应的修改命令，这时候从服务器和主服务器状态就会不一致。

　　为了让主服务器和从服务器保持状态一致，主服务器需要对从服务器执行命令传播操作，主服务器会将自己的写命令发送给从服务器执行。从服务器执行相应的命令之后，主从服务器状态继续保持一致。

　　总结：通过同步操作以及命令传播功能，能够很好的保证了主从一致的特性。

　　但是我们考虑一个问题，如果从服务器在同步主服务器期间，突然断开了连接，而这时候主服务器进行了一些写操作，这时候从服务器恢复连接，如果我们在进行同步，那么就必须将主服务器从新生成一个RDB文件，然后给从服务器加载，这样虽然能够保证一致性，但是其实断开连接之前主从服务器状态是保持一致的，不一致的是从服务器断开连接，而主服务器执行了一些写命令，那么从服务器恢复连接后能不能只要断开连接的哪些写命令，而不是整个RDB快照呢？

　　同步操作其实是一个非常耗时的操作，主服务器需要先通过 BGSAVE 命令来生成一个 RDB 文件，然后需要将该文件发送给从服务器，从服务器接收该文件之后，接着加载该文件，并且加载期间，从服务器是无法处理其他命令的。

　　为了解决这个问题，Redis从2.8版本之后，使用了新的同步命令 PSYNC 来代替 SYNC 命令。该命令的部分重同步功能用于处理断线后重复制的效率问题。也就是说当从服务器在断线后重新连接主服务器时，主服务器只将断开连接后执行的写命令发送给从服务器，从服务器只需要接收并执行这些写命令即可保持主从一致。

3.2 优缺点分析

优点：

• 哨兵集群，基于主从赋值,所有主从复制的优点都有
• 主从可以自动切换
• 哨兵模式其实就是主从模式的升级

4. Cluster模式

参考博客：

https://www.zhihu.com/question/21419897

https://www.cnblogs.com/williamjie/p/11132211.html

• sentinel模式基本可以满足一般生产的需求，具备高可用性。但是当数据量过大到一台服务器存放不下的情况时，主从模式或sentinel模式就不能满足需求了，这个时候需要对存储的数据进行分片，将数据存储到多个Redis实例中。cluster模式的出现就是为了解决单机Redis容量有限的问题，将Redis的数据根据一定的规则分配到多台机器。

• 随着公司发展，用户数量增多，并发越来越多，业务需要更高的QPS，而主从复制中单机的QPS可能无法满足业务需求

• cluster可以说是sentinel和主从模式的结合体，通过cluster可以实现主从和master重选功能（只不过这是cluster模式自己就自带的功能）。保证高可用，每个主节点都有一个从节点，当主节点故障，Cluster会按照规则实现主备的高可用性

  对于节点来说，有一个配置项：cluster-enabled，即是否以集群模式启动

特点：

* 多个redis节点网络互联，数据共享

4.1 数据分布

4.1.1 顺序分布

• 比如：1到100个数字，要保存在3个节点上，按照顺序分区，把数据平均分配三个节点上 1号到33号数据保存到节点1上，34号到66号数据保存到节点2上，67号到100号数据保存到节点3上

4.1.2 哈希分布

• 例如1到100个数字，对每个数字进行哈希运算，然后对每个数的哈希结果除以节点数进行取余，余数为1则保存在第1个节点上，余数为2则保存在第2个节点上，余数为0则保存在第3个节点，这样可以保证数据被打散，同时保证数据分布的比较均匀

1. 节点hash取余

• 比如有100个数据，对每个数据进行hash运算之后，与节点数进行取余运算，根据余数不同保存在不同的节点上

节点取余方式是非常简单的一种分区方式

节点取余分区方式有一个问题：即当增加或减少节点时，原来节点中的80%的数据会进行迁移操作，对所有数据重新进行分布

节点取余分区方式建议使用多倍扩容的方式，例如以前用3个节点保存数据，扩容为比以前多一倍的节点即6个节点来保存数据，这样只需要适移50%的数据。数据迁移之后，第一次无法从缓存中读取数据，必须先从数据库中读取数据，然后回写到缓存中，然后才能从缓存中读取迁移之后的数据

节点取余方式优点：

客户端分片
配置简单：对数据进行哈希，然后取余

节点取余方式缺点：

数据节点伸缩时，导致数据迁移
迁移数量和添加节点数据有关，建议翻倍扩容

2. 一致性哈希分区

原理：

• 将所有的数据当做一个token环，token环中的数据范围是0到2的32次方。然后为每一个数据节点分配一个token范围值，这个节点就负责保存这个范围内的数据。
• 对每一个key进行hash运算，被哈希后的结果在哪个token的范围内，则按顺时针去找最近的节点，这个key将会被保存在这个节点上。

扩容原理

• 在图中，有4个key被hash之后的值在在n1节点和n2节点之间，按照顺时针规则，这4个key都会被保存在n2节点上， 如果在n1节点和n2节点之间添加n5节点，当下次有key被hash之后的值在n1节点和n5节点之间，这些key就会被保存在n5节点上面了 在上面的例子里，添加n5节点之后，数据迁移会在n1节点和n2节点之间进行，n3节点和n4节点不受影响，数据迁移范围被缩小很多 同理，如果有1000个节点，此时添加一个节点，受影响的节点范围最多只有千分之2 一致性哈希一般用在节点比较多的时候

一致性哈希分区优点：

采用客户端分片方式：哈希 + 顺时针(优化取余)
节点伸缩时，只影响邻近节点，但是还是有数据迁移

一致性哈希分区缺点：

翻倍伸缩，保证最小迁移数据和负载均衡

4.1.3 虚拟槽分区（重要）

• 虚拟槽分区是Redis Cluster采用的分区方式

  预设虚拟槽，每个槽就相当于一个数字，有一定范围。每个槽映射一个数据子集，一般比节点数大

  Redis Cluster中预设虚拟槽的范围为0到16383

步骤：

1.把16384槽按照节点数量进行平均分配，由节点进行管理
2.对每个key按照CRC16规则进行hash运算
3.把hash结果对16383进行取余
4.把余数发送给Redis节点
5.节点接收到数据，验证是否在自己管理的槽编号的范围
    如果在自己管理的槽编号范围内，则把数据保存到数据槽中，然后返回执行结果
    如果在自己管理的槽编号范围外，则会把数据发送给正确的节点，由正确的节点来把数据保存在对应的槽中

需要注意的是：Redis Cluster的节点之间会共享消息，每个节点都会知道是哪个节点负责哪个范围内的数据槽

虚拟槽分布方式中，由于每个节点管理一部分数据槽，数据保存到数据槽中。当节点扩容或者缩容时，对数据槽进行重新分配迁移即可，数据不会丢失。
虚拟槽分区特点：

使用服务端管理节点，槽，数据：例如Redis Cluster
可以对数据打散，又可以保证数据分布均匀

4.2 故障发现

Redis Cluster通过ping/pong消息实现故障发现：不需要sentinel

ping/pong不仅能传递节点与槽的对应消息，也能传递其他状态，比如：节点主从状态，节点故障等

故障发现就是通过这种模式来实现，分为主观下线和客观下线

4.2.1 主观下线

某个节点认为另一个节点不可用，’偏见’，只代表一个节点对另一个节点的判断，不代表所有节点的认知

主观下线流程：

1.节点1定期发送ping消息给节点2
2.如果发送成功，代表节点2正常运行，节点2会响应PONG消息给节点1，节点1更新与节点2的最后通信时间
3.如果发送失败，则节点1与节点2之间的通信异常判断连接，在下一个定时任务周期时，仍然会与节点2发送ping消息
4.如果节点1发现与节点2最后通信时间超过node-timeout，则把节点2标识为pfail状态

4.2.2 客观下线

当半数以上持有槽的主节点都标记某节点主观下线时，可以保证判断的公平性

集群模式下，只有主节点(master)才有读写权限和集群槽的维护权限，从节点(slave)只有复制的权限

客观下线流程：

1.某个节点接收到其他节点发送的ping消息，如果接收到的ping消息中包含了其他pfail节点，这个节点会将主观下线的消息内容添加到自身的故障列表中，故障列表中包含了当前节点接收到的每一个节点对其他节点的状态信息
2.当前节点把主观下线的消息内容添加到自身的故障列表之后，会尝试对故障节点进行客观下线操作

4.3 故障恢复

1. 资格检查

   对从节点的资格进行检查，只有难过检查的从节点才可以开始进行故障恢复
   每个从节点检查与故障主节点的断线时间
   超过cluster-node-timeout * cluster-slave-validity-factor数字，则取消资格
   cluster-node-timeout默认为15秒，cluster-slave-validity-factor默认值为10
   如果这两个参数都使用默认值，则每个节点都检查与故障主节点的断线时间，如果超过150秒，则这个节点就没有成为替换主节点的可能性

2. 准备选举时间

   使偏移量最大的从节点具备优先级成为主节点的条件

3. 选举投票

对选举出来的多个从节点进行投票，选出新的主节点

4. 替换主节点

   当前从节点取消复制变成离节点(slaveof no one)
   执行cluster del slot撤销故障主节点负责的槽，并执行cluster add slot把这些槽分配给自己
   向集群广播自己的pong消息，表明已经替换了故障从节点

打赏