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

Redis监听过期key，过期删除策略和内存淘汰策略

背书包的小新

985人浏览 · 2022-11-03 12:48:07

背书包的小新 · 2022-11-03 12:48:07 发布

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

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

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

然后我去学习了一下redis是如何监听过期key的，查了博客后发现越来越深入，所以又想了解它的原理是如何实现的，这篇文章就来记录一下关于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 中。

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

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

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 在对 key 进行度或写操作之前，都会调用 expireIfNeeded 函数对其进行检查，检查 key 是否过期：

如果过期，则删除该 key，返回 null 给客户端
如果没有过期，不做任何操作，返回正常的键值对给客户端。

1.4.2 Redis 是怎么实现定期删除的？

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

检查间隔时长

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

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

抽查数量

Redis 的定期删除的流程：

从过期字典中随机抽取 20 个 key；
检查这 20 个 key 是否过期，并删除已过期的 key；
如果本轮检查的已过期 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 存储访问频次。

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

logc 并不是单纯的访问次数，而是访问频次（访问频率），因为 logc 会随时间推移而衰减的。

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

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

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

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

先按照上次访问距离当前的时长，来对 logc 进行衰减；
然后，再按照一定概率增加 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);
    }
}