Redis主从复制

最新推荐文章于 2024-09-23 14:16:45 发布

风城烟雨丶

最新推荐文章于 2024-09-23 14:16:45 发布

阅读量398

点赞数 1

分类专栏： Redis 文章标签：数据库

本文链接：https://blog.csdn.net/weixin_44552039/article/details/108714411

版权

Redis 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

Redis复制 — Master/Slave

介绍

Redis复制也就是我们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的 master/slaver 机制，Master 以写为主，Slave 以读为主。

能干嘛

读写分离
容灾恢复

…

如何使用

口诀：配从不配主！
从库配置：slaceof 主库 IP 主库端口。
每次与master 断开之后，都需要重新连接，除非你在 redis.conf 文件中进行相关配置！
```
Info replication
```

修改配置文件细节操作

拷贝多个 redis.conf 文件

-- 复制命令
cp 原文件名 新文件名

-- 例
cp redis.conf redis6379.conf

在这里插入图片描述

我们重新使用三个新的redis.conf文件

开启 daemonize yes

把三个配置文件中的daemonize都设置为yes
pid 文件名字

为了更加明显，我们把里面的名称进行修改，到时候好查看
指定端口

因为有三个redis，所以需要一个端口对应一个redis，还有两个redis的端口一个为6380一个为6381，这里就不给大家演示了
log 文件名字

这个默认是一个空字符串，我们将它设置一下
dump.rdb 名字

备份文件的名称，默认为dump，我们在它后面加上对应的端口号，查看的时候更加清晰易懂！

其实都是很简单的设置，虽然我这里只演示了一个，但是相信大家应该都会举一反三！！冲冲冲！！！

常用三招

一主二仆

至少要三台机器，三个redis，一个主redis，两个从redis（在刚才我们已经配置好了）

启动三台redis 在这里插入图片描述

因为都是新的，所以里面都没有任何数据，我们还可以在启动后查看是否生成了日志文件

三个日志文件都成功创建了！而且里面都成功记录了！

状态

分配角色

我们可以先看一下当前的redis角色

在这里插入图片描述

可以很明显的发现，他们都是master，表示他们在同一级上，接下来我们就将其中两台机器进行修改，将他们改为从redis

在这里插入图片描述

这里简单说明一下：我们先在6379中插入k1和k2，然后让6380和6381跟6379进行绑定，绑定之后我们在插入一条数据k3，然后去另外两个redis中进行读操作，这个时候按照逻辑来说可能大家会认为，在绑定之前写入的数据是无法读取出来的，但是上面却可以读出来，其实这是因为一旦进行了绑定，那么从服务器就会读取主服务器的所有内容！

绑定后我们再次查看角色

在这里插入图片描述

除了6379还是原来的以外，其它两个都变成了slave，并且在6379下面还可以看到我们所绑定的redis

尝试写入数据

在这里插入图片描述

上图可以明显的看到，我们在6379中可以成功写入数据，但是在其他两个里面却无法正常写入！在最开始的时候我们也说过了，“Master 以写为主，Slave 以读为主”，所以一旦绑定之后，只有主redis可以进行写操作，从redis只能进行读操作。

这里也就考虑出了一个问题，如果主redis突然崩了，这个时候从redis会发生什么呢？

在这里插入图片描述

我们关闭6379之后，从redis并不会自动的就变为主redis，而是继续为“从redis”。我们在想一下，如果这个时候6379突然又好了，那它的角色会是什么呢？我们来看一下效果

哦吼~它还是主redis，那也就表示我们在里面进行写入操作后，从redis依然可以读取到！

刚才说完了主redis突然崩了的情况，接下来再给大家说一下某一台从redis崩了会发生什么

在这里插入图片描述

在6380崩了的时候我们写入了k5，再次启动6380的时候会自动变回master（除非自己配置了），所以在崩坏的期间主机写入的数据，恢复后的从redis是读取不到的！

如果想要继续跟上主redis，那么就需要重新进行连接！
slaveof 127.0.0.1 6379

薪火相传

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

中途变更转向：会清除之前的数据，重新建立拷贝最新的

slaveof 新主库 IP 新主库端口

在这里插入图片描述

我们首先将6381换绑至6380下，然后我们再次查看6379的时候就会发现只剩下一个（6380），然后我们在6379中写入一行数据，之后再6380和6381中进行读取，这样的效果和之前一主二仆的效果差不多。只要主redis写入了新的数据，那么从redis也依旧可以获得。

反客为主

