Redis进阶

已于 2023-07-01 19:46:58 修改
阅读量1.5k 收藏 5
点赞数 1
分类专栏： 微服务 文章标签： redis 缓存 数据库
于 2023-05-16 16:53:07 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_47910339/article/details/130709141
版权

主要内容

  • Redis持久化
  • Redis主从
  • Redis哨兵
  • Redis分片集群

Redis持久化

Redis有两种持久化的方案:

  1. RDB持久化
  2. AOF持久化
1. RDB持久化

RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前运行目录。RDB也是redis的默认策略

下面的执行时机先有一个大致的印象:

RDB持久化在四种情况下会执行：

  • 执行save命令
  • 执行bgsave命令
  • Redis停机时
  • 触发RDB条件时
1. save命令

前言: 在Redis中网络请求模块和数据操作模块是单线程的

而其他的如持久化存储模块、集群支撑模块等是多线程的

对于该命令可以在连接redis之后手动的执行save命令

在这里插入图片描述

也正是因为redis的对于请求的处理是单线程模式,而save命令是主线程所执行的所以在执行此命令时,主线程就会处于一个阻塞的状态,极大的影响redis的性能.

2. bgsave命令

在这里插入图片描述

这个命令执行后会开启独立进程完成RDB，主进程可以持续处理用户请求，不受影响。如下

3. 停机时

Redis停机时会执行一次save命令，实现RDB持久化。

在这里插入图片描述

4.触发RDB的条件

Redis内部有触发RDB的机制，可以在redis.conf文件中找到，格式如下：

# 900 秒内，如果至少有1个key被修改，则执行bgsave ， 如果是save "" 则表示禁用RDB
save 900 1  
save 300 10  
save 60 10000

RDB的其它配置也可以在redis.conf文件中设置：

# 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱
rdbcompression yes

# RDB文件名称
dbfilename dump.rdb  

# 文件保存的路径目录
dir ./
2. RDB原理

这里先介绍Redis中默认使用的bgsave命令持久化内存的数据.

fork----> 创建子进程来进行RDB操作)

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。

在操作系统中不允许进程直接操作数据,而是通过页表来间接操作数据

那么在fork操作之后就可以通过拷贝页表 让子进程通过操作页表进而来操作内存中数据

在这里插入图片描述

那么问题来了,如果子进程在进行RDB操作的时候主进程又有新的读写操作的时候该怎么办呢?如下

fork采用的是copy-on-write技术：

  • 当主进程执行读操作时，访问共享内存；
  • 当主进程执行写操作时，则会拷贝一份数据，执行写操作。(原本的数据设置为read-only)

注意: 此时理论上就有一个极端的情况,(因为I/O操作的数据相对于内存十分的slow~~),所以就存在 在子进程进行RDB操作的时候,新的请求对原本的数据全部修改了一遍,此时主进程就会把所有的数据拷贝一次,此时如果原始在内存中文件的大小为4G,此时占用内存的大小就会翻倍,甚至更高,当然这只是一个极端的情况.

所以我们一般会留出一些内存,防止类似的情况出现

小结

RDB方式bgsave的基本流程？

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

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

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

RDB的缺点？

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

AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

1. AOF配置

AOF默认是关闭的，需要修改redis.conf配置文件来开启AOF：

# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"

AOF的命令记录的频率也可以通过redis.conf文件来配：

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always 
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec 
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

在这里插入图片描述

如果留心上面有一句话: Redis处理的每一个写命令都会记录在AOF文件

那么如果有下面的命令同样也会对命令依次的记录

set name zs
set name ls
set name ww
set name jack
set name pick
set name black

这里操作了数条命令后面执行了删除命令,那不是白执行了,那么有没有什么对命令优化的方案呢?

此外因为是记录命令，AOF文件会比RDB文件大的多。而且AOF会记录对同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

在使用bgrewriteaof,就可以把上面的命令优化为类似 set name black 的语句

当然redis也提供了配置文件的方式来触发bgrewriteaof操作

# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用。

3. RDB与AOF对比

在这里插入图片描述

Redis主从架构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FEIGWCvC-1684226612566)(C:\Users\57589\AppData\Roaming\Typora\typora-user-images\image-20230515223254420.png)]

如何搭建这样的架构, 常用的有两种方式,

