Redis发布订阅监控指标有哪些？

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 列是累计请求总数，差值可粗略估算每秒操作量。但问题在于：

• 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 的脆弱性不在吞吐，而在连接生命周期管理。监控重点从来不是“发了多少”，而是“谁还在听”和“听的人有没有堵住”。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于数据库的相关知识，也可关注golang学习网公众号。