lazyfree-lazy-eviction开启后仍卡顿，因其仅对内存满触发的自动淘汰生效，不作用于过期清理、DEL/FLUSH等操作；配置错误（如漏写-lazy-）、未重启或BIO线程积压均会导致失效。
lazyfree-lazy-eviction 开启后为什么还卡？
因为这个配置只对「内存满触发的自动淘汰」生效，不是万能开关。它不改变过期 key 清理、DEL 命令或 FLUSH 操作的行为。常见误判是：开了 lazyfree-lazy-user-del 就以为淘汰也异步了——其实两者完全独立，lazyfree-lazy-eviction 必须单独显式开启。
更隐蔽的问题是：配置写错（比如漏掉 -lazy- 变成 lazyfree-eviction yes），Redis 启动时会静默忽略，CONFIG GET lazyfree-lazy-eviction 返回空值，但没人检查。
- 确认是否真正生效：
CONFIG GET lazyfree-lazy-eviction必须返回1 - 验证运行时行为：
INFO MEMORY中lazyfree_pending_objects在淘汰发生后应短暂上升再回落 - 若该值长期 > 0，说明 BIO 线程处理不过来，需扩容或拆实例
大Key淘汰卡顿的根源不在命令本身
慢日志里看到大量 SET、HSET、DEL 耗时高，不是这些命令变慢了，而是 Redis 在执行它们前，被迫同步驱逐一个大 Key 来腾内存。主线程卡在 freeObj 或 dictRelease 上，后续所有请求排队等待。
典型信号：INFO memory 中 used_memory_human 长期贴近 maxmemory_human，同时 evicted_keys 持续增长，但业务 QPS 并未突增。
- Hash 类型的大 field（如单个 value > 1MB）释放是 O(N) 操作，且必须主线程完成
- List/ZSet 元素数 > 1w 也属于逻辑大 Key，淘汰时遍历跳表/链表同样阻塞
-
redis-cli --bigkeys只报 key 总大小，不暴露 field 级别分布，容易漏判
必须配套做的三件事
光开 lazyfree-lazy-eviction 不够，得和具体使用方式对齐：
- 把业务中高频出现的
DEL替换为UNLINK（仅对主动删除有效，但能降低整体主线程压力） - 对已知大 Key 结构做切分：比如把
HSET user:123 profile "{5MB JSON}"改成SET user:123:profile:basic "{'name':'a'}"+SET user:123:profile:detail "base64..." - 淘汰策略避开
volatile-lru+ 大量短过期 key 的组合——过期清理和内存淘汰双重同步释放，卡顿翻倍
Redis 版本与配置的实际约束
lazyfree-lazy-eviction 在 Redis 4.0+ 引入，但安全边界在 6.0 才真正收紧。6.0 之前版本存在 BIO 线程队列溢出风险，且部分 edge case 下仍可能 fallback 到同步释放。
生产环境建议直接上 Redis ≥ 6.0，并确保：
-
CONFIG SET lazyfree-lazy-eviction yes临时验证后，写入redis.conf并CONFIG REWRITE - 顺手打开
lazyfree-lazy-expire yes，避免过期 key 成为新瓶颈 - 禁用
slave-lazy-flush（除非你明确需要从库 RDB 加载后异步清空）
真正容易被忽略的是：异步释放不等于内存立刻归还 OS。BIO 线程释放有延迟，used_memory_rss 可能持续高于 used_memory，这不是泄漏，是预期行为。
