跳至主要內容

Redis-基础篇-③过期删除策略和内存淘汰策略

holic-x...大约 14 分钟RedisRedis

Redis-基础篇-③过期删除策略和内存淘汰策略

学习核心

  • 缓存过期删除 VS 内存淘汰策略 核心概念
  • 淘汰算法解析（手撕淘汰算法简化版本）

学习资料

过期删除策略 VS 内存淘汰策略

1.过期删除策略

​ Redis 可以对key设定过期时间，需要有相应的机制将已过期的键值对删除，而做这个工作的就是过期键值删除策略。

如何设置过期时间？

​ Redis提供了多个命令用于额外对key设置过期时间

命令说明
expire <key> <n>设置 key 在 n 秒后过期，比如 expire key 100 表示设置 key 在 100 秒后过期
pexpire <key> <n>设置 key 在 n 毫秒后过期，比如 pexpire key2 100000 表示设置 key2 在 100000 毫秒（100 秒）后过期
expireat <key> <n>设置 key 在某个时间戳（精确到秒）之后过期，比如 expireat key3 1655654400 表示 key3 在时间戳 1655654400 后过期（精确到秒）
pexpireat <key> <n>设置 key 在某个时间戳（精确到毫秒）之后过期，比如 pexpireat key4 1655654400000 表示 key4 在时间戳 1655654400000 后过期（精确到毫秒）

​ 也可在设置字符串的时候对key设置过期时间：

命令说明
set <key> <value> ex <n>设置键值对的时候，同时指定过期时间（精确到秒）
set <key> <value> px <n>设置键值对的时候，同时指定过期时间（精确到毫秒）
setex <key> <n> <valule>设置键值对的时候，同时指定过期时间（精确到秒）

​ 查看指定key的过期时间（TTL <key>）

​ 取消key的过期时间（PERSIST <key>）

如何判定key已过期？

​ 通过定义【过期字典】存储key的过期时间，如果key指定了过期事件，则在检索的时候键其对应过期时间与当前系统时间进行对比

​ 每当对一个 key 设置了过期时间时，Redis 会把该 key 带上过期时间存储到一个过期字典（expires dict）中（即「过期字典」保存了数据库中所有 key 的过期时间），过期字典数据结构分析如下：

  • 过期字典的 key 是一个指针，指向某个键对象；
  • 过期字典的 value 是一个 long long 类型的整数，这个整数保存了 key 的过期时间；

​ 字典实际上是哈希表，哈希表的最大好处就是可以用 O(1) 的时间复杂度来快速查找。当查询一个 key 时，Redis 首先检查该 key 是否存在于过期字典中：

  • 如果不在，则正常读取键值；
  • 如果存在，则会获取该 key 的过期时间，然后与当前系统时间进行比对，如果比系统时间大，那就没有过期，否则判定该 key 已过期。

过期删除策略分类

​ 常见的过期删除策略有三种：

  • 定时删除：在设置 key 的过期时间时，同时创建一个定时事件，当时间到达时，由事件处理器自动执行 key 的删除操作
    • 优点：内存友好型策略，它可以保证过期 key 会被尽快删除，即内存可以被尽快地释放
    • 缺点：对CPU不太友好，在过期 key 比较多的情况下，删除过期 key 可能会占用相当一部分 CPU 时间，在内存不紧张但 CPU 时间紧张的情况下，将 CPU 时间用于删除和当前任务无关的过期键上，无疑会对服务器的响应时间和吞吐量造成影响
  • 惰性删除：不主动删除过期键，每次从数据库访问 key 时，都检测 key 是否过期，如果过期则删除该 key
    • 优点：CPU友好型策略，每次访问时才检查key是否过期，过期则进行删除。因此此策略只会使用很少的系统资源，对 CPU 时间最友好。
    • 缺点：对内存不太友好，如果一个key早已过期，却依然保存在数据库中，如果这个key一直没有被访问就会一直占用内存，造成一定的内存空间浪费
  • 定期删除：每隔一段时间「随机」从数据库中取出一定数量的 key 进行检查，并删除其中的过期key
    • 优点：通过限制删除操作执行的时长和频率，来减少删除操作对 CPU 的影响，同时也能删除一部分过期的数据减少了过期键对空间的无效占用
    • 缺点：
      • 可以理解为它是定时删除和惰性删除的一种中和方案，其内存清理方面没有定时删除效果好，且比惰性删除占用的资源多
      • 难以衡量删除操作执行的时长和频率标准，如果执行得太频繁就会使该策略执行效果趋近于定时删除策略，如果执行得太少也会使得该策略执行效果趋近于惰性删除策略，难以抉择一个相对标准

Redis的过期删除策略

​ 基于上述多过期删除策略的分析，如果单独使用其中某一种策略，难以满足实际需求，因此 Redis 选择「惰性删除+定期删除」这两种策略配和使用，以求在合理使用 CPU 时间和避免内存浪费之间取得平衡

image-20240717165251836

（1）Redis 如何实现惰性删除？

​ Redis 的惰性删除策略由 db.c 文件中的 expireIfNeeded 函数实现，代码如下：

