开启lazyfree-lazy-expire后，大Key过期删除由后台I/O线程异步执行，主线程仅摘除key和unlink指针，避免阻塞；但需满足元素数＞64、配置生效且避开notify事件卡顿等陷阱。
大Key过期时集群抖动，根本原因是主线程被阻塞
Redis单线程模型下，过期Key的内存释放默认由主线程同步完成。当一个包含百万级成员的Hash或Sorted Set自然过期，主线程必须逐个释放元素、清理哈希桶、更新统计——这个过程可能耗时数秒。期间所有客户端请求排队等待，监控上表现为P99延迟飙升、主从复制中断、哨兵误判故障，甚至触发集群自动failover。
lazyfree-lazy-expire开启后，过期删除不再卡主线程
该参数控制的是“被动过期场景”下的删除行为：不是禁止删除，而是把内存释放工作移交后台I/O线程（bio）。主线程只做两件事：从过期字典db->expires中摘除key条目、从主字典db->dict中unlink对象指针。真正的decrRefCount和元素遍历释放，由bio线程异步执行。
- 必须搭配
redis.conf中配置生效：lazyfree-lazy-expire yes - 仅对设置了TTL且真正到期的key生效；未设置TTL的key不受影响
- 阈值受
LAZYFREE_THRESHOLD硬编码限制（Redis 4.0+为64）：只有对象实际元素数量 > 64 时才走异步路径，小key仍同步删，避免线程调度开销反超收益 - 开启后，
INFO stats中的expired_keys计数仍会增长，但evicted_keys和total_commands_processed不再因过期操作而出现长尾延迟
容易被忽略的三个坑
生产环境开了lazyfree-lazy-expire yes却仍有抖动，大概率掉进以下陷阱：
-
notify-keyspace-events配置了Ex但没消费：过期事件发布是同步的，如果客户端订阅了__keyevent@*:expired却处理缓慢或断连，主线程会卡在事件通知环节，和lazyfree无关 - 后台线程资源不足：Redis默认只启用1个bio线程处理lazyfree任务（
bio_lazy_free），若同时有多个大Key集中过期，任务队列堆积，内存释放延迟加剧；可通过bio_num_lazy_free（Redis 7.0+）或升级到更高版本缓解 - 与
maxmemory淘汰策略叠加：当maxmemory-policy设为allkeys-lru等，驱逐过程也会触发删除。此时需额外开启lazyfree-lazy-eviction yes，否则过期+驱逐双重压力仍会打爆主线程
验证是否真正生效的最简方法
不要只看配置文件，用真实数据压测并观察指标：
- 构造一个含50万字段的
Hash并设1秒后过期：HSET big_hash {k} {v}×50w，然后EXPIREAT big_hash $(($(date +%s) + 1)) - 等待过期后，立刻执行
INFO memory | grep lazy，检查lazyfree_pending_objects是否 > 0；该值非零说明后台确实在干活 - 对比
SLOWLOG GET 1：开启前过期瞬间会出现>1000ms的记录，开启后应稳定在0.1ms量级 - 注意：
redis-cli --bigkeys扫描本身不触发过期，别用它验证此场景
真正关键的不是参数开了没，而是后台线程能否跟上你的业务过期节奏——这取决于大Key规模、过期密度、以及bio线程的实际吞吐能力。