方式一: 修改配置文件（永久生效）

在redis.conf中添加一行配置：slaveof <masterip> <masterport>

方式二: 通过slaveof 命令,(重启失效)

# 执行slaveof 
slaveof 192.168.150.101 7001
主从架构中数据同步的原理

在数据同步中根据不同的时期分为: 全量同步和增量同步,下面依次介绍

全量同步

在这里插入图片描述

这里有一个问题，master如何得知salve是第一次来连接呢？？

有几个概念，可以作为判断依据：

  • Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid
  • offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

因此slave做数据同步，必须向master声明自己的replication id 和offset，master才可以判断到底需要同步哪些数据。

因为slave原本也是一个master，有自己的replid和offset，当第一次变成slave，与master建立连接时，发送的replid和offset是自己的replid和offset。

master判断发现slave发送来的replid与自己的不一致，说明这是一个全新的slave，就知道要做全量同步了。

master会将自己的replid和offset都发送给这个slave，slave保存这些信息。以后slave的replid就与master一致了。

因此，master判断一个节点是否是第一次同步的依据，就是看Replicationid是否一致。

如图：

在这里插入图片描述

完整流程描述：

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

全量同步需要先做RDB，然后将RDB文件通过网络传输到slave，成本太高了。因此除了第一次做全量同步，其它大多数时候slave与master都是做增量同步。

什么是增量同步？就是只更新slave与master存在差异的部分数据。如图：

在这里插入图片描述

那么master怎么知道slave与自己的数据差异在哪里呢?

repl_backlog原理

这就要说到全量同步时的repl_baklog文件了。

这个文件是一个固定大小的数组，只不过数组是环形，也就是说角标到达数组末尾后，会再次从0开始读写，这样数组头部的数据就会被覆盖。

repl_baklog中会记录Redis处理过的命令日志及offset，包括master当前的offset，和slave已经拷贝到的offset：

在这里插入图片描述

slave与master的offset之间的差异，就是salve需要增量拷贝的数据了。

随着不断有数据写入，master的offset逐渐变大，slave也不断的拷贝，追赶master的offset：

在这里插入图片描述

直到数组被填满：

在这里插入图片描述

此时，如果有新的数据写入，就会覆盖数组中的旧数据。不过，旧的数据只要是绿色的，说明是已经被同步到slave的数据，即便被覆盖了也没什么影响。因为未同步的仅仅是红色部分。

但是，如果slave出现网络阻塞，导致master的offset远远超过了slave的offset：

在这里插入图片描述

如果master继续写入新数据，其offset就会覆盖旧的数据，直到将slave现在的offset也覆盖：

在这里插入图片描述

棕色框中的红色部分，就是尚未同步，但是却已经被覆盖的数据。此时如果slave恢复，需要同步，却发现自己的offset都没有了，无法完成增量同步了。只能做全量同步。

在这里插入图片描述

主从同步优化

主从同步可以保证主从数据的一致性，非常重要。

可以从以下几个方面来优化Redis主从集群：

  • 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO。
  • Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
  • 适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
  • 限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少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时

哨兵机制

哨兵原理

在这里插入图片描述

哨兵的作用如下：

  • 监控：Sentinel 会不断检查您的master和slave是否按预期工作
  • 自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主
  • 通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端
集群监控原理

Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令：

•主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。

•客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

集群故障恢复原理

一旦发现master故障，sentinel需要在salve中选择一个作为新的master，选择依据是这样的：

  • 首先会判断slave节点与master节点断开时间长短，如果超过指定值（down-after-milliseconds * 10）则会排除该slave节点
  • 然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举
  • 如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高
  • 最后是判断slave节点的运行id大小，越小优先级越高。

当选出一个新的master后，该如何实现切换呢？

流程如下：

  • sentinel给备选的slave1节点发送slaveof no one命令，让该节点成为master
  • sentinel给所有其它slave发送slaveof 192.168.150.101 7002 命令，让这些slave成为新master的从节点，开始从新的master上同步数据。
  • 最后，sentinel将故障节点标记为slave，当故障节点恢复后会自动成为新的master的slave节点

小结

Sentinel的三个作用是什么？

  • 监控
  • 故障转移
  • 通知