int expireIfNeeded(redisDb *db, robj *key) {
    // 判断 key 是否过期
    if (!keyIsExpired(db,key)) return 0;
    ....
    /* 删除过期键 */
    ....
    // 如果 server.lazyfree_lazy_expire 为 1 表示异步删除，反之同步删除；
    return server.lazyfree_lazy_expire ? dbAsyncDelete(db,key) :
                                         dbSyncDelete(db,key);
}

Redis 在访问或者修改 key 之前，都会调用 expireIfNeeded 函数对其进行检查，检查 key 是否过期：

  • 如果过期，则删除该 key，至于选择异步删除，还是选择同步删除，根据 lazyfree_lazy_expire 参数配置决定（Redis 4.0版本开始提供参数），然后返回 null 客户端；
  • 如果没有过期，不做任何处理，然后返回正常的键值对给客户端；
（2）Redis 如何实现定期删除？

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

​ 因此此处需要考虑两个问题点：1.间隔检查的时间设置为多长？ 2.随机抽取的数量设置为多少？

  • 【1】间隔检查的时间设置为多长？=> 在 Redis 中，默认每秒进行 10 次过期检查一次数据库，此配置可通过 Redis 的配置文件 redis.conf 进行配置，配置键为 hz 它的默认值是 hz 10。
  • 【2】随机抽取的数量设置为多少？=> 定期删除的实现在 expire.c 文件下的 activeExpireCycle 函数中，其中随机抽查的数量由 ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 定义的，它是写死在代码中的，数值是 20

Redis 实现定期删除的过程

  • 【1】从过期字典中随机抽取 20 个 key
  • 【2】检查这 20 个 key 是否过期，并删除已过期的 key
  • 【3】判断本轮执行删除操作的时间是否超过限制（默认不超过25ms），如果超出限制则跳出循环
  • 【4】校验循环是否继续：如果本轮检查的已过期 key 的数量，超过 5 个（20/4），也就是「已过期 key 的数量」占比「随机抽取 key 的数量」大于 25%，则继续重复步骤 1；如果已过期的 key 比例小于 25%，则停止继续删除过期 key，然后等待下一轮再检查

​ 此处为了避免循环过度导致线程卡死现象，设定了定期删除循环流程的时间上限，默认不会超过 25ms，在每次删除操作完成后都会校验删除执行的时间，如果超出上限则跳出循环

2.内存淘汰策略

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

如何设置Redis最大运行内存？

​ 在配置文件 redis.conf 中，可以通过参数 maxmemory <bytes> 来设定最大运行内存，只有在 Redis 的运行内存达到了设置的最大运行内存，才会触发内存淘汰策略。 不同位数的操作系统，maxmemory 的默认值不同：

  • 在 64 位操作系统中，maxmemory 的默认值是 0，表示没有内存大小限制，那么不管用户存放多少数据到 Redis 中，Redis 也不会对可用内存进行检查，直到 Redis 实例因内存不足而崩溃也无作为
  • 在 32 位操作系统中，maxmemory 的默认值是 3G，因为 32 位的机器最大只支持 4GB 的内存，而系统本身就需要一定的内存资源来支持运行，所以 32 位操作系统限制最大 3 GB 的可用内存是非常合理的，以此避免因为内存不足而导致 Redis 实例崩溃

Redis 内存淘汰策略分类

​ Redis 内存淘汰策略共有八种，这八种策略大体分为「不进行数据淘汰」和「进行数据淘汰」两类策略

（1）「不进行数据淘汰」的策略

​ noeviction（Redis3.0之后，默认的内存淘汰策略） ：它表示当运行内存超过最大设置内存时，不淘汰任何数据，这时如果有新的数据写入，会报错通知禁止写入，不淘汰任何数据，但是如果没用数据写入的话，只是单纯的查询或者删除操作的话，还是可以正常工作。

（2）「进行数据淘汰」的策略

​ 针对「进行数据淘汰」这一类策略，又可以细分为「在设置了过期时间的数据中进行淘汰」和「在所有数据范围内进行淘汰」这两类策略

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

  • 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

> config get maxmemory-policy

# output
[
  {
    "field": "maxmemory-policy",
    "value": "noeviction"
  }
]

修改Redis内存淘汰策略

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

LRU算法 VS LFU算法

（1）LRU算法

什么是LRU算法？

​ LRU （Least Recently Used） 最近最少使用，会选择淘汰最近最少使用的数据

image-20240717174821208

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

Redis 并没有使用这样的方式实现 LRU 算法，因为传统的 LRU 算法存在两个问题：

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

Redis如何实现LRU算法？

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

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

image-20240717175652089

Redis 实现的 LRU 算法的优点：

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

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

（2）LFU算法

​ 为了解决上述缓存污染问题，Redis4.0之后引入了LFU算法。

什么是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 存储 ldt(Last Decrement Time)，低 8bit 存储 logc(Logistic Counter)

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

​ 此处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 增长越慢
0  字
评论
  • 按正序
  • 按倒序
  • 按热度
Powered by Waline v3.1.3
一人の境 Copyright © 2019-未知 holic-x
Copyright © 2024 holic-x