会，大量key同时过期会引发CPU尖峰、内存延迟释放和请求抖动；Redis通过每100ms随机抽样检查过期key，超25%过期则连续多轮高强度扫描删除，导致延迟飙升甚至超时。
大量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删得慢，内存碎片堆积
expired_keys（累计删除数）：突增说明刚经历一波过期高峰evicted_keys：如果它跟着涨，说明过期key没及时清完，内存吃紧后触发了淘汰策略mem_fragmentation_ratio > 1.5 且持续上升：大概率是过期key删得慢，内存碎片堆积顺手加个简单巡检脚本：
redis-cli INFO | grep -E "(expired_keys|evicted_keys|mem_fragmentation_ratio)"
真正麻烦的不是过期本身，而是“过期但没删干净”+“删的时候又撞上大流量”。这两件事叠在一起，比单纯数据量大还难定位。