Sentinel如何判断一个redis实例是否健康？

  • 每隔1秒发送一次ping命令，如果超过一定时间没有相向则认为是主观下线
  • 如果大多数sentinel都认为实例主观下线，则判定服务下线

故障转移步骤有哪些？

  • 首先选定一个slave作为新的master，执行slaveof no one
  • 然后让所有节点都执行slaveof 新master
  • 修改故障节点配置，添加slaveof 新master

在java代码中的配置

引入依赖

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

配置Redis地址

指定哨兵的地址的即可,因为可以通过哨兵找到所有的节点

spring:
  redis:
    sentinel:
      master: mymaster
      nodes:
        - 192.168.150.101:27001
        - 192.168.150.101:27002
        - 192.168.150.101:27003

配置读写分离

@Bean
public LettuceClientConfigurationBuilderCustomizer clientConfigurationBuilderCustomizer(){
    return clientConfigurationBuilder -> clientConfigurationBuilder.readFrom(ReadFrom.REPLICA_PREFERRED);
}

这个bean中配置的就是读写策略，包括四种：

  • MASTER：从主节点读取
  • MASTER_PREFERRED：优先从master节点读取，master不可用才读取replica
  • REPLICA：从slave（replica）节点读取
  • REPLICA _PREFERRED：优先从slave（replica）节点读取，所有的slave都不可用才读取master(常用)

Redis分片集群

主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决：

  • 海量数据存储问题

  • 高并发写的问题

使用分片集群可以解决上述问题，如图:

分片集群特征：

  • 集群中有多个master，每个master保存不同数据

  • 每个master都可以有多个slave节点

  • master之间通过ping监测彼此健康状态

  • 客户端请求可以访问集群任意节点，最终都会被转发到正确节点

散列插槽
插槽原理

Redis会把每一个master节点映射到0~16383共16384个插槽（hash slot）上，查看集群信息时就能看到：

注意: 每个插槽可以有多个数据

数据key不是与节点绑定，而是与插槽绑定。redis会根据key的有效部分计算插槽值，分两种情况：

  • key中包含"{}"，且“{}”中至少包含1个字符，“{}”中的部分是有效部分
  • key中不包含“{}”，整个key都是有效部分

例如：key是num，那么就根据num计算，如果是{itcast}num，则根据itcast计算。计算方式是利用CRC16算法得到一个hash值，然后对16384取余，得到的结果就是slot值。

如图，在7001这个节点执行set a 1时，对a做hash运算，对16384取余，得到的结果是15495，因此要存储到103节点。

到了7003后，执行get num时，对num做hash运算，对16384取余，得到的结果是2765，因此需要切换到7001节点

小结

Redis如何判断某个key应该在哪个实例？

  • 将16384个插槽分配到不同的实例
  • 根据key的有效部分计算哈希值，对16384取余
  • 余数作为插槽，寻找插槽所在实例即可

如何将同一类数据固定的保存在同一个Redis实例？

  • 这一类数据使用相同的有效部分，例如key都以{typeId}为前缀
集群伸缩

redis-cli --cluster提供了很多操作集群的命令，可以通过下面方式查看：

比如，添加节点的命令：

通过两个案例来实现集群的伸缩

需求：向集群中添加一个新的master节点

  • 启动一个新的redis实例，端口为7004

  • 添加7004到之前的集群，并作为一个master节点

这里需要两个新的功能：

  • 添加一个节点到集群中
  • 将部分插槽分配到新插槽

1: 添加新节点

redis-cli --cluster add-node  192.168.150.101:7004 192.168.150.101:7001

查看集群的状态

redis-cli -p 7001 cluster nodes

如图，7004加入了集群，并且默认是一个master节点：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WgzPPZ3x-1684226612571)(E:\a_黑马课程\09_微服务高级\day01-分布式缓存\讲义\md\assets\image-20210725161007099.png)]

但是，可以看到7004节点的插槽数量为0，因此没有任何数据可以存储到7004上

转移插槽

我们可以将0~3000的插槽从7001转移到7004，命令格式如下：

3.1 建立连接：

得到下面的反馈：

询问要移动多少个插槽，我们计划是3000个：

指定节点服务的id

在这里插入图片描述

复制这个id，然后拷贝到刚才的控制台后：

在这里插入图片描述

这里询问，你的插槽是从哪里移动过来的？

  • all：代表全部，也就是三个节点各转移一部分
  • 具体的id：目标节点的id
  • done：没有了

