Redis升级——Redis主从结构

云计算 专栏收录该内容
7 篇文章 0 订阅

Redis升级——Redis主从结构

沉寂好久的小咸鱼又回来了。经过了很长一段时间的找工作的过程,终于要尘埃落定了,目前收到的offer数量已经足够挑选了,接下来就是我来挑工作了,哈哈哈。这个结果自己也是比较满意的,但是挑选哪种工作现在也是让人有点头疼啊,毕竟是要决定一生走向的,所以不能有一点的马虎。当然了,这些和我的文章没有关系。
这两个月的笔试面试经历着实让我见识到了自己的很多的不足之处,也有了很多的收获,我会一点点总结发出来,供大家学习,也希望大家不要走我的老路。
现在,开始今天的内容。
redis的复制时redis中必不可少的一部分,它和redis集群、哨兵息息相关,所以需要简单的了解一下。今天就介绍一下如何搭建一个简单的主从结构,并且原理是怎么样的。

Redis的复制

打开虚拟机以后,首先查询IP地址(有用),是192.168.31.9
在这里插入图片描述
因为我的redis设置的是开机自动启动,(具体的设置方法可以上网查看,只要更改配置文件的一个参数即可。)所以开机以后自动启动redis并且端口为6379。
接下来,我们需要在开一个端口:6380,如下图所示:
在这里插入图片描述
启动完成以后,再开两个命令端,来启动两个客户端:
在这里插入图片描述
这时候,在6380的一个输入命令,让它作为6379的从数据库:
在这里插入图片描述
查看两个redis的状态:
在这里插入图片描述
在这里插入图片描述
可以看到6380的状态是从数据库,6379的状态是主数据库,接下来可以尝试在主数据库中设置键值并在从数据库中完成查询。
在这里插入图片描述
这样一个简单的主从数据库的设置就完成了。

redis数据库复制原理

从数据库启动以后,会向主数据库发送一个sync命令。同时主数据库接收到sync命令以后会开始在后台保存快照(RDB持久化过程)并将保存快照期间的命令缓存起来。当快照完成以后,redis会将快照文件和所有的缓存的命令发送给从数据库。从数据库收到后,会载入快照文件并执行收到的命令。以上过程称为复制的初始化。
复制初始化结束以后,主数据库每当收到写命令时就会将命令同步给从数据库,从而保证主从数据库数据一致。

当主从数据库之间的连接断开后重连后,redis2.6及以前的版本就会重新的进行复制的初始化(即主数据库重新保存快照并传输给从数据库)即使从数据库可以仅有几条命令没有收到,数据库也必须要将数据库里的所有的数据重新的发送给从数据库。这使得主从数据库断开之后的重连的数据恢复效率低下,在网络不好的时候更是如此。
redis2.8以后的版本的一个重要的改进就是断线重连能够支持有条件的增量数据传输,当从数据库重新连接上主数据库以后,主数据库只需要将断线期间执行的命令传输给从数据库就行,从而大大提高了redis的实用性

模拟redis的复制过程

这里需要使用telnet工具,使用如下图所示:
在这里插入图片描述
依次输入
replconf listening-port 6381
sync
即可完成同步过程,后面的内容就是同步的数据。
在这里插入图片描述
可以看到已经可以查询到主数据库的内容,该过程就已经展示了redis主从数据库的同步过程。

增量复制

接下来总结一下Redis2.8版本以后的增量复制过程
增量复制的实现有三个前提:
(1)从数据库会存储主数据库的运行ID(run id)。每个Redis运行实例都会拥有一个唯一的运行ID,每当实例重启以后,就会自动生成一个新的运行ID;
(2)在复制同步阶段,主数据库每将一个命令传输到主数据库传送给从数据库的时候,都会把命令存放在一个积压队列中,并且记录下当前积压队列中存放的命令的偏移量;
(3)从数据库接收到主数据库传来的命令时,会记录下该命令的偏移量。
这三点是实现增量复制的基础。当主从连接准备就绪以后,从数据库会发送一条SYNC命令来告诉主数据库可以开始把所有的数据同步过来。而2.8版本以后,不再发送SYNC命令,取而代之的是发送PSYNC,格式为 :
“PSYNC 主数据库的运行ID 断开前最新的命令偏移量”
主数据库收到命令以后,会执行以下判断来决定此次重连是否可以执行增量复制。

  • 判断从数据库传送来的运行ID是否和自己的运行ID相同。这一步骤的意义在于确保从数据库之前确实是和自己同步的,以免从数据库拿到错误的数据库(比如主数据库在断线期间重启过,会造成数据的不一致);
  • 判断从数据库最后同步成功的命令偏移量是否在积压队列中,如果在则可以执行增量复制,并将积压队列中相应的命令发送给从数据库。

如果此次重连不满足增量复制的条件,主数据库会进行一次全部的同步。
积压队列默认长度是1MB,可以通过repl-backlog-size来设置;
另一个相关配置是repl-backlog-ttl,为当所有的从数据库与主数据库断开连接以后,经过多长时间可以释放积压队列的内存空间,默认是1小时。
在这里插入图片描述

乐观复制

Redis采用了乐观复制的复制策略,容忍一段时间内主从数据库的内容是不同的,但是两者的数据最终会同步。具体来说,redis在主从数据库之间的复制数据的过程是异步的,这意味着,主从数据库执行完客户端请求的命令后会立即将命令在主数据库的执行结果返回给客户端,并异步地将命令同步给从数据库,而不会等待从数据库接收到命令后再返回给客户端。这一特性保证了启用复制后主数据库的性能不会受到影响,但另一方面也会产生一个主从数据库数据不一致的时间窗口,当主数据库执行了一条写命令以后,主数据库的数据已经发生了变动,然而在数据库将该命令传送给从数据库之前,如果两个数据库之间的网络连接断开了,此时二者之间的数据就会是不一致的。
Redis提供了两个配置选项来限制只有当数据至少同步给指定数量的从数据库时,主数据才是可写的:
min-slaves-to-write 3
min-slaves-max-lag 10
表示只有当3个或者3个以上的从数据库连接到主数据库时主数据库才是可写的
即当连接的从数据库数量少于三个的时候,主数据库是不可写的。
以及允许从数据库最长的失去连接的时间(10s)
在这里插入图片描述

手动恢复数据库数据

数据库的持久化比较耗时,为了提高性能,可以通过复制功能建立一个从数据库,并在从数据库中启用持久化,同时在主数据库禁用持久化。当从数据库崩溃以后,主数据库会自动将数据同步过来,所以无需担心数据丢失。
然而当主数据库崩溃以后,手动从从数据库恢复主数据库数据时,需要严格按照以下两步进行:
1、在从数据库中使用slaveof no one命令将从数据库提升至主数据库继续服务;
2、启动之前崩溃的主数据库,然后使用slaveof 命令将其设置成为新的主数据库的从数据库,即可将数据同步回来。
注意:一定不能将主数据库自动的重启,一旦重新启动,主数据库会因为没有启用持久化造成所有数据被清空,这时从数据库依然会从主数据库中接受数据,使得所有的从数据库也被清空,导致从数据库的持久化失去意义。

当然现实中一直使用手动恢复是不可能的,这就需要redis的另外的一种模式,哨兵模式来辅助完成redis恢复过程,当然这是下一篇的内容了,今天的内容就到这里,如有不当之处,还望大家多多指教。小咸鱼再次谢过各位大佬啦!

  • 1
    点赞
  • 0
    评论
  • 1
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值