redis pub/sub无断连通知机制，需用键空间通知+保活key模拟探测：客户端定期设置带ttl的heartbeat:key，监听__keyevent@n__:expired事件，收到对应key过期消息即判定掉线，但存在秒级延迟且cluster模式需确保key路由至监听节点。
Redis 的 PUB/SUB 本身不提供断连通知机制——这不是 Bug，是设计如此。 订阅者进程崩溃、网络中断、超时退出，发布端完全感知不到。你不能靠 subscribe 或 psubscribe 的返回值、异常或回调来判断谁掉线了。所谓“修复断开不通知”，本质是换思路：用键空间通知（Keyspace Notifications）作为间接心跳探测手段，结合业务逻辑补位。
为什么键空间通知不能直接当“断连通知”用
键空间通知（如 __keyevent@0__:expired）只在 Redis 内部触发真实事件（比如 key 过期、DEL 执行）时才发消息。它和客户端连接状态无关——即使所有订阅者都已离线，只要事件发生，Redis 照样广播；反过来，没人断连，但也没 key 变化，就永远没消息。所以它不能替代连接层的健康检查，只能作为“某人可能还活着”的弱信号。
常见错误现象：psubscribe 后一直阻塞无输出，日志里既没报错也没收到任何消息，误以为“通知失效”，其实是根本没触发事件（比如忘了设 EXPIRE）。
- 必须先确保
notify-keyspace-events已启用（例如CONFIG SET notify-keyspace-events Ex） - 监听的频道名必须严格匹配格式：
__keyevent@0__:expired（数据库号、事件名大小写、双下划线都不能错） - 键空间通知默认关闭，且
CONFIG SET是运行时生效，重启 Redis 会丢失——生产环境务必写进redis.conf
用“保活 key + 键空间通知”模拟断连探测
核心做法：让每个订阅者定期写一个带 TTL 的保活 key（如 heartbeat:client_a），并监听该 key 的 expired 事件。如果事件被触发，说明这个 client 至少在 TTL 时间内没更新 key——极大概率已掉线。
实操建议：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 发布端（即你的服务）用
SET heartbeat:client_a 1 EX 30每 15 秒刷新一次，TTL 设为 30 秒留出缓冲 - 监听端订阅
__keyevent@0__:expired，收到msg['data'] == 'heartbeat:client_a'就认为 client_a 失联 - 注意：
expired事件不是实时的，受 Redis 过期键清理策略影响（惰性+定期），延迟通常在秒级，不可用于毫秒级故障检测 - 避免监听
__keyspace@0__:heartbeat:client_a——它发的是set、del等操作名，无法区分是主动删还是过期删
Redis Cluster 下键空间通知收不到？别只盯着配置
在 Cluster 模式中，键空间通知只在事件发生的那个分片节点上发出，不会自动广播到所有节点。如果你只连了一个节点并监听，而保活 key 被哈希到了另一个节点，那就永远收不到 expired 事件。
解决路径只有两条：
- 强制把保活 key 落在固定节点：用
{heartbeat:client_a}（花括号包裹）让 Redis 只对括号内部分做 CRC16 哈希，确保所有heartbeat:*key 都路由到同一 slot - 或改用客户端多路复用：为每个 Cluster 节点单独建连接 +
pubsub实例，统一汇总事件（代码复杂度高，但最可靠） - 验证是否真在目标节点触发：登录对应节点，执行
DEBUG OBJECT heartbeat:client_a确认 key 存在，并用redis-cli -p 7001 --csv pubsub channels __key*查看该节点是否启用了通知
监听代码里最容易漏掉的兼容性细节
很多示例代码直接用 psubscribe(['__keyevent@0__:expired'])，但在 Python 的 redis-py 3.0+、PHP 的 phpredis 5.3+ 中，psubscribe 的回调参数签名变了，且默认不解析消息结构。
关键差异点：
- Python：
redis-py的pubsub.listen()返回字典，必须检查msg['type'] == 'message'，否则会收到subscribe、psubscribe等控制消息干扰 - PHP：
psubscribe第二个参数是回调函数，但该函数接收的$msg是原始字符串，不是 JSON；若用json_decode($msg)会失败——实际内容就是 key 名（如"mykey"），无需解析 - 所有语言都要注意：频道名中的
@0表示数据库 0，如果你的保活 key 存在 db 1，就必须监听__keyevent@1__:expired，不能硬编码
真正难处理的，从来不是“怎么监听”，而是如何定义“掉线”——30 秒没心跳算掉线？那 GC STW 或网络抖动怎么办？要不要加二次确认？这些边界逻辑，得贴着你的业务 SLA 去拧，Redis 只负责发那条 expired 消息。
