【Redis】主从复制和哨兵模式

主从复制

主从复制：主机数据更新后根据配置和策略， 自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主

作用：

• 读写分离，性能扩展
• 容灾快速恢复

主从复制的配置

在我的/myredis目录中，存在redis.conf配置文件

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LcJw1p1j-1671250147140)(https://pg3993-1311808981.cos.ap-nanjing.myqcloud.com/img/image-20221216112825444.png)]

接下来配置一个主机两个从机

第一步：

配置三个不同的redis配置文件；三台服务器对应的端口号，dump文件等信息要不同。

三台服务器对应的端口号分别是：6379，6380，6381

第二步：

启动三台服务器

使用命令：redis-server 配置文件 启动redis服务器

第三步：

客户端连接服务器

使用命令 ：redis-cli -p port 连接redis服务器

使用info replication命令查看当前服务器状和各种消息

目前每台服务器都是主服务器，没有从服务器。

一主二从配置实例

下面将6379redis服务器作为主服务器，6380和6381服务器作为从服务器。

只需要在6380和6381服务器上执行命令： slaveof ip port 挂载主服务器

在主服务器上写入数据，观察从服务器的数据变化

主服务器在执行命令后，从服务器的数据也会相应的发生改变。

从机无法进行写操作，只能执行读操作。

当我们在从机上进行写操作时，从机会报错。

主机宕机的现象

当主机宕机，三个服务器会有什么现象？

当主机宕机后，从服务器会等待主服务器的重新连接。

从服务器挂掉的现象

在从服务器6380上执行shutdown命令。

从服务挂掉后，需要重新执行slaveof ip port命令挂载主服务器。

薪火相传和反客为主机制

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。

特点：

• 中途变更转向:会清除之前的数据，重新建立拷贝最新的
• 风险是一旦某个slave宕机，后面的slave都没法备份
• 主机挂了，从机还是从机，无法写数据了

下面我们将6381服务器配置为6380服务器的从机

反客为主机制：

当6379服务器挂掉后。可以使用命令slaveof no one 让从机6380会成为主服务器：

主从复制的原理

主从服务器间第一次同步的过程分为三个阶段：

• 第一阶段：建立链接，协商同步；
• 第二阶段：主服务器同步数据给从服务器；
• 第三阶段：主服务器发送新写操作命令给服务器

第一阶段

建立链接，协商同步。

从服务器执行slaveof ip port命令后，向主服务器发送psync命令，请求同步。psync包含两个参数：主服务器runID和复制进度offset。这两个参数是传入类型参数

• runID，每个 Redis 服务器在启动时都会自动生产一个随机的 ID 来唯一标识自己。当从服务器和主服务器第一次同步时，因为不知道主服务器的 run ID，所以将其设置为 “?”。
• offset，表示复制的进度，第一次同步时，其值为 -1。

主服务器收到psync命令后，向从服务器发送FULLRESYNC 作为响应命令返回给从服务器。该响应命令会传递两个参数：主服务器的 runID 和主服务器目前的复制进度 offset。从服务器收到响应后，会记录这两个值。

FULLRESYNC 响应命令的意图是采用全量复制的方式，主服务器会把所有的数据都同步给从服务器

第二阶段

主服务器同步数据给从服务器

服务器会执行 bgsave 命令来生成 RDB 文件，然后把文件发送给从服务器。从服务器收到 RDB 文件后，会先清空当前的数据，然后载入 RDB 文件。

第三阶段

同步主服务器的命令到从服务器中。

在主服务器生成的 RDB 文件发送完，从服务器收到 RDB 文件后，丢弃所有旧数据，将 RDB 数据载入到内存。完成 RDB 的载入后，会回复一个确认消息给主服务器。至此，第一次同步工作结束。

第一次同步结束后，主从服务器之间会建立一个TCP连接

后续主服务器可以通过这个连接继续将写操作命令传播给从服务器，然后从服务器执行该命令，使得与主服务器的数据库状态相同。

哨兵模式

哨兵模式：反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

配置实例

先让6379redis服务器成为主服务器，6380和6381成为6379的从服务器。

第一步：

创建一个sentinel.conf文件（文件名不能出错）；在文件中填写相关的配置内容：

sentinel monitor 主服务器名 主服务器ip 主服务器port n

• 这里的n表示，至少有n个哨兵同意迁移的数量

第二步：

执行命令：redis-sentinel 配置文件路径

该命令作用是启动哨兵服务器

redis-sentinel sentinel.conf

第三步：

测试：让主服务器6379shutdown，查看6380和6381的情况。

6379服务器挂掉后，6381按照一定的规则成为了新的服务器；选举主服务器的规则在原理一节中将会详细讲解。

哨兵模式的问题：

• 复制延时：由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。