Redis不主动通知session过期，KeySpace事件仅在键被实际删除时触发一次，无法保证实时性，不能替代TTL检查；需配合显式TTL验证与事件监听做可靠清理。
Redis本身不会主动通知你某个session已过期，KeySpace事件机制只是“告诉你发生了什么”，不是“帮你做清理”——它不替代TTL，也不能保证实时性。
KeySpace事件是什么，它能触发session过期通知吗
KeySpace事件是Redis发布的一类内部操作广播，比如__keyevent@0__:expired表示数据库0中某个key因过期被删除。但它只在**键真正被删除时**才发出，而Redis的过期删除依赖惰性+定期两种机制，所以：
- 如果一个session key已过期但从未被访问，且定期扫描还没抽到它，
expired事件就不会触发 - 事件只发一次，且不带value内容，无法直接还原session数据做业务逻辑（比如登出推送）
- 必须显式开启：
redis.conf里要配置notify-keyspace-events Ex（E表示事件，x表示过期） - 客户端需用
PSUBSCRIBE __keyevent@*:expired监听，注意数据库编号通配写法
为什么不能只靠KeySpace事件做session清理
因为Redis的过期清理本身就有延迟窗口：
Session Reset
下载
安全地重置 OpenClaw agent sessions，支持备份、预览、恢复和批量操作。用于：1) 清理过期的 agent 会话上下文，2) 重置特定 agents 的 session，3) 批量重置六部/秘书 sessions，4) 查看和恢复历史备份。当用户需要"reset session"、"清理 se...
- 定期删除默认每100ms随机抽检20个带过期时间的key，抽不到就搁置
- 若大量key集中在同一秒过期，可能堆积数分钟才被扫到
- 惰性删除只在
GET/HGETALL等访问时触发，无人访问=永不触发=事件永不发出 - 这意味着：用户session实际已失效，但你的监听程序收不到事件，也就无法调用
session_destroy()或清理关联缓存
怎么配合TTL和KeySpace事件做可靠清理
把KeySpace事件当“补充信号”，主逻辑仍依赖显式TTL检查：
- 每次读session前，先
TTL session:xxx；返回-2说明已删，-1说明永不过期，≥0才是有效剩余时间 - 写session时统一用
SETEX session:xxx 1800 "data"或SET session:xxx "data" EX 1800，避免漏设TTL - 用KeySpace事件做辅助动作：比如收到
expired后，异步更新用户在线状态表、清空本地缓存副本 - 别在事件回调里做阻塞操作（如HTTP请求），否则会卡住Redis事件队列；建议投递到消息队列再处理
容易忽略的配置和权限坑
KeySpace事件看似开箱即用，实则几个地方极易失败：
-
notify-keyspace-events默认是空字符串，必须手动设为Ex或AKE等组合，仅redis-cli CONFIG SET临时生效，重启丢失 - 某些云Redis服务（如腾讯云CRS、阿里云Tair）默认禁用KeySpace事件，需在控制台单独开启，且可能额外收费
- 监听用
PSUBSCRIBE，不是SUBSCRIBE；用redis-cli测试时得加--csv参数才能看清事件格式 - PHP的
phpredis扩展默认不启用事件订阅，需用setOption(REDIS_OPT_READ_TIMEOUT, -1)并手动循环psubscribe()
真正关键的不是“有没有事件”，而是你是否在每次session读写路径上都做了TTL兜底判断——事件只是锦上添花，不是雪中送炭。