这里我们要从7001获取，因此填写7001的id：

在这里插入图片描述

填完后，点击done，这样插槽转移就准备好了：

在这里插入图片描述

确认要转移吗？输入yes：

然后，通过命令查看结果：

在这里插入图片描述

可以看到：

在这里插入图片描述

故障转移

集群初始状态是这样的：

其中7001、7002、7003都是master，我们计划让7002宕机。

自动故障转移

当集群中有一个master宕机会发生什么呢？

直接停止一个redis实例，例如7002：

在这里插入图片描述

手动故障转移

从机上利用cluster failover命令可以手动让集群中的某个master宕机，切换到执行cluster failover命令的这个slave节点，实现无感知的数据迁移。其流程如下：

这种failover命令可以指定三种模式：

  • 缺省：默认的流程，如图1~6歩
  • force：省略了对offset的一致性校验
  • takeover：直接执行第5歩，忽略数据一致性、忽略master状态和其它master的意见

缓存穿透:

缓存穿透: 查询一个不存在的数据,mysql查询不到数据也不会直接写入缓存,就会导致每次请求都查数据库,而数据库的承受并发的能力是有限的

方案一: 缓存空数据: 如果查不到就返回空的数据, 仍然把这个空结果进行缓存( 优点: 简单  确定: 消耗内存)
方案二: 采用布隆过滤器 底层使用的bitmap 通过对当前的key,进行三次Hash计算,模以数组的大小,得到在数组中的位置,然后将三个位置的值改为1其中会存在误判率,数组越小误判率就越大( 其实好像跟,Hash冲突一样), 数组越大误判率就越小,但是同时带来了更多的内存消耗
（优：内存占用较少,没有多余的key   缺: 实现复杂,存在误判）
一般设置为百分之五以内

布隆过滤器的实现: Redisson 或者 Guava

    @PostMapping("/addUser")
    public Integer insert(@RequestBody MUser user) {
 
        RBloomFilter<String> bloomFilter
                = redisson.getBloomFilter(Constant.REDISSON_BLOOMFILTER_USER);
        //布隆过滤器计算的正确率为97%，初始化布隆过滤器容量为50000L
        bloomFilter.tryInit(500000L,0.03);
        if (bloomFilter.contains(user.getName())) {
            throw new InvalidArgumentException("用户名:" + user.getName() + "已经存在");
        }
 
        user.setId(null);
        int res = userMapper.insertSelective(user);
        if (res > 0) {
            //加入布隆过滤器
            bloomFilter.add(user.getName());
        }
        return user.getId();
    }

最终解决方案:

缓存预热通过实现 InitalizingBean 接口实现aftterPropertieSet方法

缓存预热案例如下： 也可以通过管道实现，尤其对于批量数据的导入。

@Override
    public void afterPropertiesSet() throws Exception {
        // 初始化缓存
        // 1.查询商品信息
        List<Item> itemList = itemService.list();
        // 2.放入缓存
        for (Item item : itemList) {
            // 2.1.item序列化为JSON
            String json = MAPPER.writeValueAsString(item);
            // 2.2.存入redis
            redisTemplate.opsForValue().set("item:id:" + item.getId(), json);
        }
 
        // 3.查询商品库存信息
        List<ItemStock> stockList = stockService.list();
        // 4.放入缓存
        for (ItemStock stock : stockList) {
            // 2.1.item序列化为JSON
            String json = MAPPER.writeValueAsString(stock);
            // 2.2.存入redis
            redisTemplate.opsForValue().set("item:stock:id:" + stock.getId(), json);
        }
    }

缓存击穿:

缓存穿透: 给某一个key设置了过期时间，当key过期的时候，恰好这时间点对这个key有大量的并发请求过来，这些并发的请求可能会瞬间把DB压垮

解决方案: 
(1): 使用互斥锁
线程1 查询缓存未命中,此时就去获取分布式锁, 查询数据库, 重建缓存数据, 写入缓存
线程2 同时来了之后,查询缓存,未命中, 加锁, 失败,重试

