Redis5过期删除策略和内存淘汰机制

「爱情、让人受尽委屈。」 2022-12-20 12:55 285阅读 0赞

Redis是基于内存操作的非关系型数据库，在内存空间不足的时候，为了保证程序的运行和命中率，就会淘汰一部分数据。如何淘汰数据？这就是Redis的内存回收策略。

Redis中的内存回收策略主要有两个方面：

*  Redis过期策略：删除已经过期的数据;
 *  Redis淘汰策略：内存使用到达maxmemory上限时触发内存淘汰数据。

# 一、Redis过期策略 #

通过EXPIRE命令和PEXPIRE命令，可以以秒或者毫秒精度为Redis中的某个key设置生存时间（Time To Live，TTL），在经过指定的秒数或者毫秒数之后，服务器就会自动删除生存时间为0的键。

*  EXPIRE <key> <ttl> ：设置key的生存时间，ttl单位为秒。
 *  PEXPIRE <key> <ttl> ：设置key的生存时间，ttl单位为毫秒。
 *  EXPIREAT <key> <timestamp> ：设置key的过期时间，timestamp为指定的秒数时间戳。
 *  PEXPIREAT <key> <timestamp> :设置key的过期时间，timestamp为指定的毫秒数时间戳。
 *  SETEX  <key>  <ttl>  <value>：设置key的值为value，并设置超时时间，ttl单位为毫秒。

通过上面命令，设置了key的超时时间，如果一个键过期了，那么它什么时候会被删除呢？Redis通过过期删除策略对过期的key进行删除，过期策略有两种：惰性删除和定期删除。惰性删除为动删除策略，而定期删除为主动删除策略。

## 1.1、被动方式（passive way） ##

放任键过期不管，在客户端尝试访问key时，都检查取得的key是否过期

*          如果key已经失效，就删除key；
 *          如果没有失效，就返回该key的值。但是那些从未被查询过的key，即使这些key已经失效了，但是也无法删除。

惰性删除策略的优点：对CPU时间来说是最友好的，程序只会在取出键时才对键进行过期检查，这可以保证删除过期键的操作只会在非做不可的情况下进行，并且删除的目标仅限于当前处理的键，这个策略不会在删除其他无关的过期键上花费任何CPU时间。

惰性删除策略的缺点：对内存是最不够友好，如果一个键已经过期，这个键有可能仍然保留在数据库中，所占用的内存不会释放。在使用惰性删除策略时，如果数据库中有非常多的过期键，而这些过期键又恰好没有被访问到的话，那么它们也许永远也不会被删除（除非用户手动执行FLUSHDB），我们甚至可以将这种情况看作是一种内存泄漏——无用的垃圾数据占用了大量的内存，而服务器却不会自己去释放它们，这对于运行状态非常依赖于内存的Redis服务器来说，肯定不是一个好消息。

## 1.2、主动方式（active way） ##

定期删除策略是每隔一段时间，程序就对数据库进行一次检查，从设置失效时间的 key 中，选择一部分失效的 key 进行删除操作。并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响。至于要删除多少过期键，以及要检查多少个数据库，则由算法决定。

定期删除策略的难点是确定删除操作执行的时长和频率

如果删除操作执行得太频繁，或者执行的时间太长，定期删除策略就会退化成定时删除策略，以至CPU时间过多地消耗在删除过期key上面。

*  如果删除操作执行得太少，或者执行的时间太短，定期删除策略又会和惰性删除策略一样，出现浪费内存的情况。

因此，如果采用定期删除策略的话，服务器必须根据情况，合理地设置删除操作的执行时长和执行频率。

因此Redis会周期性的随机测试一些key，已过期的key将会被删除。Redis每秒会进行10次操作，根据key的过期比例，使用快慢两种速率回收键，具体的流程：

1.  随机的测试20个带有timeout(过期时间)信息的key；
2.  删除其中已经过期的key；
3.  如果超过25%的key被删除，则重复执行步骤1

定期删除不断重复的进行过期检测，直到过期的keys的百分百低于25%,这意味着，在任何给定的时刻，最多会清除1/4的过期keys。

定期删除的优点是：通过定期删除过期key，有效地减少了因为过期key带来的内存浪费。

定期删除的缺点是：会漏掉了很多过期key，然后你也没及时去查，也就没走惰性删除，造成大量过期key堆积在内存里。

Redis服务器使用的是惰性删除和定期删除两种策略，通过配合使用这两种删除策略，服务器可以很好地在合理使用CPU时间和避免浪费内存空间之间取得平衡。

## 1.3、RDB、AOF对过期键的处理 ##

**1、RDB**

