做后端开发这几年谁没被 Redis 内存逼疯过几回。线上缓存明明设了过期时间内存却一路飙到 maxmemory紧接着就是写入报错、告警轰炸还有更诡异的key 明明还没到期却被“提前”清空了业务拿回一个 null 查了半天数据。这两个问题其实都指向 Redis 最基础也最容易被轻描淡写带过的两个机制过期删除策略和内存淘汰策略。很多人把这两件事混为一谈以为“key 过期了就该被删、内存满了就该淘汰”但对底层细节一无所知。这篇是 Redis 系列第十七篇我把这两块一次性讲透底层怎么运作、八种淘汰策略各自的应用场景、maxmemory 相关参数的配置逻辑以及我在实际项目里踩过的坑和排查套路。不管你是刚接触 Redis 的新手还是已经被内存告警按在地上摩擦过的老伙计这篇都能给你一套可以直接落地的思路。1. 先搞清楚过期删除和内存淘汰不是一回事1.1 两个机制的分工很多人默认认为“过期 key 会被自动删除、不需要管”这话没毛病但删除的时机和方式大有讲究。Redis 对过期 key 的处理靠的是两套独立机制过期删除策略决定“到期的 key 什么时候真正被释放”内存淘汰策略决定“内存打满之后哪些 key 先被牺牲”。过期删除只针对设置了 TTL 的 key内存淘汰针对的是整体内存水位只要达到 maxmemory 上限就会触发跟 key 有没有设置过期时间没有必然关系——具体看策略是 volatile 系列还是 allkeys 系列。拿生活场景类比一下就非常清晰过期删除像冰箱里的保质期检查菜坏了、过期了你随手把它扔了内存淘汰像冰箱容量不够时你要决定把哪些东西先扔出去——是扔放了好几天没动的剩菜LRU扔不常吃的酱料LFU还是随手乱扔Random。两条规则同时生效但决策逻辑完全不同。如果只懂其中一个遇到内存问题一定是一头雾水。1.2 你以为的“到期即删”并不存在新手最容易踩的坑就是以为 TTL 归零的那一刻key 就从内存里消失了。实际上 Redis 并不保证“到期瞬间删除”它只保证“到期之后这个 key 对你不可见”。也就是说你去 GET 一个已过期的 key 会得到 nil但这块内存可能还占着直到惰性删除或定期删除真正把它清掉。这个认知非常关键否则排查内存问题时你会被“明明 key 都过期了used_memory 怎么还不降”这种事活活绕晕。Redis 的一切设计都在 CPU 开销和内存回收之间做折衷过期删除也不例外。2. 过期删除策略Redis 如何清理到期的 key2.1 惰性删除访问时才动手惰性删除的逻辑非常直白每次在执行读写命令访问某个 key 之前Redis 会先检查它是否在 expires 字典里并且是否已过期。如果过期了先删除这个 key再继续执行后续逻辑。这就像你冰箱里的菜只有你打开冰箱想拿它的时候才发现它坏了、扔掉。好处显而易见CPU 开销极小不访问就不处理对性能几乎没有任何影响。坏处同样明显如果一个过期的 key 长期不被访问它就会一直占着内存直到内存彻底吃紧。所以 Redis 不可能只靠惰性删除必须配合主动清理机制。这里还要注意一个细节惰性删除不只是对 GET、SET 这类普通命令生效像 EXISTS、TTL 这类元数据命令也会触发检查。如果你只是想知道一个 key 还在不在用 EXISTS 也会顺带把它清理掉这在排查线上问题时需要心里有数。2.2 定期删除后台巡逻队为了弥补惰性删除的“懒”Redis 的 serverCron主循环定时任务会周期性启动 activeExpireCycle从 expires 字典里抽样扫描过期 key。整体流程是这样的从 expires 字典里随机抽取一批 key默认 20 个逐个检查这批 key 是否已过期过期的直接删除如果这批 key 里过期比例超过 25%说明当前过期密度高继续重复新一轮扫描如果比例低于 25%本轮结束等下一个周期再跑。serverCron 的执行频率由 hz 参数控制默认值是 10也就是每秒执行 10 次。注意这里说的是“每秒最多 10 轮扫描”每一轮里具体扫多少、扫多久还要受 CPU 时间预算限制。所以定期删除并不是全量扫描而是抽样式推进目的就是把 CPU 开销摁在一个可控范围内。Redis 7.x 对定期删除做了进一步优化引入了更细粒度的 CPU 限流机制整体比老版本平滑很多。如果你是 5.x 升级上来的老用户能明显感受到大量 key 同时过期时的卡顿现象有所缓解。2.3 双管齐下也有短板有了惰性 定期这套组合过期 key 基本能在可接受的时间窗口内被清理干净。但两个场景还是会出现问题。第一个场景大量 key 在同一秒过期。比如你缓存了一批数据统一设置 1 小时过期那么整点那一刻Redis 要处理的过期 key 数量会瞬间激增。activeExpireCycle 会因此连续执行多轮扫描CPU 出现明显尖峰命令延迟也跟着抖。第二个场景过期 key 占比很大而定期删除来不及清完。这时候过期 key 虽然逻辑上已经不可见但物理内存迟迟不释放导致 used_memory 虚高。如果此时内存水位又逼近 maxmemory淘汰策略就会插手把没来得及删除的 key 当成可牺牲对象处理掉。所以实践里很反直觉的一点是过期时间不是设得越整齐越好反而要刻意加随机抖动让过期时间分散开。这个操作听着简单能少踩一半的缓存雪崩坑。3. 内存淘汰策略内存满了之后谁能活3.1 触发前提maxmemory 门槛内存淘汰不是默认开启的。Redis 64 位系统的 maxmemory 默认值是 0代表不限制内存使用。也就是说如果你什么都不配置Redis 不会主动约束自己内存会一路吃上去直到操作系统 OOM 把它杀掉。生产环境必须显式设置上限写在 redis.conf 里maxmemory 4gb也可以在线调整不用重启CONFIG SET maxmemory 4gb有个经典误区特别值得说很多人以为 maxmemory 的单位是 MB实际上 Redis 配置允许带单位4gb、4096mb都行不带单位时就是裸字节。我见过有人写maxmemory 4096结果 Redis 只允许用 4KB 内存整个服务瞬间写不进去任何数据现场直接雪崩。这种错误真不是段子是真实生产事故。3.2 八种淘汰策略逐一拆解从 Redis 4.0 起淘汰策略一共 8 种由 maxmemory-policy 配置指定。先上总览表策略作用范围淘汰依据典型场景noeviction无不淘汰写入报错数据禁丢、强一致场景allkeys-lru全部 key最近最少使用通用缓存最常用volatile-lru仅设了 TTL 的 key最近最少使用缓存 持久数据混合allkeys-random全部 key随机访问均匀、无明显热点volatile-random仅设了 TTL 的 key随机热点不明显的临时数据volatile-ttl仅设了 TTL 的 key剩余 TTL 最短优先保留新写入数据allkeys-lfu全部 key最不常使用热点集中、长尾明显的访问volatile-lfu仅设了 TTL 的 key最不常使用热点集中的过期数据逐个说清楚背后的逻辑不然后面选型就是瞎蒙。noeviction 是 Redis 出厂默认策略。内存达到上限后所有会导致内存增长的写命令SET、LPUSH、ZADD 等都会返回OOM command not allowed when used memory maxmemory读命令照常服务。这个策略适合不允许任何淘汰、宁可报错也不能丢数据的场景比如存分布式锁、存关键配置。代价是你必须严格控制写入量不然服务会频繁拒绝写入相当于给自己加了一道紧箍咒。allkeys-lru 是目前最通用的缓存策略。所有 key 一视同仁内存吃紧时优先淘汰“最近最少被访问”的 key。对大多数“缓存一切”的业务这是最省心的选择也是我在纯缓存场景下的首选。volatile-lru 和 volatile-ttl 只针对设置了过期时间的 key。它们有一个非常隐蔽的隐患如果业务里存在大量“永不过期”的 key那么内存打满时被淘汰的永远只是那部分设了 TTL 的缓存 key持久 key 稳如泰山。反过来看这也是一种保护手段适合内存里混合存放“缓存数据”和“强一致数据”的场景。allkeys-random 和 volatile-random 就更好理解了。访问模式特别均匀、没有热点时随机淘汰能绕开 LRU 近似算法的误差而且开销最小。说实话我日常几乎不用但它确实在某些特殊负载下比 LRU 合理因为 LRU 依赖采样近似对“所有 key 访问频率差不多”的场景反而可能误判。allkeys-lfu 和 volatile-lfu 是 Redis 4.0 加入的。LFU 统计的是“访问频率”而不是“最近访问时间”。这解决了 LRU 一个经典缺陷某个 key 曾经被高频访问但已经很久没用了按 LRU 它会被优先淘汰而按 LFU 它的历史热度很高会被保留。反过来如果一个 key 刚被访问一次LRU 会认为它很“新”从而保它LFU 则认为它频率太低、应该被淘汰。这里有个关键细节LFU 不是绝对计数而是用了近似实现。它通过一个对数递增的计数器记录访问频次配合衰减因子让老热度随时间下降具体由 lfu-log-factor 和 lfu-decay-time 两个参数控制。前者控制计数器增长速度后者控制多少分钟没访问就衰减一次。生产环境基本不需要动这两个参数但你要知道它们存在否则观察 LFU 表现时你会看不懂为什么某个高频 key 会被淘汰。3.3 LRU 和 LFU 的“近似”不是玄学需要澄清一个被反复误解的点Redis 的 LRU 并不是教科书里那种严格 LRU。它不会维护一个全量的“访问时间排序链表”而是采用采样近似。每次需要淘汰时Redis 从内存里随机抽取 maxmemory-samples 个 key默认 5 个比较它们的空闲时间idle time淘汰掉最久没被访问的那个。采样数量决定了近似精度采样越多淘汰结果越接近真实 LRU但抽取和比较本身也有 CPU 开销。实测中把 maxmemory-samples 调到 10淘汰准确度在绝大多数工作负载下已经很接近真实 LRU 了。LFU 同理靠的是记录每个 key 的访问频率字段再用衰减和裁剪模拟出“近期使用频率”的排序。所以网上有人争论“Redis 的 LRU 不准确”这其实不是 bug是设计上的故意折衷。全量排序的 LRU 需要大量额外内存和时间来维护对 Redis 这种主打高性能的内存数据库来说不划算抽样近似是性价比最优的解。理解这一点你就不会在调优时钻牛角尖也不会迷信某些“百分百精确 LRU”的第三方方案。4. 配置参数与业务场景选型4.1 核心配置项一览除了 maxmemory 和 maxmemory-policy还有几个配套参数会直接影响淘汰行为整理成表配置项默认值作用maxmemory0不限制内存使用上限maxmemory-policynoeviction淘汰策略maxmemory-samples5LRU/LFU/TTL 近似算法的采样数maxmemory-eviction-tenacity10Redis 7.0淘汰执行强度0~10lfu-log-factor10LFU 计数器增速因子lfu-decay-time1LFU 计数器衰减周期分钟maxmemory-eviction-tenacity 是 Redis 7.0 新增的参数控制内存到达上限后淘汰循环对命令延迟的影响程度。值调低Redis 每处理一批命令只做更克制的淘汰命令延迟更稳定但内存回落变慢值调高淘汰更激进内存能快速降下来但可能带来延迟抖动。默认 10 表示按原有的快速清退方式处理。如果业务对尾延迟极敏感可以实验性调低观察 evicted_keys 曲线和延迟指标再做决定。在线查看当前生效配置用这几个命令CONFIG GET maxmemory CONFIG GET maxmemory-policy CONFIG GET maxmemory-samples INFO memory4.2 不同场景怎么选我给自己定的选型原则很简单先问一句“这个 Redis 里到底存的是什么”。纯缓存场景比如给数据库查询结果做缓存、给接口响应做缓存选 allkeys-lru 或 allkeys-lfu。热点数据集中、访问频率差异很大、长尾明显的用 lfu热点随着时间迁移、今天热明天冷的用 lru。缓存和持久数据混合场景比如缓存 分布式锁、缓存 队列任务锁和队列数据不能丢用 volatile-lru 或 volatile-ttl把不可丢的数据设为永不过期淘汰永远只落在缓存数据上。这种“无 TT L 保护伞”的思路比在代码里加各种判断要干净得多。数据绝对不允许丢、宁肯暂时不写入也不淘汰用 noeviction同时必须配套内存监控告警。这个策略本质上不是给正常业务用的它是一个安全阀防止错误配置导致数据大面积无声蒸发。还有一个常见的组合操作全局用 allkeys-lru但对个别核心 key 可以用 OBJECT idletime 观察空闲情况必要时用一次触摸或重写来刷新它的热度。注意Redis 没有“给单个 key 设置不准淘汰”的属性这是很多人的认知误区。4.3 配置失误的典型后果选错策略或者没设 maxmemory后果是实打实的我讲一个真实案例。某个团队把 Redis 当成消息队列用list 无限增长maxmemory 没设结果系统内存耗尽后操作系统直接把 Redis 进程 OOM Kill 了。重启后 RDB 恢复瞬间内存就要打满又触发新一轮淘汰大量未消费的队列消息被随机策略无差别清掉业务丢消息丢得莫名其妙。这个事故本质上犯了两层错第一没设 maxmemory让 Redis 一路吃到 OOM第二恢复后的淘汰策略不区分业务数据把队列消息也当缓存清掉了。如果当时用 noeviction 显式告警消息至少不会默默蒸发业务能及时感知并介入。另一个高频错误选了 volatile-* 系列策略但代码里习惯性给所有 key 都设过期时间结果所有数据全被当成“可淘汰对象”。一旦内存打满、缓存集中失效核心数据也跟着大面积被清掉。罪魁祸首就是“无脑全设 TTL”的坏习惯。正确做法是写代码前先明确每个 key 是纯缓存还是持久数据再决定要不要设置过期时间。5. 踩坑记录与排查实战5.1 高频问题与定位思路问题一key 明明还没到过期时间却查不到或者过期了却偶尔还能查到。先说后者。主从复制架构下主节点删除过期 key 时会向从节点发送 DEL 命令所以从节点的删除在时间上是滞后的。如果客户端读的是从节点就可能短暂读到已过期数据。Redis 5.0 起从节点返回过期 key 时会为了逻辑一致性返回 nil但物理删除仍依赖主节点的 DEL 命令。排查长尾过期数据时一定要结合主从拓扑来看别只盯着单节点。问题二设置了过期时间内存却不释放。前面已经解释过惰性删除 定期删除都不是即时全量清理大量过期 key 没有被访问、定期抽样又没抽中内存就“虚高”了。此时你可以手动排查用 SCAN 配合 TTL 找出已过期但仍占内存的 key再用 UNLINK 异步删除清理。UNLINK 不会阻塞主线程适合大批量清理场景。问题三写入报OOM command not allowed。这是 noeviction 策略 内存打满的标准表现。先用 INFO memory 看 used_memory 和 maxmemory 的关系再配合redis-cli --bigkeys扫大 key优先处置大对象。千万别一上来就重启重启不等于解决内存问题RDB 加载回来内存一样打满问题只会换个姿势再来一遍。5.2 监控与工具链排查内存问题我习惯按这个顺序来INFO memory INFO stats redis-cli --bigkeys redis-cli --memkeysINFO memory 里重点看 used_memory、used_memory_peak、maxmemory 和 mem_fragmentation_ratio。碎片率长期大于 1.5说明内存碎片问题严重要考虑开启 activedefrag 让它热整理。INFO stats 里重点看 evicted_keys 和 expired_keys 两个计数。evicted_keys 持续快速上升说明淘汰在频繁发生要么内存不够用要么缓存命中率在崩expired_keys 平稳增长是正常现象突然暴增则说明大量 key 在同一时刻过期大概率是过期时间设置得太齐整了。观察单个 key 可以用 OBJECT 命令OBJECT freq key查看 LFU 访问频率OBJECT idletime key查看空闲秒数。结合这两个值和当前策略就能定位一个 key 是不是“淘汰嫌疑人”。5.3 一次线上内存告警复盘挑一次典型的线上排查过程说。当时一个 4G 的实例 used_memory 逼近上限evicted_keys 每分钟上千缓存命中率肉眼可见地往下掉。我第一反应不是扩内存而是先搞清楚谁在写入。用 INFO keyspace 看各库 key 数量发现某个业务库 key 数量不算夸张但 INFO memory 显示 used_memory 异常高。接着用--bigkeys扫了一遍发现一个 value 高达 300MB 的 hash。顺藤摸瓜查代码发现是那边把大报文直接塞进了 hash 的某个 field一次写入就是几个 MB。在 allkeys-lru 策略下大量小 key 频繁被淘汰、正常缓存不断失效而那个大 key 因为体积太大很难被完全淘汰出去形成恶性循环。处理方案分三步第一把大报文拆出去改用独立对象存储并做分片第二给每个小 key 设置合理的过期时间并加随机抖动第三把 maxmemory-samples 从 5 调到 10降低淘汰误判率。改完再观察evicted_keys 掉到个位数命中率恢复内存水位也稳住了。这个案例最值得记的一点allkeys-lru 不是万能的它只负责决定淘汰哪个 key根本不管 key 的体量。业务上不控制 key 的大小再好的淘汰策略都白搭。6. 从实践里提炼的几条通用建议6.1 过期时间别“一刀切”批量设置过期时间时我习惯在基础值上乘一个 0.8~1.2 的随机系数或者加一个固定抖动区间。比如基础过期 3600 秒实际设置就在 2880 到 4320 秒之间随机取。这样极端峰值出现的时间会被打散从根源上缓解缓存雪崩和定期删除的 CPU 尖峰。这个技巧成本极低收益非常明显。6.2 删 key 优先用 UNLINK很多人还在用 DEL 删大 key这是真亏。DEL 是同步删除一个几 MB 的 string 可能让 Redis 阻塞几十毫秒甚至更久UNLINK 把内存释放动作丢到后台线程主线程不卡。Redis 4.0 起 UNLINK 就可用日常开发中凡是可能删大 key 的地方我都建议直接用 UNLINK几乎没有副作用。6.3 配置变更要谨慎落地线上调整 maxmemory-policy 之前先确认 redis.conf 可写再用 CONFIG SET 临时修改观察指标确认没问题后执行 CONFIG REWRITE 固化。别直接在配置文件上改完就 restart那会把 RDB 恢复、重启预热这些变量全搅进排查过程问题定位难度直接翻倍。另外CONFIG SET 是即时生效的操作前要确认当前实例的配置基线免得改错了还要花时间回滚。7. 与过期、淘汰强相关的几个延伸话题7.1 键空间通知的事件延迟如果你的业务需要监听 key 过期事件比如订单超时关单用的是 keyspace notifications 的 expired 事件。但要注意Redis 的过期事件不是 TTL 归零那一刻发布的而是删除动作真正发生时才会发布。惰性删除发生在访问时定期删除发生在扫描到的那一轮所以事件天然有延迟。高精度关单业务别把所有希望押在这上面延迟不可控。如果必须用要评估事件延后、偶发丢失对业务的影响最好配合其他补偿机制。7.2 持久化与主从复制下的差异RDB 持久化时已过期的 key 不会写进 dump 文件AOF 持久化时key 过期后会在合适时机追加 DEL 命令。主从复制场景下过期删除以主节点为准从节点的清理依赖主节点发来的 DEL 命令。所以从 RDB 恢复数据时理论上不会恢复已过期 key但在主从切换、故障恢复这类边界场景里从节点可能短暂保留过期数据。做灾备演练时这类细节要提前设计好。7.3 托管实例的默认策略陷阱不少云厂商的托管 Redis 会把 maxmemory-policy 默认设成 allkeys-lru 或 volatile-lru方便客户开箱即用。但如果你在同一个实例里混存了缓存数据和业务队列数据默认的 allkeys 策略可能会把队列数据当普通 key 淘汰掉造成消息丢失。拿到新实例的第一件事就是确认 maxmemory-policy 到底是什么而不是等线上丢数据了才回头查。8. 最后说点实在的我在实际维护 Redis 的过程中最大的体会是内存淘汰和过期删除这两个机制拼的不是“背下八种策略的名字”而是想清楚自己每一类数据的生命周期和重要程度。你给 key 设的每个 TTL、给实例设的每个 maxmemory 数值本质都是在和 Redis 签一份“内存优先权契约”。谁优先、谁垫底都应该在业务设计阶段就明确而不是等告警来了再救火。我建议每个团队在 Redis 上线前把策略选型、TTL 规范、大 key 治理这三件事定成铁律能省掉无数个深夜。最后再分享一个小技巧每次处理完这类内存问题我都习惯把 INFO memory、evicted_keys、expired_keys 这几个关键指标存档配上时间点和处理备注。攒上几个月你就能摸清自己业务的内存波动规律很多问题还没变成告警你就能提前预判到。这种手感比任何监控平台里的花哨大盘都好使。