(2): 逻辑过期
那么为什么不把数据设置为永不过期呢?
如果设置永不过期，你不知道现在缓存数据是不是最新的，你得有一个过期时间来触发去数据库刷新最新数据到缓存中
1. 设置多级缓存
2. 对于一些热点数据不设置过期时间
3. 通过分布式锁(当发现缓存没有命中时,首先去拿到分布式锁,再去数据库中查询,并将数据添加到缓存中)
4. 布隆过滤器(防止一些恶意请求的key)

缓存雪崩

首先注意缓存击穿和缓存雪崩的区别: 前者是一个热点key过期导致大量的请求到db, 后者是同一时间大量的key过期,导致大量的请求到db

缓存雪崩: 缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。 
缓存击穿: 通常针对同一个key过期，大量并发访问同一个key失败，造成数据压力过大

解决方案:
1. 给不同的key的ttl 添加随机值
2. 利用Redis集群提高服务的可用性  : (哨兵, 集群)
3. 给缓存业务添加降级限流策略     : Nginx 或者 spring CLoud gateway (降级策略可)
4. 给业务添加多级缓存		    : Caffeine或Guava

穿透无中生有key, 布隆过滤Null隔离               ----直接过滤掉布隆过滤器中没有key
缓存击穿过期key, 锁与非期解难题
雪崩大量过期key, 过期时间要随机
面试必考三兄弟, 可用限流做保底

🚩 双写一致性

当修改了数据库的数据也要同时更新缓存的数据,缓存和数据的数据要保持一致

先删缓存还是先修改数据库

读操作: 缓存命中,直接返回; 缓存未命中查询数据库, 写入缓存,设定超时时间

写操作: 延迟双删

为什么要使用延迟双删呢?

是这样的: 按照之前的逻辑, 先删除缓存再操作数据库, 线程1 把缓存删了, 线程2 来了,此时在查缓存未命中,虽然查询数据库,然后写入redis, 然后线程1 再更新数据库, 此时导致 redis的数据库是10, 数据库中是20

如果是先更新数据库,然后再删除缓存, 此时也有问题, 比如线程1,先查询缓存,发现缓存中没有数据, 然后查询数据库,此时线程2 来了更新数据库,然后删除缓存.此时线程1把刚才查到的数据填入缓存,即redis是10, 数据库中是20

但是我们一般不会使用延迟双删的策略, 因为一般这个延迟的时间控制不了. 如果前一个线程还没有执行完, 我们已经把数据删除给删除了,即会出现我们这边刚把数据删除, 那边线程把数据又给读到redis中, 导致数据不一致

此时可以使用读写锁: 读多写少, (保证了强一致性, 但是性能较低) 读的时候采用共享锁,写的时候使用排它锁

即: 在读的时候采用共享锁, 在写的时候对读的代码以及写的代码都实现排它锁(独享锁).

在这里插入图片描述

常用两种方案: 一致性要求高, 允许延迟一致

一致性要求高 CP

示意代码

允许延迟一致 AP

通过Mq异步的通知数据的修改(允许暂时的不一致, 但是会最终一致)

也可以使用 canal

canal，译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费。

canal的工作原理就是把自己伪装成MySQL slave，模拟MySQL slave的交互协议向MySQL Mater发送 dump协议，MySQL mater收到canal发送过来的dump请求，开始推送binary log给canal，然后canal解析binary log，再发送到存储目的地，比如MySQL，Kafka，Elastic Search等等。

Redis的过期策略

惰性删除
惰性删除: 设置该key过期时间后，我们不去管它，当需要该key时，我们在检查其是否过期，如果过期，我们就删掉它，反之返回该key

优点 ：对CPU友好，只会在使用该key时才会进行过期检查，对于很多用不到的key不用浪费时间进行过期检查

缺点 ：对内存不友好，如果一个key已经过期，但是一直没有使用，那么该key就会一直存在内存中，内存永远不会释放

定期删除
定期删除: 每隔一段时间，我们就对一些key进行检查，删除里面过期的key(从一定数量的数据库中取出一定数量的随机key进行检查，并删除其中的过期key)。

定期清理有两种模式：

SLOW模式
 SLOW模式是定时任务，执行频率默认为10hz，每次不超过25ms，以通过修改配置文件redis.conf 的hz 选项来调整这个次数
FAST模式
FAST模式执行频率不固定，但两次间隔不低于2ms，每次耗时不超过1ms