我们先把刚才换绑的redis6381重新绑定到6379中

在这里插入图片描述

案例

-- 转成主数据库
slaveof no one

在这里插入图片描述

① 关闭 redis6379

② 关闭6379后，其他两个就没有了主redis，所以我们将6380转成主数据库，让它变回master角色

③ 变回master角色

④ 6381没有解除绑定，所以它还会继续等待6379

接下来我们就要做到让6380变为主redis

在这里插入图片描述

① 将6381换绑至6380

② 在6380中新写入一行数据

③ 在6381中读取刚才在6380中写入的数据，可以正常读取到

④ 重新启动6379进行读取，可以明显得发现无法读取到刚才再6380中写入的数据

复制原理

slave 启动成功连接到 master 后会发送一个 synchronized（同步）命令。
Master 接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master 将传送整个数据文件到 slave，以完成一次完全同步。
全量复制：而 slave 服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制：Master 继续将新的所有收集到的修改命令依次传给 slave，完成同步。
但是只要是重新连接 master，一次完全同步（全量复制）将被自动执行。

哨兵机制

Redis-Sentinel 是 Redis 官方推荐的高可用（HA）方案，当用 Reids 做master-slave高可用方案时，假如 master 宕机了，redis 本身（包括它的很多客服端）都没有实现自动的主备切换，而 Redis-Sentinel 本身也是一个独立运行的进程，它能监控多个 master-slave 集群，发现 master 宕机后能自动切换。

简单来说就是反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

在公司中，有人上班的时候使用反客为主可能还可以，但是如果在大家都下班了的环境下，主服务器突然崩了，这个时候又没人管，那这个时候就会造成很大的损失，所以我们可以使用它的自动版–哨兵机制！在没人的时候它也可以从剩下的机器中选取一台主机继续使用。

使用步骤

第一步：

调整结构，将我们修改过的 redis 主从关系调整一下，换回之前的 6379 为主 6380 和 6381 为从。

第二步：

自定义的 /myredis 目录下新建 sentinel.conf文件，名字绝不能错！

-- 创建文件
touch sentinel.conf

在这里插入图片描述

第三步：

配置哨兵，填写内容

-- 打开 sentinel.conf 文件
vim sentinel.conf

-- 添加内容
sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1

在这里插入图片描述

上面最后一个数字 1，表示主机挂掉后 salve 投票看让谁接替成为主机，得票数多少后成为主机！

第四步：

启动哨兵

redis-sentinel /myredis/sentinel.conf

在这里插入图片描述

注：上述目录依照各自的实际情况配置，可能目录不同

接下来我们来看一下在哨兵模式下主机崩掉的效果

正常的状态

在这里插入图片描述

我们把6379redis给关掉，制造出服务器崩坏的效果

在这里插入图片描述

在来看刚才的sentinel.conf文件

在这里插入图片描述

因为主redis突然崩了，所以大家投票决定由6381作为新的主redis进行使用

在这里插入图片描述

我们使用 info replication 查看会更加的明显，这里可以直接看到，6381已经变成了master，而6380成为了6381的从redis。

接下来我们在来看一下如果后面6379有恢复了会是什么效果！

在这里插入图片描述

我们可以看到6379自动绑定到了6381，这是类似于一个老领导退休后又回来看看，但是现在已经有新领导了，所以老领导来了也得听新领导的！

PS：一组sentinel能同时监控多个Master

复制的缺点

复制延迟：

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

如果大家在测试的时候没有效果，那么可以暂时等一下，因为可能是因为延迟的原因!

扩展

Redis的发布订阅

介绍

进程间的一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接收消息。

订阅/发布消息图

在这里插入图片描述

例：我们使用微信的时候会关注一些公众号，在我们关注之后公众号就会给我们推送一些相关信息，而我们没有关注的时候它是不会给我们发的！

命令

在这里插入图片描述

案例

先订阅后发布后才能收到消息

可以一次性订阅多个，SUBSCRIBE c1 c2 c3
消息发布，PUBLISH c2 hello-redis

在订阅对应的频道之后，只要该频道发布新的信息，订阅的机器就可以获取到发布的信息，但是没有订阅的机器就接收不到发布的信息。
订阅多个，通配符， PSUBSCRIBE new

这里的 new 并不是固定的，大家也可以改成其他的，比如a、b、c之类的，但是一定要加上后面的 * 号！
收取消息， PUBLISH new1 redis2020

在发布的时候需要根据刚才订阅的格式进行发布，否则就不会获取到信息！