Redis中key过期和删除及淘汰策略

1.1 过期 key

1.1.1 常用过期删除策略

  • 定时删除 :给每个 key 添加定时任务(或者使用全局 定时任务) 来删除过期的 key 【Redis中没有使用】
  • 惰性删除 : 客户端访问 key 的时候再去判断 key 是否过期,若过期则删除【内部策略,无需配置】
  • 定期删除 :定期过期策略会周期性地执行过期 key 扫描逻辑,并将扫描到的过期 key 清理掉, 可以设置扫描耗时的上限,避免影响正常的功能 Redis使用 惰性过期和定期过期两种策略

1.1.2 定期删除策略描述

Redis 默认会每秒进行 10 次扫描,过期扫描不会遍历过期字典中所有的 key

  • 从过期字典中随机 20 个 key
  • 删除这 20 个 key 中已经过期的 key
  • 如果过期的 key 比率超过 1/4,则重复上述步骤

1.1.3 定期删除策略配置

redis.conf 中可以通过修改 hz 配置来控制删除的频率, 对该配置到描述可以参考 Redis 官网给的 Redis configuration file example, 下面贴出来这个文件和 hz 配置相关的部分, 可以先看一下对 hz 参数的解释

Redis 的配置文件中,hz参数是一个重要的配置项,它表示 Redis 服务器每秒钟执行定时器的频率,单位是次/秒。这个参数主要影响 Redis 对过期 key 的删除策略。 具体来说,hz 参数决定了 Redis 检查并删除过期 key 的频率。当 hz 的值较大时,Redis 会更频繁地检查并删除过期 key,从而保持内存的清洁和高效利用。然而,这也意味着 Redis 会消耗更多的 CPU 资源来执行这些检查和删除操作。因此,需要根据服务器的实际情况来合理配置hz的值,以在内存使用和 CPU 资源之间达到良好的平衡

conf 复制代码
# Redis calls an internal function to perform many background tasks, like
# closing connections of clients in timeout, purging expired keys that are
# never requested, and so forth.
#
# Not all tasks are performed with the same frequency, but Redis checks for
# tasks to perform according to the specified "hz" value.
#
# By default "hz" is set to 10. Raising the value will use more CPU when
# Redis is idle, but at the same time will make Redis more responsive when
# there are many keys expiring at the same time, and timeouts may be
# handled with more precision.
#
# The range is between 1 and 500, however a value over 100 is usually not
# a good idea. Most users should use the default of 10 and raise this up to
# 100 only in environments where very low latency is required.
hz 10

# Normally it is useful to have an HZ value which is proportional to the
# number of clients connected. This is useful in order, for instance, to
# avoid too many clients are processed for each background task invocation
# in order to avoid latency spikes.
#
# Since the default HZ value by default is conservatively set to 10, Redis
# offers, and enables by default, the ability to use an adaptive HZ value
# which will temporarily raise when there are many connected clients.
#
# When dynamic HZ is enabled, the actual configured HZ will be used
# as a baseline, but multiples of the configured HZ value will be actually
# used as needed once more clients are connected. In this way an idle
# instance will use very little CPU time while a busy instance will be
# more responsive.
dynamic-hz yes
  • 根据官网给出的配置示例,该值在 1-500 之间,不过不建议将值设置的超过 100
  • 如果配置了 dynamic-hz yes, 那么 hz 的值只是基准值,可能会根据实际情况动态改变

1.2 内存淘汰策略

1.3 1.什么是内存淘汰策略

  • redis.confmaxmemory 配置项指定了 Redis 的最大内存(单位是 byte )
  • Redis 内存达到设置的值时,就会按照 配置的内存淘汰策略 删除 key

1.3.1 内存淘汰策略有哪些

Redis 的内存淘汰策略可以通过 redis.conf 文件中的 maxmemory-policy 配置指定,具体有以下几种策略

  • no-envictionRedisServer 不会主动删除 key,对 key 的增、改操作会报错,删、查操作可正常响应
  • 接下来的这些策略是对设置了过期时间key 进行删除
    • volatile-lru:[[LRU算法]]
      • Redis 会按照近似 LRU 的算法,从设置了过期时间的 key 中,选取 key 进行淘汰
      • 之所以说近似是因为每次只会选择部分过期的 key,然后删除最近没有访问的 key,这样可以避免遍历所有过期的 key
    • volatile-random
      • 从设置了过期时间的 Key 中随机选择 Key 进行淘汰
    • volatile-ttl
      • 从设置了过期时间的 Key 中筛选将要过期的 Key 进行淘汰
    • volatile-lfu [[LFU算法]]
      • 使用近似 LFU 算法从设置了过期时间的 Key 中,筛选出最近访问频率最低的 Key 进行淘汰
  • 接下来的这些策略是对所有 key 进行选择删除
    • allkeys-lru
      • 使用近似 LRU 算法,筛选 Key 的范围是 Redis 内全部的 Key
    • allkeys-random
      • 从所有 Key 中随机选择 Key 进行淘汰
    • allkeys-lfu
      • 使用近似 LFU 算法从全部 Key 中,筛选出最近访问频率最低的 Key 进行淘汰
相关推荐
【D'accumulation】33 分钟前
令牌主动失效机制范例(利用redis)注释分析
java·spring boot·redis·后端
2401_8543910842 分钟前
高效开发:SpringBoot网上租赁系统实现细节
java·spring boot·后端
Cikiss1 小时前
微服务实战——SpringCache 整合 Redis
java·redis·后端·微服务
Cikiss1 小时前
微服务实战——平台属性
java·数据库·后端·微服务
OEC小胖胖1 小时前
Spring Boot + MyBatis 项目中常用注解详解(万字长篇解读)
java·spring boot·后端·spring·mybatis·web
2401_857617622 小时前
SpringBoot校园资料平台:开发与部署指南
java·spring boot·后端
计算机学姐2 小时前
基于SpringBoot+Vue的在线投票系统
java·vue.js·spring boot·后端·学习·intellij-idea·mybatis
一休哥助手2 小时前
Redis 五种数据类型及底层数据结构详解
数据结构·数据库·redis
Yvemil73 小时前
MQ 架构设计原理与消息中间件详解(二)
开发语言·后端·ruby
盒马盒马3 小时前
Redis:zset类型
数据库·redis