• Redis——分布式缓存


    一.Redis持久化
    1.RDB
    RDB全称Redis Database Backup file(Redis数据备份文件),也被叫做Redis数据快照。简单来说就是把内存中的所有数据记录到磁盘中。当Redis实例故障重启后,从磁盘读取快照文件,恢复数据。
    快照文件称为RDB文件,默认是保存到当前运行目录。
    在这里插入图片描述
    RDB执行命令有两种:使用save命令是利用主进程在对Redis进行持久化,因为Redis是一种单线程模式,这样的话会对阻塞所有命令,耗时时间长。不推荐使用。

    推荐使用bigsave命令对Redis进行持久化操作,bgsave开始时会fork主进程得到子进程,子进程共享主进程的内存数据。完成fork后读取内存中的数据并写入RDB文件。
    fork采用的是copy-on-write技术:

    • 当主进程执行读操作时,访问共享内存;
    • 当主进程执行写操作时,则会拷贝一份数据,执行写操作。
      在这里插入图片描述
      这也会有一种极端的情况发生:当数据进行RDB备份的时候,如果说读写速度很慢,会耗费一定的时间,而这段时间会有大量的请求来对数据进行更改,这样主进程就会不断的拷贝数据进行修改,此时内存就会是当前内存的2倍,所以在使用redis的时候需要预留出一部分内存,避免这种极端情况发生,否则就会造成内存溢出的现象。

    总结:
    RDB方式bgsave的基本流程?

    • fork主进程一个子进程,共享内存空间
    • 子进程读取内存数据并写入新的RDB文件
    • 用新的RDB文件替换旧的RDB文件

    RDB会在什么时候执行?save 60 1000代表什么含义?

    • 默认是服务停止时
    • 代表60秒内至少执行1000次修改才会才触发RDB

    RDB的缺点?

    • RDB执行间隔时间长,两次RDB之间写入数据有丢失的风险
    • fork子进程,压缩,写出RDB文件都比较耗时

    2.AOF持久化
    AOF全称Append Only File(追加文件)。Redis处理的每一个写命令都会记录在AOF文件,可以看做是命令日志文件。

    AOF默认是关闭的,需要修改redis.conf配置文件来开启AOF:
    在这里插入图片描述
    AOF的命令记录的频率也可以通过redis.conf文件来配:
    在这里插入图片描述
    因为是记录命令,AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作,但只有最后一次写操作才有意义。通过执行bgrewriteaof命令,可以让AOF文件执行重写功能,用最少的命令达到相同的效果。
    在这里插入图片描述
    Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置:
    在这里插入图片描述
    3.RDB与AOF
    在这里插入图片描述
    二、Redis主从集群
    1、搭建主从架构
    单节点Redis的并发能力是有上限的,要进一步提高Redis的并发能力,就需要搭建主从集群,实现读写分离。
    在这里插入图片描述
    使用一台虚拟机对集群进行模拟搭建:
    首先构造三个redis实例,端口号分别为7001(主)、7002(从)、7003(从),
    ①拷贝redis.config文件
    在这里插入图片描述
    ②修改每个实例的端口、工作目录
    在这里插入图片描述
    ③修改每个实例声明的ip
    在这里插入图片描述
    ④同时开启三个redis实例
    在这里插入图片描述
    ⑤开启主从关系
    在这里插入图片描述
    在这里插入图片描述
    查看集群状态信息
    在这里插入图片描述
    至此,主从集群搭建完成。

    总结:假设有A、B两个Redis实例,如何让B作为A的slave节点?

    • 在B节点中执行 slaveof A的IP A的端口号

    2、数据同步原理

    ①主从第一次同步是全量同步

    在这里插入图片描述
    master如何判断slave是不是第一次来同步数据?这里会用到两个很重要的概念:

    • Replication Id:简称replid,是数据集的标记,id一致则说明是同一数据集。每一个master都有唯一的replid,slave则会继承master节点的reolid
    • offset:偏移量,随着记录在repa_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset.如果slave的offset小于master的offset,说明slave数据落后于master,需要更新。
      因此slave做数据同步,必须向master声明自己的 Replication Idoffset,master才可以判断到底需要同步哪些数据。

    总结:
    简述全量同步的流程:

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

    ②增量同步
    在这里插入图片描述
    注意:repl_baklog大小实际上是一个数组的形式进行存储的,当数据达到上限的时候就会继续从零开始写入命令,把之前的命令进行覆盖。正因为repl_baklog大小有上限,写满后会覆盖最早的数据。如果slave断开时间太久,导致尚未备份你的数据被覆盖,则无法基于log做增量同步,只能再次全量同步。

    ③优化Redis主从集群

    • 在master中配置repl-diskless-sync yes启用无磁盘复制,避免全量同步时的磁盘IO.(使用这种方法的场景是需要网络带宽很大,网络非常快的情况下,如果网络很慢,也会造成网络阻塞)
    • Redis单节点上的内存占用不要太大,减少RDB导致的过多磁盘IO
    • 适当提高repl_baklog的大小,发现slave宕机时尽快实现故障恢复,尽可能避免全量同步
    • 限制一个master上的slave节点数量,如果实在是太多slave,则可以采用主-从-从链式结构,减少master压力
      也就是在从节点中将从节点设置为自己的master即可
      在这里插入图片描述
      总结:
      简述全量同步与增量同步的区别?
    • 全量同步:master将完整内存数据生成RDB,发送RDB到slave。后续命令则记录在repl_baklog中,逐个发给slave
    • 增量同步:slave提交自己的offset到master,master获取repl_baklog中从offset之后的命令给slave

    什么时候执行全量同步?

    • slave节点第一次连接master节点时
    • slave节点断开时间太久,repl_baklog中的offset已经覆盖时

    什么时候执行增量同步?

    • slave节点断开又恢复,并且在repl_baklog中能找到offset时

    思考:slave节点宕机恢复后可以找master节点同步数据,那master节点宕机怎么办?

    3、Redis哨兵
    ①哨兵的作用
    Redis提供了哨兵(Sentinel)机制来实现主从集群的自动故障恢复。哨兵的结构和作用如下:

    • 监控:Sentinel会不断检查您的master和slave是否按预期工作
    • 自动故障恢复:如果master故障,Sentinel会将一个slave提升为master。当付账实例恢复后也以新的master为主
    • 通知:Sentinel充当Redis客户端的服务发现来源,当集群发生故障转移是,会将最新信息推送给Redis的客户端
      在这里插入图片描述
      ②服务状态监控
      Sentinel基于心跳机制检测服务状态,每隔1秒向集群的每个实例发送ping命令:
    • 主观下线:如果sentinel节点发现某实例未在规定时间响应,则认为该实例主观下线。
    • 客观下线:若超过指定数量的Sentinel都认为改实例主观下线,则该实例客观下线。所指定的数量最好超过sentinel实例数量的一半。
      在这里插入图片描述
      ③选举新的master
      一旦发现master故障,sentinel需要在slave中选择一个作为新的master,选择依据是:
    • 首先会判断slave节点与master节点断开时间长短,如果超过指定值则会排除该slave节点
    • 然后判断slave节点的slave-priority值,越小优先级越高,如果是0则永不参与选举
    • 如果slave-priority一样,则判断slave节点的offset值,越大说明数据越新,优先级越高
    • 最后判断slave节点的运行id大小,越小优先级越高。

    4.搭建哨兵集群
    目标:创建三个Sentinel实例去监控上面创建的三个节点的集群

    ①准备实例和配置
    在这里插入图片描述
    在这里插入图片描述

    在这里插入图片描述
    虽然只是与主节点建立监控连接了,但是可以间接通过主节点去获取其他从节点的信息。

    在这里插入图片描述
    ②启动
    在这里插入图片描述
    在这里插入图片描述
    通过查看日志可以发现已经成功开始监控集群
    在这里插入图片描述

    ③测试主节点宕机,从节点选举为主节点
    在这里插入图片描述
    此时7002执行成为主节点的命令,广播告诉其他节点自己成为主节点,其他节点就会修改自己的配置文件,将7002作为自己的主节点(下图为7003的从节点)
    在这里插入图片描述
    如果将已经宕机的7001进行恢复的话,7002就会收到7001尝试进行同步的请求。并且进行数据同步,7001同时将7002设置成自己的主节点。
    在这里插入图片描述
    5、Redis分片集群

    分片集群的结构
    主从和哨兵可以解决高可用,高并发读的问题,但是依然有两个问题没有解决:

    • 海量数据存储问题
    • 高并发写的问题

    使用分片集群可以解决上述问题,分片集群特征:

    • 集群中有多个master,每个master保存不同数据
    • 每个master都可以有多个slave节点
    • master之间通过ping监测彼此健康状态
    • 客户端请求可以访问集群任意节点,最终都会被转发到正确节点

    在这里插入图片描述

    在这里插入图片描述

    总结:
    在这里插入图片描述

    例如控制有效位为a,则插入的数据就会在一个插槽中,从而在一个节点中
    在这里插入图片描述

    集群伸缩
    eg:添加一个节点到集群
    在这里插入图片描述

  • 相关阅读:
    YOLO目标检测——谢韦尔钢材缺陷检测数据集下载分享【含对应voc、coco和yolo三种格式标签】
    Flask入门学习教程
    Java学习笔记(三十六)
    【Leetcode每日一题:1662.检查俩个字符串数组是否相等~~~遍历+模拟+StringBuilder】
    Nacos——注册中心源码详解
    【性能测试】Jenkins+Ant+Jmeter自动化框架的搭建思路
    文件管理系统概述
    MYSQL下载及安装完整教程
    SpringBoot 统一异常处理
    今天是七夕,来看看程序员的土味情话。
  • 原文地址:https://blog.csdn.net/xiaowanziddd/article/details/125485670