优点：可以通过限制删除操作执行的时长和频率来减少删除操作对 CPU 的影响。另外定期删除，也能有效释放过期键占用的内存。

缺点：难以确定删除操作执行的时长和频率。

(3) 定时删除 即按照规定的时间, 删除, 十分消耗CPU资源一般不采用

Redis 的过期删除策略：惰性删除 + 定期删除两种策略进行配合使用

redis 的淘汰策略

数据的淘汰策略: 当Redis中的内存不够用时，此时在向Redis中添加新的key，那么Redis就会按照某一种规则将内存中的数据删除掉，这种数据的删除规则被称之为内存的淘汰策略。

Redis支持8种不同策略来选择要删除的key：

主要分为两种, 第一种是对设置了ttl的key, 第二种是对所有

noeviction： 不淘汰任何key，但是内存满时不允许写入新数据，默认就是这种策略。

volatile-ttl： 对设置了TTL的key，比较key的剩余TTL值，TTL越小越先被淘汰

allkeys-random：对全体key ，随机进行淘汰。

volatile-random：对设置了TTL的key ，随机进行淘汰。

allkeys-lru： 对全体key，基于LRU算法进行淘汰

volatile-lru： 对设置了TTL的key，基于LRU算法进行淘汰

allkeys-lfu： 对全体key，基于LFU算法进行淘汰

volatile-lfu： 对设置了TTL的key，基于LFU算法进行淘汰

LRU（Least Recently Used）最近最少使用:   用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。
LFU（Least Frequently Used）最少频率使用: 会统计每个key的访问频率，值越小淘汰优先级越高。
数据淘汰策略建议

1.优先使用 allkeys-lru 策略。充分利用 LRU 算法的优势，把最近最常访问的数据留在缓存中。如果业务有明显的冷热数据区分，建议使用。

2.如果业务中数据访问频率差别不大，没有明显冷热数据区分，建议使用 allkeys-random，随机选择淘汰。

3.如果业务中有置顶的需求，可以使用 volatile-lru 策略，同时置顶数据不设置过期时间，这些数据就一直不被删除，会淘汰其他设置过期时间的数据。

4.如果业务中有短时高频访问的数据，可以使用 allkeys-lfu 或 volatile-lfu 策略。

平时开发过程中用的比较多的就是allkeys-lru（结合自己的业务场景）

Redis分布式锁

什么场景下使用呢?

需要结合项目中的业务进行回答，通常情况下，分布式锁使用的场景: 集群情况下的单机定时任务、抢单、幂等性场景

xxl-job 分布式锁 + 单机定时任务

setnx 命令
  1. 首先要避免死锁, 因为方式获取锁的实例宕机 可以通过设置过期时间
  2. 锁的过期时间设置多长合适, 如果太短的话,业务还没有执行完就释放了锁, 依然会出现并发超卖问题 使用看门狗续期
Redisson

  • 原子性问题：可以利用Redis的LUA脚本来编写锁操作，确保原子性

  • 超时问题：利用WatchDog（看门狗）机制，获取锁成功时开启一个定时任务，在锁到期前自动续期，避免超时释放。而当服务宕机后，WatchDog跟着停止运行，不会导致死锁。

  • 锁重入问题：可以模拟Synchronized原理，放弃setnx，而是利用Redis的Hash结构来记录锁的持有者以及重入次数，获取锁时重入次数+1，释放锁是重入次数-1，次数为0则锁删除

  • 主从一致性问题：可以利用Redis官网推荐的RedLock机制来解决

    此时有个问题,对于集群模式如果获得到了主节点的锁, 但是主节点挂了, 此时就会产生一个新的主节点, 别的线程就可以获取到新的主节点中的锁, 那么就会有两把锁,这该怎么办???

    使用红锁, 也就是说如果是集群的话,如果能获得到多个节点的锁(n / 2 + 1) 才算是获得成功

在这里插入图片描述

每隔(releaseTime / 3)的时间做一次续期 releaseTime (释放时间): 获取锁的第一个参数

Redis集群的思想是AP思想,采用的是高可用性. 如果必须要求数据的强一致性可以使用zookeeper

在这里插入图片描述

红锁的缺点: 实现复杂, 性能差, 运维繁琐

🚩 redis管道技术

不要在一次批处理中传输太多命令，否则单次命令占用带宽过多，会导致网络阻塞

