Redis处理大量瞬时过期数据的方法

Redis在处理大量瞬时过期key时并非直接卡死，而是会因定期删除机制（每100ms随机采样+高强度多轮扫描）引发CPU飙升、内存延迟释放和请求抖动，导致超时、READONLY误判等连锁故障；单纯加随机偏移或依赖惰性删除并不够，真正有效的方案需结合业务容忍度分层打散过期时间（如哈希分桶、毫秒级PEXPIRE偏移、pipeline内分批打散），并配合Redis 7.0+的lazyfree-lazy-expire异步化能力；同时必须通过监控expired_keys突增、evicted_keys上升和mem_fragmentation_ratio持续走高这三大信号提前预警，因为最危险的从来不是“过期”，而是“过期未及时清理”与“大流量高峰”的致命叠加。

大量key同时过期会卡住Redis吗？ 会，但不是“直接卡死”，而是触发CPU尖峰 + 内存延迟释放 + 请求响应抖动。Redis默认每100ms做一次随机抽样检查（activeExpireCycle），如果某次抽样发现超过25%的样本已过期，它会立刻再执行一轮——这在大量key集中过期时，可能连续多轮高强度扫描+删除，把CPU吃满，导致正常请求延迟飙升甚至超时。

常见错误现象包括：INFO commandstats里 cmdstat_expire 耗时突增、used_cpu_sys 或 used_cpu_user 飙升、客户端出现大量 timeout 或 READONLY（主从切换误判）错误。

• 不要依赖“反正有惰性删除兜底”——冷数据不访问，过期key就一直占内存
• 不要全量用 EXPIREAT 算同一个时间戳——哪怕只差1毫秒，也比完全同步强
• Redis 7.0+ 的 lazyfree-lazy-expire yes 可让过期删除异步化，但仅对定期删除生效，惰性删除仍同步删

怎么分散过期时间才真正有效？ “加个随机数”不够，得看业务容忍度和key规模。比如10万条用户token统一设30分钟过期，直接加±90秒（即29.5~30.5分钟）只是把压力摊到2分钟内，依然可能压垮单个redis实例。

更稳妥的做法是分层打散：

• 按key前缀或用户ID哈希分桶，每桶设置不同基础过期时间（如桶0→1780s，桶1→1792s…）
• 对时效性敏感的（如短信验证码），用 PEXPIRE + 毫秒级偏移（rand(100, 500)），避免秒级对齐
• 对批量写入场景（如导入缓存），用pipeline分批提交，每批内再打散过期时间，别一次性塞5000个同过期key

注意：TTL 返回 -2 表示key已过期但尚未被清理，此时它还在内存里，只是“逻辑不可见”——这种僵尸key堆积多了，mem_fragmentation_ratio 会悄悄升高。

定期删除机制到底在查什么？ Redis不是遍历整个数据库，而是在每个db的过期字典（expires dict）里随机采样。这个字典只存设置了过期时间的key，所以没设过期的key完全不影响它。

关键点在于：

• 采样数量由 ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 控制（默认20），但实际每次最多删10个过期key，防止单次操作太久
• 如果某个db里过期key占比长期高于25%，Redis会加大扫描力度，可能持续占用10%~30% CPU
• CONFIG GET active-expire-effort（6.2+）可调扫描强度，但值过高反而引发抖动，生产环境不建议动

你可以用这个命令快速看当前库有多少待清理的过期key：EVAL "return #redis.call('ZCOUNT', 'redis_expires', '-inf', '+inf')" 0（需提前用Lua建索引）或更轻量的 DBSIZE 对比 INFO keyspace 中各db的 keys 和 expires 字段。

监控哪些指标能提前发现问题？ 别等报警才看，日常盯紧三个地方：

• expired_keys（累计删除数）：突增说明刚经历一波过期高峰
• evicted_keys：如果它跟着涨，说明过期key没及时清完，内存吃紧后触发了淘汰策略
• mem_fragmentation_ratio > 1.5 且持续上升：大概率是过期key删得慢，内存碎片堆积

顺手加个简单巡检脚本：

redis-cli INFO | grep -E "(expired_keys|evicted_keys|mem_fragmentation_ratio)"

真正麻烦的不是过期本身，而是“过期但没删干净”+“删的时候又撞上大流量”。这两件事叠在一起，比单纯数据量大还难定位。

本篇关于《Redis处理大量瞬时过期数据的方法》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于数据库的相关知识，请关注golang学习网公众号！