【Redis】Redis——过期键删除策略、内存淘汰8种策略、LRU/LFU实现

文章目录Redis——过期键删除、内存淘汰、LRU/LFU实现一、核心概念前置区分90%使用者的混淆点二、Redis 过期键删除策略2.1 过期键的底层存储2.2 行业通用的3种过期删除策略2.3 Redis 实际采用的组合策略惰性删除 定期删除2.3.1 惰性删除实现细节2.3.2 定期删除实现细节2.4 特殊场景下的过期键处理三、Redis 内存淘汰8种策略全解3.1 内存淘汰的触发条件与核心配置3.2 8种淘汰策略的结构化分类与详解3.2.1 不淘汰类策略1种3.2.2 全键空间淘汰类策略3种3.2.3 过期键空间淘汰类策略4种3.3 高频踩坑点与策略选型建议四、Redis LRU/LFU 算法深度实现4.1 核心载体RedisObject 结构4.2 LRULeast Recently Used最近最少使用算法实现4.2.1 标准LRU算法原理与缺陷4.2.2 Redis 近似LRU实现原理4.2.3 核心配置与优化细节4.3 LFULeast Frequently Used最不经常使用算法实现4.3.1 标准LFU算法原理与缺陷4.3.2 Redis 近似LFU实现原理4.0新增4.3.3 核心配置与优化细节4.4 LRU vs LFU 核心对比与选型五、全体系实战最佳实践六、高频面试考点总结Redis——过期键删除、内存淘汰、LRU/LFU实现一、核心概念前置区分90%使用者的混淆点特性过期键删除策略内存淘汰策略核心目标清理已到过期时间的键释放无效内存当Redis内存达到maxmemory上限时主动选键删除保障写入可用触发条件键设置了过期时间且已到期与内存使用率无强制关联Redis已用内存 ≥ 配置的maxmemory上限与键是否过期无强制关联执行优先级前置执行是内存管控的第一道防线后置兜底过期键清理后内存仍超限才会触发处理范围仅处理设置了过期时间的键可配置为处理全量键/仅过期键二、Redis 过期键删除策略2.1 过期键的底层存储Redis在每个数据库redisDb结构中通过**expires字典**专门存储键的过期时间字典key指向数据库键的指针无额外内存冗余字典value键的过期时间戳毫秒级Unix时间戳优势判断键是否过期、获取过期时间的时间复杂度为O(1)2.2 行业通用的3种过期删除策略策略核心逻辑优点核心缺陷定时删除设置过期时间时同步创建定时器到期立即删除键内存极致友好到期立即释放内存CPU极不友好大量过期键会占用主线程CPU严重影响Redis响应性能惰性删除键到期不主动删除仅当客户端访问该键时检查并删除过期键CPU极致友好仅访问时才做处理无额外CPU开销内存极不友好大量冷过期键永不被访问造成内存泄漏定期删除每隔固定时间抽取部分过期键检查删除其中已到期的键折中CPU与内存可通过配置调整执行频率和力度难以精准平衡频率过高耗CPU频率过低内存泄漏2.3 Redis 实际采用的组合策略惰性删除 定期删除Redis单线程架构决定了无法使用定时删除最终采用惰性删除为基础、定期删除为兜底的组合方案平衡CPU与内存开销。2.3.1 惰性删除实现细节触发时机所有访问键的命令GET/MGET/HGET等执行前都会调用expireIfNeeded函数核心执行逻辑检查键是否存在于expires字典无过期时间直接放行检查键是否已过期未过期直接放行已过期主库同步/异步删除键4.0lazyfree机制对大键异步删除避免主线程阻塞并向AOF/从库追加DEL命令返回nil主从一致性约束从库永远不会主动执行惰性删除即使键已过期访问时也仅返回过期状态必须等待主库同步DEL命令后才会删除3.2版本从库访问过期键会返回nil但仍不执行删除2.3.2 定期删除实现细节触发频率由redis.conf的hz参数控制默认10即每秒执行10次单次间隔100ms取值范围1-500值越高清理越及时CPU开销越大自适应执行逻辑遍历0-15号数据库逐个库从expires字典随机抽取20个带过期时间的键检查并删除抽取结果中已过期的键若本次抽取的键中过期占比超过25%立即重复抽取-检查-删除流程单次执行设置硬时间上限不超过当前hz周期的25%如hz10时单次最多执行25ms避免阻塞主线程内存紧张时自动进入慢模式提升清理频率和时长2.4 特殊场景下的过期键处理RDB持久化生成RDB文件时会跳过所有已过期的键载入RDB时主库跳过过期键从库全量载入等待主库同步DEL命令AOF持久化键过期被删除时会向AOF文件追加一条DEL命令AOF重写时会跳过所有已过期的键集群模式仅主节点执行过期键删除从节点完全同步主节点的DEL命令保障集群数据一致性三、Redis 内存淘汰8种策略全解3.1 内存淘汰的触发条件与核心配置触发条件客户端发送写入类命令时Redis检查已用内存若已用内存 ≥maxmemory配置上限则触发内存淘汰流程核心配置maxmemoryRedis最大可用内存上限单位字节生产环境建议设置为物理内存的50%-70%避免使用swap导致性能暴跌maxmemory-policy内存淘汰策略配置默认noevictionmaxmemory-samples淘汰算法采样数默认5值越大淘汰越精准CPU开销越高3.2 8种淘汰策略的结构化分类与详解8种策略可分为1种不淘汰策略7种淘汰策略淘汰策略按「淘汰范围」「淘汰算法」两个维度组合划分。3.2.1 不淘汰类策略1种noeviction默认策略核心逻辑内存达到maxmemory时所有会导致内存增加的写入命令SET/INCR/LPUSH等全部返回OOM错误仅只读命令GET/INFO等可正常执行适用场景绝对不允许数据丢失、有独立的降级容灾策略、仅提供只读服务的场景3.2.2 全键空间淘汰类策略3种淘汰范围数据库中所有键无论是否设置过期时间、是否已过期优先级最高无键可淘汰时降级为noeviction。策略核心逻辑适用场景allkeys-lru优先淘汰最近最少使用的键近似LRU算法业务有明显冷热数据区分80%请求集中在20%热点数据生产环境最常用的策略allkeys-lfu优先淘汰访问频率最低的键近似LFU算法4.0新增业务数据访问频率差异极大如电商爆款、热点新闻需精准保留高频访问数据避免冷数据污染缓存allkeys-random完全随机淘汰任意键所有键访问概率完全均等的特殊场景生产环境极少使用3.2.3 过期键空间淘汰类策略4种淘汰范围仅针对设置了过期时间的键无论是否已到期若当前库无带过期时间的键直接降级为noeviction高频踩坑点。策略核心逻辑适用场景volatile-lru仅在过期键中优先淘汰最近最少使用的键需要永久保留核心数据如配置、用户基础信息仅允许淘汰带过期时间的缓存数据volatile-lfu仅在过期键中优先淘汰访问频率最低的键4.0新增既要保留永久核心数据又需精准淘汰低频访问的缓存数据volatile-random仅在过期键中完全随机淘汰键极少使用仅适用于过期键访问概率完全均等的场景volatile-ttl仅在过期键中优先淘汰剩余TTL最短的键业务有明确的过期优先级希望优先淘汰即将到期的键3.3 高频踩坑点与策略选型建议高频踩坑点使用volatile-xxx系列策略时若库中无带过期时间的键内存超限后会直接拒绝所有写入从库不会主动执行内存淘汰必须与主库配置相同的maxmemory否则会出现从库OOM未配置maxmemory时32位Redis默认最大内存3GB64位Redis无上限会耗尽服务器内存触发OOM选型优先级建议首选allkeys-lru绝大多数有冷热区分的业务场景最优解次选allkeys-lfu热点数据集中、访问频率差异大的场景特殊场景需保留永久键时选择volatile-lru/volatile-lfu非特殊需求禁止使用random/ttl/noeviction策略四、Redis LRU/LFU 算法深度实现4.1 核心载体RedisObject 结构Redis中每个键值对的value都封装为redisObject其中24位的lru字段是LRU/LFU算法的核心载体无需额外数据结构极致节省内存typedefstructredisObject{unsignedtype:4;// 数据类型unsignedencoding:4;// 编码格式unsignedlru:24;// LRU时间戳 / LFU的ldtlogcintrefcount;// 引用计数void*ptr;// 指向实际数据的指针}robj;4.2 LRULeast Recently Used最近最少使用算法实现4.2.1 标准LRU算法原理与缺陷核心原理最近被访问的数据未来被访问的概率更高内存不足时淘汰最久未被访问的数据标准实现哈希表 双向链表哈希表记录键与链表节点的映射链表按访问时间排序访问时将节点移至表头淘汰时删除表尾节点核心缺陷额外内存开销大需维护双向链表频繁的链表节点移动操作单线程下CPU开销高缓存污染一次性批量访问的冷数据会挤出长期热点数据导致缓存命中率暴跌4.2.2 Redis 近似LRU实现原理Redis放弃了严格LRU采用随机采样候选池的近似LRU方案在性能和命中率之间做到极致平衡。核心基础redisObject的24位lru字段存储键最后一次被访问的秒级Unix时间戳24位可覆盖194天循环使用执行流程3.0优化版内存超限触发淘汰时按maxmemory-samples配置随机采样对应数量的键维护一个大小为16的候选池池内按键的lru时间升序排序最久未访问的在前采样的键仅当lru时间早于池内最小时间或池未满时才会被加入候选池从候选池中选出lru时间最早的键执行淘汰重复流程直到内存降至maxmemory以下核心优势无需额外数据结构内存开销极低无链表操作CPU开销极小maxmemory-samples10时命中率已与标准LRU几乎一致4.2.3 核心配置与优化细节maxmemory-samples默认5生产环境追求命中率可调整至10不建议超过10避免CPU开销激增访问优化键的lru时间与当前时间差小于1秒时不会更新lru字段避免频繁更新带来的CPU开销3.0候选池优化解决了旧版本单次采样的局限性实现跨轮次的键对比大幅提升淘汰精准度缓解缓存污染问题4.3 LFULeast Frequently Used最不经常使用算法实现4.3.1 标准LFU算法原理与缺陷核心原理访问频率越高的数据未来被访问的概率越高内存不足时淘汰访问次数最少的键标准实现为每个键维护访问计数器访问时计数1淘汰时删除计数最小的键核心缺陷内存开销大需为每个键维护计数器无法适配访问模式变化历史热点数据长期不访问计数仍居高不下难以被淘汰缓存预热问题新的热点数据刚进入时计数低极易被淘汰计数排序开销大单线程下性能瓶颈明显4.3.2 Redis 近似LFU实现原理4.0新增Redis复用redisObject的24位lru字段拆分为两部分实现LFU同时通过对数计数器周期衰减机制解决标准LFU的核心缺陷。24位字段拆分高16位ldtLast Decrement Time单位分钟记录上一次计数器衰减的时间戳低8位logcLogistic Counter访问频率计数器最大值255核心机制1对数增长计数器解决8位计数器无法区分高频访问的问题采用基于概率的对数增长逻辑而非线性增长核心规则计数器值越小增长越快值越大增长越慢。lfu_log_factor越大计数器增长越慢对访问频率的区分度越高源码级增长逻辑每次访问时生成0-1的随机数仅当随机数小于1/(counter * lfu_log_factor 1)时计数器才1默认lfu_log_factor10时计数器达到255需要百万次以上访问核心机制2周期衰减机制解决历史热点数据无法淘汰的问题计数器会随时间周期衰减核心规则每次访问/采样时计算当前时间与ldt的差值除以lfu_decay_time得到衰减次数计数器max(counter - 衰减次数, 0)同时更新ldt为当前时间默认lfu_decay_time1即每分钟衰减1次10分钟未访问的键计数器至少衰减10新键友好优化新创建的键计数器初始值为5LFU_INIT_VAL而非0避免新键刚进入就因计数过低被淘汰解决缓存预热问题淘汰执行流程内存超限触发淘汰时按maxmemory-samples随机采样对应数量的键对采样键执行计数器衰减更新logc和ldt将采样键加入候选池按计数器值升序排序从候选池中选出计数器值最小的键执行淘汰重复流程直到内存降至maxmemory以下4.3.3 核心配置与优化细节lfu-log-factor默认10取值范围0-100高频访问场景可适当调大提升频率区分度lfu-decay-time默认1单位分钟访问模式变化快的场景可适当调小加快衰减速度快速适配新的热点数据4.4 LRU vs LFU 核心对比与选型维度近似LRU近似LFU核心判断依据最后一次访问的时间历史访问频率 时间衰减缓存污染抗性弱批量冷数据易挤出热点数据强单次访问几乎不会提升计数器冷数据难以污染缓存新数据友好度高新访问数据直接更新lru时间不易被淘汰中初始值5需积累访问次数才能避免被淘汰访问模式适配适合冷热区分明显、访问模式稳定的场景适合访问频率差异大、访问模式频繁变化的场景Redis版本支持全版本支持4.0及以上版本支持五、全体系实战最佳实践基础配置必做必须设置maxmemory生产环境不超过物理内存的70%hz参数默认10高并发场景可调至20-50禁止超过100淘汰策略选型绝大多数场景首选allkeys-lru热点集中、访问频率差异大的场景选allkeys-lfu需保留永久键的场景选volatile-lru/volatile-lfu性能优化maxmemory-samples默认5追求命中率可调至10开启lazyfree-lazy-eviction/lazyfree-lazy-expire避免大键删除阻塞主线程主从集群规范主从节点maxmemory、淘汰策略、过期相关配置必须完全一致禁止在从节点执行大量写入避免从库OOM过期键规范避免大量键设置相同的过期时间导致定期删除集中执行阻塞主线程建议给过期时间增加随机偏移量六、高频面试考点总结请区分Redis过期键删除策略和内存淘汰策略的核心差异Redis过期键删除为什么采用惰性定期的组合策略而不用定时删除Redis的8种内存淘汰策略分别是什么生产环境如何选型Redis为什么不实现严格的LRU而是用近似LRU3.0对LRU做了什么优化Redis的LFU是如何实现的如何解决标准LFU的历史热点和缓存预热问题主从架构下Redis的过期键删除和内存淘汰有什么特殊约束使用volatile-lru策略时内存满了但没有淘汰任何键反而拒绝写入是什么原因