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

时间：2022-11-04 20:52:42

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

文章目录

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

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

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

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

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 如何判定 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;

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

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

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

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

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

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 是怎么实现惰性删除的？

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

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"

可以看出，当前 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;

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

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

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

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

  • 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
  • 或者在redis.conf 添加配置:
notify-keyspace-events "Ex" //过期时间监听生效

idea环境配置

pom.xml加上redis的依赖

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

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

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;
    }
}

实现类

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);
    }
}

测试

127.0.0.1:6379> setex name 10 zhangsan

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

成功了，哦吼！

笔记参考：

感谢大佬支持！！

标签：

相关文章