PUBSUB CHANNELS 和 PUBSUB NUMSUB 是唯二能直接反映频道与订阅者状态的命令；前者返回当前至少有一个活跃订阅者的频道名列表，后者返回指定频道的实时订阅客户端数量，二者均不依赖键空间、历史记录或间接指标。
PUBSUB CHANNELS 和 PUBSUB NUMSUB 是唯二能直接反映频道与订阅者状态的命令，其他方式全是间接推断或不可靠采样。
查当前有哪些频道正在被订阅（PUBSUB CHANNELS）
这个命令只返回「至少有一个活跃 SUBSCRIBE 或 PSUBSCRIBE 连接」的频道名，不包含空频道或历史频道。
-
PUBSUB CHANNELS列出所有活跃频道，无参数时扫描全部；加pattern（如news.*）可模糊匹配，但注意：它不识别PSUBSCRIBE的模式本身，只匹配实际被模式命中、且已有客户端订阅的频道名 - 返回结果是纯字符串列表，没有计数，也不区分
SUBSCRIBE和PSUBSCRIBE来源 - 在 Redis 集群或代理后端（如 Twemproxy、Codis）中，该命令可能返回空或报错——因为多数中间件不转发 Pub/Sub 状态查询
查指定频道的实时订阅者数量（PUBSUB NUMSUB）
这是唯一能拿到数字的命令，但必须理解它的“实时性”本质：它只统计此刻 TCP 连接仍存活、且处于 SUBSCRIBE/PSUBSCRIBE 监听态的客户端。
- 执行
PUBSUB NUMSUB channel1 channel2，返回值是交替出现的频道名与整数，例如"channel1" 2 "channel2" 0——0表示当前无人订阅，不代表没用过这个频道 - 如果用脚本调用后立刻看到
0，先确认：订阅客户端是否仍在运行？是否已调用listen()（如 redis-py）或保持阻塞读取？是否被防火墙/NAT 断连但未触发 TCP FIN？ -
PSUBSCRIBE订阅的频道也会被计入NUMSUB，但仅当有消息实际匹配到该模式时；模式本身不增加计数，只有匹配成功的订阅连接才被算入
为什么不能用 INFO 或 CLIENT LIST 推算订阅者？
因为 Redis 不在连接元数据里标记“此连接是订阅者”，connected_clients 是总连接数，client_longest_output_list 只反映输出缓冲区长度，无法区分是订阅者积压还是普通 client 在发大请求。
-
CLIENT LIST输出中的flags字段理论上含U（pubsub）标识，但实测中大量版本（尤其 6.2+ 集群分片节点）返回为空或不一致，不可依赖 -
INFO clients里的connected_clients和client_recent_max_input_buffer等指标，对 Pub/Sub 场景几乎无诊断价值——它们不区分用途，也无法定位哪个连接对应哪个频道 - 试图用
redis-cli --stat观察requests增量来反推发布频率？不行。它统计所有命令，且无频道维度，误差极大
真正要监控的不是“有多少人”，而是“有没有人掉线”
Pub/Sub 的脆弱点从来不在数量，而在连接生命周期管理。一个 NUMSUB 从 3 突降到 0，往往意味着某个服务实例崩溃、网络分区或客户端未正确重连。
- 建议对关键频道做周期性
PUBSUB NUMSUB channel_name采样（比如每 5 秒一次），并设置阈值告警：连续 3 次为 0 就触发通知 - 避免用
MONITOR+grep统计发布次数——payload 里含频道名就会误判，且无时间精度；真要用，必须走redis-cli --csv MONITOR+awk解析第三列 - 最常被忽略的一点：
NUMSUB查不到代理后的订阅者，也查不到集群中非当前节点负责的频道订阅——如果你用了集群或代理，得在每个分片/后端单独查，或改用业务层心跳上报