🚩 redis管道技术 在某些高并发的场景下，网络开销成了Redis速度的瓶颈，所以需要使用管道技术来实现突破。

原始:

在这里插入图片描述

学习网址: redis使用管道(Pipelining)提高查询速度

@Override
public Set<Long> isBizLiked(List<Long> bizIds) {
    // 1.获取登录用户id
    Long userId = UserContext.getUser();
    // 2.查询点赞状态   --- 使用管道查询
    List<Object> objects = redisTemplate.executePipelined((RedisCallback<Object>) connection -> {
        StringRedisConnection src = (StringRedisConnection) connection;
        for (Long bizId : bizIds) {
            String key = RedisConstants.LIKES_BIZ_KEY_PREFIX + bizId;
            src.sIsMember(key, userId.toString());
        }
        // 这里不用管
        return null;
    });
    // 3.返回结果
    return IntStream.range(0, objects.size()) // 创建从0到集合size的流
            .filter(i -> (boolean) objects.get(i)) // 遍历每个元素，保留结果为true的角标i
            .mapToObj(bizIds::get)// 用角标i取bizIds中的对应数据，就是点赞过的id
            .collect(Collectors.toSet());// 收集
}
yfs1024
关注
  • 1
    点赞
  • 踩
  • 5
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 2
    评论
