当前位置: 首页 > news >正文

Redis删除策略、淘汰策略

  • 概要
  • 一、删除策略:
    • 1、惰性删除:
    • 2、定时删除:
    • 3、定期删除:
    • 4、惰性删除 + 定期删除:
  • 二、淘汰策略:
    • 1、noeviction:
    • 2、volatile-*:
    • 3、allkeys-*:
    • 4、参数调优:

概要

redis删除策略、淘汰策略

删除策略主要为:

  • 惰性删除(被动清理)
  • 定时删除(纯理论)
  • 定期删除(主动清理)
  • 惰性删除 + 定期删除

淘汰策略主要有八种:

  • 默认策略:不操作
  • volatile-*:四种
  • allkeys-*:三种

一、删除策略:

删除策略聚焦于到期键的主动/被动删除

1、惰性删除:

被动清理到期键

  • 核心逻辑:仅在访问时发现键过期时进行删除,若键未过期,则返回值。
  • 优点:只在必要时进行删除,避免无意义的扫描。
  • 缺点:可能导致过期键长期存在,占用内存空间(比如一个键永远不会被访问,则该键永远不会被删除,引发内存泄漏)

2、定时删除:

  • 核心逻辑:在设置过期时间时,同时设置一个timer,timer会在过期时间到达时,立即触发删除操作,将过期键从内存中移除。
  • 优点:内存利用率极高,无过期键残留。
  • 缺点:CPU开销极大,阻塞主线程。

纯理论的理想策略,redis并未采用。

不采用原因:redis核心是单线程,即使引入了IO多线程,主线程仍是单线程,定时器回调会阻塞。

3、定期删除:

主动清理到期键

  • 核心逻辑:redis会启动一个周期性的定时任务(默认100ms执行一次),每次在过期字典中随机抽样N个键(默认为20个)进行检查和删除。
  • 执行流程:
    • ①从「过期字典」(保存所有带过期时间的键)中抽取N个键
    • ②遍历N个键,删除其中已过期的键
    • ③计算过期键占抽样键的比例,若 过期键/抽样键 > 25% ,则重复步骤①;
    • ④单次任务执行不超过 「时间上限」,默认为25ms,避免阻塞主线程。

4、惰性删除 + 定期删除:

redis实际采用 惰性删除 + 定期删除 的混合模式。

  • 定期删除用于主动删除,惰性删除用于兜底。
  • 若开启了持久化,过期键的处理还会结合持久化规则(如:RDB生成时跳过过期键,AOF重写时删除过期键)

二、淘汰策略:

淘汰策略聚焦于内存达到上限时的键的淘汰。

  • 指定策略使用:如maxmemory-policy noeviction进行配置

补充说明:

  • LRU并非严格实现,redis的LRU是近似LRU,默认抽取5个键选最久未使用的,通过maxmemory-samples参数进行配置,越大越接近严格LRU,但是CPU开销越大。
  • LFU原理:基于访问频率淘汰,每个KEY维护一个计数器,访问时递增,随时间衰减,最终淘汰计时器最小的KEY,比LRU更适合高频访问保留的场景。
  • 淘汰优先级:若volatiole-*策略中无过期键可以删除,则退化为noeviction策略(拒绝写操作)。
  • maxmemory设置:默认为0,若不设置,redis不会触发淘汰机制,生产环境必须根据内存大小配置。

1、noeviction:

  • 默认策略
  • 核心逻辑:内存满时拒绝所有写操作,返回OOM错误

2、volatile-*:

  • volatile-ttl:从设置了过期时间的KEY中,选择剩余时间最少的KEY
  • volatile-lru:从设置了过期时间的KEY中,选择最久未使用的KEY
  • volatile-lfu:从设置了过期时间的KEY中,选择使用频率最低的KEY
  • volatile-random:从设置了过期时间的KEY中,随机选择一个KEY

3、allkeys-*:

  • allkeys-lru:从所有KEY中,选择最久未使用的KEY
  • allkeys-lfu:从所有KEY中,选择使用频率最低的KEY
  • allkeys-random:从所有KEY中,随机选择一个KEY

