• 【Redis】原理篇:Redis过期删除与内存淘汰


    【Redis】原理篇:Redis过期删除与内存淘汰

    这周老板给我安排一个任务是在规定时间内发送一个邮件给对方,业务流程:

    1. 在redis中存储一个有存活时间的key
    2. redis监听过期的key
    3. 当监听到该key过期了,就发一个邮件给对方

    然后我去学习了一下redis是如何监听过期key的,查了博客后发现越来越深入,所以又想了解它的原理是如何实现的,这篇文章就来记录一下关于redis过期删除与内存淘汰机制

    image-20221103124019125

    Redis之所以性能强,最主要的原因就是基于内存存储。然而单节点的Redis其内存大小不宜过大,会影响持久化或主从同步性能。

    当内存使用达到上限时,就无法存储更多数据了。为了解决这个问题,Redis提供了一些策略实现内存回收:

    1. 过期删除策略

    我们知道Redis是可以对 key 设置过期时间的,因此当过期时间一到,Redis就会使用某种策略将过期的key 删除,从而起到内存回收的目的。

    1.1 如何设置过期时间?

    这里我们举例了一些常用的设置过期时间的命令:

    # 设置键值对的同时指定过期时间 EX单位是秒
    127.0.0.1:6379> set name zhangshan EX 10
    OK
    # 查看key过期时间还剩多少
    127.0.0.1:6379> ttl name
    (integer) 5
    127.0.0.1:6379> ttl name
    (integer) -2
    # 设置过期时间,单位是秒
    127.0.0.1:6379> setex name 10 lisi
    OK
    127.0.0.1:6379> ttl name
    (integer) 6
    127.0.0.1:6379> ttl name
    (integer) -2
    127.0.0.1:6379> set name wangwu
    OK
    # 给已经有的key设置过期时间,单位是秒
    127.0.0.1:6379> expire name 10
    (integer) 1
    127.0.0.1:6379> ttl name
    (integer) 5
    127.0.0.1:6379> ttl name
    (integer) -2
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24

    1.2 如何判定 key 过期了?

    我们先来看设置过期时间的key是怎么存储的:

    Redis本身是一个典型的key-value内存存储数据库,因此所有的key、value都保存在Dict结构中。不过在其database结构体中,有两个Dict:一个用来记录key-value;另一个用来记录key-TTL。

    typedef struct redisDb {
        dict *dict;    /* 数据库键空间,存放着所有的键值对 */
        dict *expires; /* 存放着每一个key及其对应的TTL存活时间,只包含了设置TTL的key */
        ....
    } redisDb;
    
    • 1
    • 2
    • 3
    • 4
    • 5

    也就是说当我们每对一个 key 设置了过期时间时,Redis会把该键值对存入dict的同时,存储到expire 中。

    image-20221102211528824

    字典实际上是哈希表,哈希表的最大好处就是可以用O(1)的复杂度去查询某个key。当我们执行get key这条指令后,Redis搜先检查该key是否存在于字典中:

    • 如果在expire中找不到的话,就直接从dict中获取
    • 如果在expire中找到该key,则会获取该 key 的过期时间,然后与当前系统时间进行比对:
      • 如果比系统时间大,说明还未过期
      • 否则已过期

    image-20221102212922000

    1.3 过期策略有哪些?

    1.3.1 定时删除

    定时删除的策略是,在设置 key 的过期时间时,同时创建一个定时时间,当时间到达时,由时间处理器自动执行 key 的删除操作。

    跟定时炸弹💣一样,到点就炸。

    • 优点:可以保证过期 key 会被尽快删除掉,也就是说内存可以被尽快地释放。因此,定时删除对内存时最友好的。
    • 缺点:在过期 key 比较多的情况下,删除过期 key 可能会占用相当一部分 CPU 时间,在内存不紧张但 CPU 时间紧张的情况下,将 CPU 时间用于删除和当前任务无关的过期键上,无疑会对服务器的相应时间和吞吐量造成影响。所以,定时删除对CPU不友好
    1.3.2 惰性删除

    惰性删除策略:不主动删除过期键,每次从数据库访问 key 时,都检测 key 是否过期,如果过期则删除该 key。

    • 优点:因此每次访问时,才会检查 key 是否过期,所以此策略只会使用很少的系统资源,因此,该策略对 CPU 很友好
    • 缺点:如果一个 key 已经过期,而这个 key 又仍然保留在数据库中,那么只要这个过期 key 一致没有被访问,它所占用的内存就不会释放,造成了一定的内存空间浪费。所以,惰性删除对内存不友好
    1.3.3 定期删除

    定期删除策略:每个一段时间 随机 从数据库中取出一定数量的 key 进场检查,并删除其中的过期 key。

    这个策略就属于综合上面两个策略了,对 CPU 友好一些,对 内存也友好一些。

    • 优点:通过限制删除操作执行的时长和频率,来减少删除操作对 CPU 的影响,同时也能删除一部分过期的数据减少了过期键对空间的无效占用。
    • 缺点
      1. 内存清理方面没有定时删除效果好,同时没有惰性删除使用的系统资源少。
      2. 难以缺点删除操作执行的市场和频率。如果执行的太频繁,定期删除策略变得和定时删除策略一样,对CPU不友好。如果执行的太少,那又和惰性删除一样了,过期 key 占用的内存不会及时得到释放。

    1.4 Redis 过期策略是什么?

    前面介绍了三种过期删除策略,每一种都有优缺点,仅使用某一个策略都不能满足实际需求。

    所以, Redis 选择 惰性删除+定期删除 这两种策略配和使用,以求在合理使用 CPU 时间和避免内存浪费之间取得平衡。

    1.4.1 Redis 是怎么实现惰性删除的?

    image-20221103112254611

    Redis 在对 key 进行度或写操作之前,都会调用 expireIfNeeded 函数对其进行检查,检查 key 是否过期:

    • 如果过期,则删除该 key,返回 null 给客户端
    • 如果没有过期,不做任何操作,返回正常的键值对给客户端。
    1.4.2 Redis 是怎么实现定期删除的?

    定期删除策略:每个一段时间 随机 从数据库中取出一定数量的 key 进场检查,并删除其中的过期 key。

    检查间隔时长

    在 Redis 中,默认每秒进行 10 次过期检查一次数据库,此配置可通过 Redis 的配置文件 redis.conf 进行配置,配置键为 hz 它的默认值是 hz 10。

    特别强调下,每次检查数据库并不是遍历过期字典中的所有 key,而是从数据库中随机抽取一定数量的 key 进行过期检查。

    抽查数量

    Redis 的定期删除的流程:

    1. 从过期字典中随机抽取 20 个 key;
    2. 检查这 20 个 key 是否过期,并删除已过期的 key;
    3. 如果本轮检查的已过期 key 的数量,超过 5 个(20/4),也就是「已过期 key 的数量」占比「随机抽取 key 的数量」大于 25%,则继续重复步骤 1;如果已过期的 key 比例小于 25%,则停止继续删除过期 key,然后等待下一轮再检查。

    可以看到,定期删除是一个循环的流程。

    那 Redis 为了保证定期删除不会出现循环过度,导致线程卡死现象,为此增加了定期删除循环流程的时间上限,默认不会超过 25ms。


    2 内存淘汰策略

    前面说的过期删除策略,是删除已过期的 key,而当 Redis 的运行内存已经超过 Redis 设置的最大内存之后,则会使用内存淘汰策略删除符合条件的 key,以此来保障 Redis 高效的运行。

    2.1 Redis内存淘汰策略有哪些?

    Redis 内存淘汰策略共有八种,这八种策略大体分为不进行数据淘汰进行数据淘汰两类策略。

    不进行数据淘汰的策略

    noeviction(Redis3.0之后,默认的内存淘汰策略) :它表示当运行内存超过最大设置内存时,不淘汰任何数据,这时如果有新的数据写入,则会触发内存溢出,但是如果没用数据写入的话,只是单纯的查询或者删除操作的话,还是可以正常工作。

    进行数据淘汰的策略

    针对这一策略,又可以分为两类:

    在设置了过期时间的数据中进行淘汰

    • volatile-random:随机淘汰设置了过期时间的任意键值;
    • volatile-ttl:优先淘汰更早过期的键值。
    • volatile-lru(Redis3.0 之前,默认的内存淘汰策略):淘汰所有设置了过期时间的键值中,最久未使用的键值;
    • volatile-lfu(Redis 4.0 后新增的内存淘汰策略):淘汰所有设置了过期时间的键值中,最少使用的键值;

    在所有数据范围内进行淘汰

    • allkeys-random:随机淘汰任意键值;
    • allkeys-lru:淘汰整个键值中最久未使用的键值;
    • allkeys-lfu(Redis 4.0 后新增的内存淘汰策略):淘汰整个键值中最少使用的键值。

    如何查看当前 Redis 使用的内存淘汰策略?

    可以使用 config get maxmemory-policy 命令,来查看当前 Redis 的内存淘汰策略,命令如下:

    127.0.0.1:6379> config get maxmemory-policy
    1) "maxmemory-policy"
    2) "noeviction"
    
    • 1
    • 2
    • 3

    可以看出,当前 Redis 使用的是 noeviction 类型的内存淘汰策略,它是 Redis 3.0 之后默认使用的内存淘汰策略,表示当运行内存超过最大设置内存时,不淘汰任何数据,但新增操作会报错。

    如何修改 Redis 内存淘汰策略?

    设置内存淘汰策略有两种方法:

    • 方式一:通过“config set maxmemory-policy <策略>”命令设置。它的优点是设置之后立即生效,不需要重启 Redis 服务,缺点是重启 Redis 之后,设置就会失效。
    • 方式二:通过修改 Redis 配置文件修改,设置“maxmemory-policy <策略>”,它的优点是重启 Redis 服务后配置不会丢失,缺点是必须重启 Redis 服务,设置才能生效。

    2.2 LRU 算法和 LFU 算法有什么区别?

    2.2.1 LRU 算法

    LRU 全称是 Least Recently Used 翻译为最近最少使用,会选择淘汰最近最少使用的数据。

    传统 LRU 算法的实现是基于链表结构,链表中的元素按照操作顺序从前往后排,最新操作的键会被移动到表头,当需要内存淘汰是,只需要删除链表尾部的元素即可,因为链表尾部的元素就代表最久未被使用的元素。

    但Redis并没有使用这样的方式实现LRU算法,一五年传统的LRU算法存在两个问题:

    • 需要用链表管理所有的缓存数据,这会带来额外的空间开销
    • 当有数据被访问是,需要在链表上把该数据移动到表头,如果有大量数据被访问,就会带来很多链表移动操作,会很耗时,进而会降低 Redis 缓存性能。

    Redis 是如何实现LRU算法的?

    Redis 实现的是一种 近似LRU算法,目的是为了更好的节约内存,它的实现方式是在Redis 的对象结构体中添加一个 额外的字段,用于记录此数据的最后依次访问时间。

    当 Redis 进行内存淘汰,会使用随机采样的方式来淘汰数据,它是随机取5个值(此值可配置),然后淘汰最久没有使用的那个

    Redis 实现的 LRU 算法的优点:

    • 不用为所有的数据维护一个大链表,节省了空间占用;
    • 不用在每次数据访问时都移动链表项,提升了缓存的性能;

    但是 LRU 算法有一个问题,无法解决缓存污染问题,比如应用一次读取了大量的数据,而这些数据只会被读取这一次,那么这些数据会留存在 Redis 缓存中很长一段时间,造成缓存污染。

    为了解决这一问题,Redis引入了LFU算法来解决这个问题。

    2.2.2 LFU算法

    LFU 全称是 Least Frequently Used 翻译为最近最不常用的,LFU 算法是根据数据访问次数来淘汰数据的,它的核心思想是“如果数据过去被访问多次,那么将来被访问的频率也更高”。

    所以, LFU 算法会记录每个数据的访问次数。当一个数据被再次访问时,就会增加该数据的访问次数。这样就解决了偶尔被访问一次之后,数据留存在缓存中很长一段时间的问题,相比于 LRU 算法也更合理一些。

    Redis是如何实现LFU算法的?

    LFU算法比LRU算法的实现,多记录了数据的访问频次的信息。

    Redis对象的结构如下:

    typedef struct redisObject {
        ...
    
            // 24 bits,用于记录对象的访问信息
            unsigned lru:24;  
        ...
    } robj;
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7

    Redis 对象头中的 lru 字段,在 LRU 算法下和 LFU 算法下使用方式并不相同。

    在 LRU 算法中,Redis 对象头的 24 bits 的 lru 字段是用来记录 key 的访问时间戳,因此在 LRU 模式下,Redis可以根据对象头中的 lru 字段记录的值,来比较最后一次 key 的访问时间长,从而淘汰最久未被使用的 key。

    在 LFU 算法中,Redis对象头的 24 bits 的 lru 字段被分成两段来存储,高 16bit 存储 访问时间戳,低 8bit 存储 访问频次。

    image-20221103122155062

    • ldt 是用来记录 key 的访问时间戳;
    • logc 是用来记录 key 的访问频次,它的值越小表示使用频率越低,越容易淘汰,每个新加入的 key 的logc 初始值为 5。

    logc 并不是单纯的访问次数,而是访问频次(访问频率),因为 logc 会随时间推移而衰减的

    在每次 key 被访问时,会先对 logc 做一个衰减操作,衰减的值跟前后访问时间的差距有关系,如果上一次访问的时间与这一次访问的时间差距很大,那么衰减的值就越大,这样实现的 LFU 算法是根据访问频率来淘汰数据的,而不只是访问次数。访问频率需要考虑 key 的访问是多长时间段内发生的。key 的先前访问距离当前时间越长,那么这个 key 的访问频率相应地也就会降低,这样被淘汰的概率也会更大。

    对 logc 做完衰减操作后,就开始对 logc 进行增加操作,增加操作并不是单纯的 + 1,而是根据概率增加,如果 logc 越大的 key,它的 logc 就越难再增加

    存储访问频率的位数有限,所以不可能特别大,要进行一定的策略来保证相对大小。

    所以,Redis 在访问 key 时,对于 logc 是这样变化的:

    1. 先按照上次访问距离当前的时长,来对 logc 进行衰减;
    2. 然后,再按照一定概率增加 logc 的值

    redis.conf 提供了两个配置项,用于调整 LFU 算法从而控制 logc 的增长和衰减:

    • lfu-decay-time 用于调整 logc 的衰减速度,它是一个以分钟为单位的数值,默认值为1,lfu-decay-time 值越大,衰减越慢;
    • lfu-log-factor 用于调整 logc 的增长速度,lfu-log-factor 值越大,logc 增长越慢。

    3 Redis监听过期key(Java实现)

    3.1 适用场景

    比如预约成功半小时后提醒;比如当超时15分通知;比如间隔5分钟处理一次等等

    3.2 配置环境

    Redis环境配置

    • 登录进入redis-cli客户端,执行:
    config set notify-keyspace-events Ex
    
    • 1
    • 或者在redis.conf 添加配置:
    notify-keyspace-events "Ex" //过期时间监听生效
    
    • 1

    idea环境配置

    pom.xml加上redis的依赖

    
    <dependency>
        <groupId>org.springframework.bootgroupId>
        <artifactId>spring-boot-starter-data-redisartifactId>
    dependency>
    
    • 1
    • 2
    • 3
    • 4
    • 5

    application.yml环境中加上Redis配置

    spring:
      redis:
        host: 121.41.xxx.xxx
        port: 6379
        password: 123456
        lettuce:
          pool:
            max-active: 8
            max-idle: 8
            min-idle: 0
            max-wait: 100ms
    
    server:
      port: 8088
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14

    3.3 代码

    配置类

    import org.springframework.context.annotation.Bean;
    import org.springframework.context.annotation.Configuration;
    import org.springframework.data.redis.connection.RedisConnectionFactory;
    import org.springframework.data.redis.listener.RedisMessageListenerContainer;
    
    @Configuration
    public class RedisListenerConfig {
        @Bean
        RedisMessageListenerContainer container(RedisConnectionFactory connectionFactory) {
            RedisMessageListenerContainer container = new RedisMessageListenerContainer();
            container.setConnectionFactory(connectionFactory);
            return container;
        }
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14

    实现类

    import org.springframework.data.redis.connection.Message;
    import org.springframework.data.redis.listener.KeyExpirationEventMessageListener;
    import org.springframework.data.redis.listener.RedisMessageListenerContainer;
    import org.springframework.stereotype.Component;
    
    @Component
    public class RedisKeyExpirationListener extends KeyExpirationEventMessageListener {
        public RedisKeyExpirationListener(RedisMessageListenerContainer listenerContainer) {
            super(listenerContainer);
        }
    
        /**
         * 针对Redis数据失效时间,进行数据处理
         *
         * @param message
         * @param pattern
         */
        @Override
        public void onMessage(Message message, byte[] pattern) {
            // 获取失效的key
            String expireKey = message.toString();
            // 业务处理
            System.out.println(expireKey);
        }
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25

    测试

    127.0.0.1:6379> setex name 10 zhangsan
    
    • 1

    10秒过后idea控制台打印输出name

    成功了,哦吼!

    笔记参考

    感谢大佬支持!!

  • 相关阅读:
    全国职业技能大赛云计算--高职组赛题卷①(容器云)
    API文档工具knife4j使用详解
    概述机器学习算法(机器学习)
    基于Python深度学习的DGA域名检测
    day14网络编程
    论文(0):下载ieee期刊会议杂志论文模板流程
    JavaWeb在线商城系统(java+jsp+servlet+MySQL+jdbc+css+js+jQuery)
    【网管日记】linux服务器上apt-get换源
    Hexagon_V65_Programmers_Reference_Manual(23)
    OpenCV-Python实战(1) —— 给图片添加图片水印【利用 OpenCV 像素的读写原理实现】
  • 原文地址:https://blog.csdn.net/weixin_53029342/article/details/127667922