执行SAVE命令或者BGSAVE命令创建一个新的RDB文件时，程序会对数据库中的键进行检查，已过期的键不会被保存到新创建的RDB文件中。也就是说数据库中包含过期键不会对生成新的RDB文件造成影响。

在启动Redis服务器时，如果服务器开启了RDB功能，那么服务器将对RDB文件进行载入：

如果服务器以主服务器模式运行，在载入RDB文件时会对文件中的key进行检查，未过期的键会被载入到数据库中，而过期键则会被忽略，所以过期键对载入RDB文件的主服务器不会造成影响。

如果服务器以从服务器模式运行，那么在载入RDB文件时，文件中保存的所有key，不论是否过期，都会被载入到数据库中。不过，因为主从服务器在进行数据同步的时候，从服务器的数据库就会被清空，所以一般来讲，过期键对载入RDB文件的从服务器也不会造成影响。

**2、AOF**

当服务器以AOF持久化模式运行时，如果数据库中的某个键已经过期，但它还没有被惰性删除或者定期删除，那么AOF文件不会因为这个过期键而产生任何影响。当过期键被惰性删除或者定期删除之后，程序会向AOF文件追加（append）一条DEL命令，来显式地记录该键已被删除。因此，数据库中包含过期键不会对AOF重写造成影响。

# 二、Redis内存淘汰机制 #

## 2.1、maxmemory ##

maxmemory用来设置redis存放数据的最大的内存大小，一旦超出这个内存大小之后，就会立即使用Redis的淘汰策略，来淘汰内存中的一些对象，以保证新数据的存入。当maxmemory限制达到的时，Redis会使用的行为由 Redis的maxmemory-policy配置指令来进行配置。

通过redis.conf可以设置maxmemory的值，或者之后使用CONFIG SET命令来配置maxmemory的值。

修改redis.confg配置

maxmemory 100mb  \#内存限制为100mb

maxmemory设置为0表示没有内存限制。64位系统默认值为0，32位系统默认内存限制为3GB。

在Redis的配置文件redis.conf中，maxmemory和maxmemory-policy如下图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY2hhb3lhbmc_size_16_color_FFFFFF_t_70][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY2hhb3lhbmc_size_16_color_FFFFFF_t_70 1][]

## 2,2、maxmemory-policy ##

Redis淘汰默认的是noeviction策略，当内存使用达到限制时，Redis将根据根据选择的淘汰策略，尝试删除一部分key。

根据配置的淘汰策略，如果redis删除key失败，或者配置的淘汰策略是noeviction，执行使用内存的命令，例如SET, LPUSH等命令，Redis将会报错，而只读命令GET可以正常执行。

Redis淘汰策略有以下8种：

*  volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，使用LRU算法，移除最近最少使用的key；
 *  allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，使用LRU算法，移除最近最少使用的key；
 *  volatile-lfu：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，使用LFU算法，移除最近最少使用的key；
 *  allkeys-lfu：当内存不足以容纳新写入数据时，在键空间中，使用LFU算法，移除最近最少使用的key；
 *  volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key；
 *  allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key；
 *  volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除；
 *  noeviction：当内存不足以容纳新写入数据时，新写入操作会报错(默认)。

## 2.3、淘汰策略**回收过程** ##

理解回收进程如何工作是非常重要的:

*  1、客户端运行了新的命令，添加了新的数据
 *  2、Redi检查内存使用情况，如果大于maxmemory的限制, 则根据设定好的策略进行回收。
 *  3、一个新的命令被执行

Redis的LRU算法并非完整的实现。这意味着Redis并没办法选择最佳候选来进行回收，也就是最久未被访问的键。相反它会尝试运行一个近似LRU的算法，通过对少量keys进行取样，然后回收其中一个最好的key（被访问时间较早的）。

不过从Redis 3.0算法已经改进为回收键的候选池子。这改善了算法的性能，使得更加近似真是的LRU算法的行为。

Redis LRU有个很重要的点，你通过调整每次回收时检查的采样数量，以实现**调整**算法的精度。这个参数可以通过以下的配置指令调整:

maxmemory-samples 5

Redis为什么不使用真实的LRU实现是因为这需要太多的内存。不过近似的LRU算法对于应用而言应该是等价的。

参考

《Redis设计与实现》—— 黄健宏

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY2hhb3lhbmc_size_16_color_FFFFFF_t_70]: /images/20221120/fd3fe94247264314895a0dad220bee29.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nY2hhb3lhbmc_size_16_color_FFFFFF_t_70 1]: /images/20221120/98b54b6f2ddb4e9996232cb99d42ed4c.png