4、参数调优:

  • maxmemory:设置为内存上限的70%-80%,如内存16GB,设置maxmemory 12GB
  • maxmemory-samples:通用场景设置为10;高精度场景设置为20~30;CPU敏感场景设置为5。
  • maxmemory-policy
    • 通用缓存:maxmemory-policy allkeys-lru,优先保留最近使用的KEY
    • 高频访问:maxmemory-policy allkeys-lfu,优先保留访问最多的KEY
    • 仅清理临时数据(如验证码):maxmemory-policy volatile-lru,只淘汰带过期时间的KEY
    • 数据不可丢失(金融):maxmemory-policy noeviction,拒绝写操作,需要配合集群/持久化+监控,内存满时需要人工扩容
    • 简单测试/低价值数据:maxmemory-policy volatile-random,实现简单,CPU开销最低(仅适合非核心场景)
  • hz:默认值为10,即一秒执行10次,100ms执行一次,主线程定时任务执行频率,影响定期删除过期键和淘汰机制的执行及时性。
    • CPU敏感场景:保持默认。
    • 内存紧张/淘汰频繁:hz 20,设为20~50,提高定时任务频率。
    • 极端情况:hz 100,通常不会将hz设置>100。
  • dynamic-hz:默认为yes,开启。根据客户端连接数量自动调整后台任务执行频率,以配置的hz为基准动态调整。
  • LFU专属调优参数:
    • lfu-log-factor:默认值为10,值越低计数器增长速度越快。
      • 高频访问场景:lfu-log-factor 5,设为1~5,高频键与低频键快速拉开差距。
      • 普通访问场景:lfu-log-factor 10,保持默认。
      • 低频访问场景:lfu-log-factor 20,计数器增长缓慢,避免偶尔访问的键被误判为高频。
    • lfu-decay-time:默认值为1分钟,代表1分钟没有访问则衰减。
      • 短期热点数据:lfu-decay-time 1,设为1~5,热点快速衰减,如直播弹幕。
      • 长期热点数据:lfu-decay-time 60,设为10~60,高频键长期保留,如商品详情。
http://www.cnnetsun.cn/news/1878.html

相关文章:

  • Wan2.2-T2V-5B能否生成客户案例展示?销售转化助力
  • Wan2.2-T2V-5B是否提供监控面板?推理过程可视化工具介绍
  • C# 或成“2025 年度编程语言”,「黑马」R 语言杀回前十!TIOBE 12 月榜单发布
  • Wan2.2-T2V-5B能否用于教学演示视频自动制作?
  • Wan2.2-T2V-5B能否生成布料飘动?柔性体运动建模能力验证
  • Wan2.2-T2V-5B能否生成人物动作?实测走路和挥手场景
  • Wan2.2-T2V-5B能否生成疫情传播模拟?公共卫生科普
  • Wan2.2-T2V-5B API接入教程:三步集成到现有系统
  • Wan2.2-T2V-5B输出稳定性评测:是否存在闪烁或抖动?
  • Wan2.2-T2V-5B能否生成镜子反射效果?光学现象还原挑战
  • Wan2.2-T2V-5B为何成为中小团队视频生成首选?
  • 动态推理任务适应中持续学习的应用与优化
  • 提示工程架构师视角:Agentic AI如何让智能家居更贴心?
  • 企业估值中的人工智能赋能效果评估
  • 题目介绍:LeetCode 79. Word Search
  • 从文本到视频只需几秒:Wan2.2-T2V-5B的极致优化之道
  • Wan2.2-T2V-5B能否生成动物行为?宠物内容创作尝试
  • Wan2.2-T2V-5B能否生成昼夜变化效果?时间维度建模能力检验
  • vscode连接真机无法同步main.dart代码
  • 使用gsplat进行3D高斯泼溅的方案
  • 解决Chroma数据库中的RAG嵌入问题
  • 从Firebase Storage下载3D模型的进度显示
  • Bun 监控文件变化的终极指南
  • Wan2.2-T2V-5B助力营销创新:自动生成广告素材全流程
  • 那个说“TypeScript是多余的“的同事,昨晚又在改bug到凌晨
  • Wan2.2-T2V-5B技术亮点解读:为什么它适合实时生成
  • Wan2.2-T2V-5B推理速度优化技巧大全(附配置建议)
  • Wan2.2-T2V-5B能否生成钟表指针转动?精细动作控制能力评测
  • Wan2.2-T2V-5B能否生成碳足迹追踪?可持续发展报告
  • 用Wan2.2-T2V-5B生成广告短片,成本能省多少?