专栏目录
Redis进阶（深度历险）
01-23
本进阶教程“Redis深度历险”旨在帮助读者深入理解Redis的核心特性和应用场景，从而更好地利用它来提升应用的性能和效率。 1. **Redis的数据结构** - 字符串(Strings)：最基础的数据类型，可存储任意长度的字符串...
Redis进阶实践之十四 Redis-cli命令行工具使用详解第一部分.md
最新发布
06-11
### Redis进阶实践之十四 Redis-cli命令行工具使用详解（第一部分） 这份资源详细介绍了 Redis 的命令行工具 Redis-cli 的使用方法和相关实践技巧。Redis-cli 是 Redis 提供的一个命令行客户端工具，用于与 Redis ...
redis 主从同步、集群、持久化
LeoHan
02-13 1284
redis有两种方式实现持久化：RDB和AOF AOF：类似数据库WAL 机制，但是redis是先执行命令，然后在记录AOF日志，是一种写后日志而不是咱们常说的写前日志（这样做主要是为了redis在写入日志之前不会对命令进行语法检查，只记录成功的命令，避免了出现记录错误命令的情况，并且命令执行完之后在记录不会阻塞当前的写操作，但是这样也会带来风险：数据可能丢失（执行完命令宕机）、可能阻塞其他他操作（AOF日志需要写磁盘）） 另外，如果运行时间较长，AOF日志比较快，在重启恢复的时候，较大的AOF会导致恢复较
Centos7 设置每5分钟同步系统时间
u010887012的博客
01-20 516
在我们本地电脑使用的虚拟机中，经常电脑睡眠导致系统时间总是不正确，从而导致应用程序的时间不正确。如果显示激活状态就不用执行下面操作了，否则进行安装启动。下面简单操作几步，让系统定时同步远程时间。在文件的最下方输入下面代码即可。检查系统是否安装了crond。
Redis RDB持久化原理
菜鸟联盟
07-28 262
一 rdb持久化配置 # 时间策略，表示900s内如果有1条是写入命令，就触发产生一次快照，可以理解为就进行一次备份 save 900 1 save 300 10 # 表示300s内有10条写入，就产生快照 save 60 10000 # redis servercron 类似于linux的crontab，默认每隔100毫秒执行一次 # 文件名称 dbfilename dump.rdb # 如果持久化出错，主进程是否停止写入 stop-writes-on-bgsave-error yes # 是
Redis持久化【RDB，bgsave的写时复制机制】【AOF，aof重写机制】【Redis混合持久化，以及对应改变aof重写规则】【Redis数据备份策略】
蓝天it（让亿万孩子在蓝天下共享优质教育）
03-24 976
如果开启了混合持久化，AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。从 1.1 版本开始，注意，如果执行带过期时间的set命令，aof文件里记录的是并不是执行的原始命令，而是记录key过期的时间戳。
redis中的数据什么时候更新？
m0_67390963的博客
04-22 1268
目录 redis的执行过程 redis中的数据什么时候更新？ redis的执行过程 当客户端请求请求服务器时，首先查看redis中是否有需要的数据，如果有直接从redis中拿数据；如果没有数据，则从数据库中取到数据，把数据放到redis中，下次可以从redis中取数据了。因为redis在内存中，运行很快。 redis中的数据什么时候更新？ 在后台管理页面修改后台数据时，牵涉到redis中的数据时，在修改数据后应该删除redis中相应的字段，这样当客户端访问时会重新加载redis，即从数据库中取到数据放到r
Redis进阶.zip
11-02
Redis进阶.zip
Redis进阶，架构师成长之路
02-09
Redis进阶，架构师成长之路
Redis专项进阶课 解决Redis工作实际问题+掌握Redis6.x特性-附件资源
03-05
Redis专项进阶课 解决Redis工作实际问题+掌握Redis6.x特性-附件资源
Redis之RDB数据备份
hq.zheng的博客
04-06 2669
一、什么是RDB(Redis DataBase)？ 1）、在指定的时间间隔内将内存中的数据集快照写入磁盘，保存的是dump.rdb文件，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。 2）、Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 fork...
redis之RDB快照定时备份
lglspace的博客
09-11 1263
设置每小时备份一次，保留48小时 crontab -e 0 * * * * sh /root/tools/redis_rdb_bak_hourly.sh vim /root/tools/redis_rdb_bak_hourly.sh #!/bin/sh history_hour=`date +%Y%m%d%H` rm -rf /opt/data-history/redis/$history_h...
Redis过期时间
huangtianyu1的博客
10-07 1523
Redis过期时间
Redis缓存简介以及缓存的更新策略
花&败
12-30 1585
举个例子：越野车，山地自行车，都拥有” 避震器”, 防止车体加速后因惯性，在酷似”U” 字母的地形上飞跃，硬着陆导致的损害 , 像个弹簧一样；同样，实际开发中，系统也需要” 避震器”,；这在实际开发中对企业讲，对产品口碑，用户评价都是致命的；所以企业非常重视缓存技术；。
redis更新key的存在时间
lpfasd123的博客
11-30 1856
在 Redis 中，可以为给定key设置生存时间，当key过期时(生存时间为0)，它会被自动删除。在 Redis 中，带有生存时间的key被称为『易失的』(volatile)。生存时间可以通过使用DEL命令来删除整个key来移除，或者被SET和GETSET命令覆写(overwrite)，这意味着，如果一个命令只是修改(alter)一个带生存时间的key的值...
Redis刷新数据
热门推荐
IT民工，从事Linux系统运维工作多年，日常技术知识分享。
03-09 1万+
[root@back-end2 ~]# redis-cli 127.0.0.1:6379&gt; keys * 1) "aa" 2) "REDIS_KEY_SQL" 127.0.0.1:6379&gt; del key REDIS_KEY_SQL (integer) 1 127.0.0.1:6379&gt; keys * ## 多刷新几次 1) "aa" 127.0.0.1:6379&...
Redis学习笔记（十）——过期时间、访问限制与缓存
sjmnh1的专栏
11-27 1158
过期时间 之前应该提到过redis的特性之一是可以设置键的超时时间。命令是expire。 redis > SET session:27e7a id1234 OK redis > EXPIRE session:27e7a 1200 (integer) 1 EXPIRE命令返回1表示成功，返回0表示键值不存在或设置失败。 同时这里还有一个比较
高级Redis进阶课 解决Redis实际问题
05-10
《高级Redis进阶课》主要关注Redis的实际应用和解决方案，旨在帮助开发者更好地应对Redis在实际项目中遇到的问题。 该课程内容涵盖Redis的高级特性和应用场景，包括Redis的分布式锁、Lua脚本、持久化、复制、集群等方面的内容。通过实际案例分析和演示，让学员深入理解Redis的运作机制，掌握如何在实际项目中使用Redis解决各种问题。 此外，课程还介绍了如何优化Redis的性能和可靠性，包括如何进行性能测试和调优、如何设置合理的配置参数、如何保证Redis的高可用性等方面的内容。 总的来说，《高级Redis进阶课》是一门非常实用的课程，能够帮助开发者更好地应对Redis在实际项目中遇到的各种问题。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

yfs1024

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值