pubsub numsub是唯一能获取服务端实时在线订阅者数量的命令，返回整数如“my:channel 5”表示当前5个客户端监听该频道；它不区分subscribe/psubscribe，但只对显式频道生效，且结果受断连、集群分片、代理拦截等因素影响。
用 PUBSUB NUMSUB 查频道级实时订阅数
这是唯一能拿到服务端真实在线订阅者数量的命令，返回值是整数，比如 my:channel 5 表示此刻有 5 个客户端在监听该频道。它不区分 SUBSCRIBE 和 PSUBSCRIBE，但只对显式订阅的频道生效（通配符模式需用 PUBSUB NUMPAT）。
常见误判点：
-
PUBSUB NUMSUB返回 0 不代表没人订阅——可能是客户端已断连但未触发清理，或连接刚建立、还没来得及发SUBSCRIBE命令 - Redis Cluster 下，该命令只查当前节点；如果频道在其他 master 上，结果为空是正常现象
- 某些代理（如 Twemproxy）会拦截 PUBSUB 命令，导致始终返回 0 或报错
ERR unknown command
用 redis-cli --csv MONITOR + awk 统计频道级 PUBLISH 频率
MONITOR 本身不支持过滤，但配合 --csv 输出可稳定提取频道名字段，避开 payload 干扰。执行以下命令可每秒输出指定频道的发布次数：
redis-cli --csv MONITOR 2>/dev/null | awk -F',' '$2=="\"PUBLISH\"" && $3=="\"my:channel\"" {c++} ENDFILE{print strftime("%H:%M:%S"), c; c=0}'
注意：
- 必须用双引号包裹字段值（
"\"PUBLISH\""），否则匹配失败 - 该方式无法识别 PSUBSCRIBE 匹配到的发布，只统计直连频道的
PUBLISH命令 - 高频使用 MONITOR 会显著增加 Redis CPU 开销，生产环境建议采样间隔 ≥10 秒
用 INFO 辅助识别长连接客户端
INFO 不直接暴露订阅数，但能帮你定位疑似订阅者：重点关注 connected_clients（总连接数）、client_longest_output_list（输出缓冲区最大长度）、instantaneous_output_kbps（实时出口带宽）。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
订阅者通常表现为：
-
client_longest_output_list明显高于其他连接（因消息积压在输出队列） -
instantaneous_output_kbps持续偏高，且与PUBLISH频率趋势一致 - 结合
CLIENT LIST过滤flags=O的连接，确认是否为 Pub/Sub client（但无法知道订的是哪个频道）
为什么不能只靠 PUBSUB CHANNELS 判断活跃性
PUBSUB CHANNELS 只返回“至少有一个订阅者”的频道名，不带数量、不带连接详情、不跨节点。它本质是服务端的一个轻量缓存索引，不是状态快照。
最常被忽略的事实：
- Python redis-py 的
pubsub.channels字典是纯本地内存结构，网络断开后仍显示非空，和服务端完全脱节 - Redis 不维护“僵尸订阅”概念——连接一断，
NUMSUB立即归零，但客户端可能还在等重连逻辑触发 - 频道名严格区分大小写，
PUBSUB NUMSUB "User"和PUBSUB NUMSUB "user"是两个独立计数
真正可靠的监控必须交叉验证：在客户端循环里捕获 ConnectionError，配合服务端 NUMSUB 定期采样，再叠加 instantaneous_output_kbps 异常突增告警——三者缺一不可。
