notify-keyspace-events 开启后会显著增加CPU开销，因其在每个命令执行后强制执行事件广播逻辑，即使无人订阅；高写入场景下DEL、EXPIRE、SET等操作均触发线性增长的事件生成与分发。
为什么 notify-keyspace-events 会吃CPU
Redis 的键空间通知（keyspace notifications）本身不主动轮询，但一旦开启，每个命令执行后都要多走一遍事件广播逻辑——哪怕没人订阅。尤其在高写入场景下，DEL、EXPIRE、SET 等操作都会触发事件生成和分发，这部分开销是线性增长的。
常见错误现象：INFO cpu 显示 used_cpu_sys 或 used_cpu_user 持续偏高，而 QPS 并没明显上涨；用 redis-cli --stat 观察到 instantaneous_ops_per_sec 波动大，但业务请求量平稳。
- 默认关闭时完全无开销；一旦设为
KEA或更宽泛的配置，所有 key 变更都进通知管道 - 即使客户端只订阅了
__keyevent@0__:del，Redis 仍要为set、incr、hset等所有事件构造 payload - 通知通过 Pub/Sub 发送，如果订阅者消费慢或断连，内部缓冲区堆积会进一步拖慢主线程
只开真正需要的通知类型（比如只用 Ex）
大多数业务其实只关心过期和删除，而非所有变更。用最小集配置能砍掉 70%+ 的事件生成成本。
使用场景：延时队列（监听 expired）、缓存穿透兜底（监听 del 后重建）、审计日志（仅记录删改）。
-
notify-keyspace-events "Ex"—— 只发过期事件，最轻量，适用于基于 TTL 的清理逻辑 -
notify-keyspace-events "Kl"—— 只发列表相关事件（如lpush、rpop），适合消息队列桥接 - 避免用
AKE或KA：前者等于全开，后者连get这种只读操作都可能触发通知（取决于是否启用了tracking） - 修改后必须重启或用
CONFIG SET notify-keyspace-events Ex生效，且该命令不会校验值合法性，输错（如EX）会静默失败
用 SCAN + TTL 替代监听 del 事件做兜底
监听 del 看似直接，但实际容易漏事件（客户端断连、Pub/Sub 消息丢弃）、且无法区分是主动删还是被动逐出。对缓存重建这类关键逻辑，不如主动探查更稳。
性能影响：一次 SCAN 扫几百个 key 的 TTL，CPU 开销远低于持续广播 + 客户端重连恢复 + 消息重投的组合成本。
- 在业务低峰期跑定时任务，用
SCAN 0 MATCH "cache:*" COUNT 500拉一批 key，再批量TTL - 只对
TTL返回 -2（已删）或 -1（永不过期）的 key 做判断，跳过正在存活的 - 不要在主线程里同步调
SCAN，它虽非阻塞，但大范围扫描仍会占一定时间片；建议起独立 worker 或用 Lua 封装减少往返
确认客户端真的在消费，而不是堆积在 Redis 内部缓冲区
Redis 不会因为客户端卡住就停发通知——它把消息往 client 输出缓冲区一塞，就继续干别的了。缓冲区满会导致连接被踢，而重连后又从头开始，形成恶性循环。
典型表现：CLIENT LIST 中看到某个 client 的 qbuf 或 qbuffersize 持续 >1MB，flags 里有 P（Pub/Sub client）但 omem 不降。
- 用
CLIENT UNBLOCK <client-id> TIMEOUT</client-id>主动断开滞留连接，避免雪球效应 - 订阅端必须设置合理的
SO_TIMEOUT和重连退避，别用无限阻塞的subscribe调用 - 生产环境禁用
MONITOR命令——它本质也是个超级 Pub/Sub 订阅者，开一次等于加一个永不消费的客户端
最麻烦的不是配错 notify-keyspace-events，而是开着它却没人真去收消息，或者收了不处理完就断。这种“半启用”状态最耗 CPU，也最难排查。
