redis pub/sub监控需聚焦连接行为与资源消耗：用pubsub numsub查实时订阅数，instantaneous_output_kbps和client_longest_output_list组合判断积压，connected_clients与connections_received_per_sec协同识别频繁重连。

Redis 发布订阅（Pub/Sub）本身不持久、无状态，监控必须绕开“消息内容”，聚焦在连接行为和资源消耗上——否则你看到的永远是“一切正常”，直到消息突然断流。

如何用 INFO 提取 Pub/Sub 实时连接数

Redis 的 INFO 命令不直接暴露订阅者数量，但能间接推算：connected_clients 是总连接数，client_longest_output_list 和 client_biggest_input_buf 可辅助识别长连接客户端（比如订阅者）。真正可靠的是 PUBSUB NUMSUB 命令：

• PUBSUB NUMSUB channel1 channel2 返回每个频道当前活跃订阅者数，返回值为整数，0 表示无人订阅
• 若频道名含通配符（如 news.*），NUMSUB 不支持匹配，需改用 PUBSUB NUMPAT 查看模式订阅总数
• 注意：该命令只统计当前在线的 SUBSCRIBE 连接，PSUBSCRIBE 也计入；但断连后不会自动清理，实际依赖 TCP Keepalive 或客户端重连逻辑

redis-cli --stat 能否反映发布频率？

不能直接反映，但可观察间接信号：redis-cli --stat 输出中的 requests 列是累计请求总数，差值可粗略估算每秒操作量。但问题在于：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• PUBLISH 属于写命令，会增加 instantaneous_ops_per_sec，但和 SET、INCR 混在一起，无法单独剥离
• 高频 PUBLISH 往往伴随大量小包网络 I/O，此时 redis_instantaneous_output_kbps 会上升明显，比 requests 更具指向性
• 如果发布端使用 pipeline 批量 PUBLISH，instantaneous_ops_per_sec 峰值可能虚高，而 output_kbps 更贴近真实带宽压力

为什么 memory_used_rss 突增不一定和 Pub/Sub 有关

Pub/Sub 本身几乎不占内存——它不存储消息，只维护订阅关系表（pubsub_channels 和 pubsub_patterns 字典）。但以下情况会让内存异常上涨：

• 订阅者消费过慢或断连未及时退出，导致 Redis 内部缓冲区（output_buffer）持续堆积，表现为 client_longest_output_list > 0 且长期不降
• 使用 PSUBSCRIBE 匹配大量频道（如 *），Redis 会为每个匹配项注册回调，pubsub_patterns 字典膨胀，尤其在 pattern 数量超千级时明显
• 误把 Pub/Sub 当作队列用，上游疯狂 PUBLISH、下游不 SUBSCRIBE，消息被直接丢弃，但连接缓冲仍占用 RSS 内存，直到连接超时关闭

真正需要盯住的三个指标组合

单看一个指标容易误判。建议用以下组合建立基线并设告警：

• PUBSUB NUMSUB your_channel 返回值持续为 0 → 订阅端进程已挂，或频道名拼写错误
• redis_instantaneous_output_kbps 突增 + client_longest_output_list > 1000 → 某个订阅者卡住，正在积压消息
• redis_connected_clients 缓慢上涨 + redis_connections_received_per_sec 同步升高 → 客户端频繁重连，可能是网络抖动或 SUBSCRIBE 后未保持长连接

Pub/Sub 的脆弱性不在吞吐，而在连接生命周期管理。监控重点从来不是“发了多少”，而是“谁还在听”和“听的人有没有堵住”。