Redis PUBSUB NUMPAT 统计模式订阅数量的使用方法

我在排查 Redis Pub/Sub 订阅数量时，最容易把 PUBSUB NUMPAT 看成“当前有多少个模式订阅客户端”。它实际返回的是：当前 Redis 节点上，通过 PSUBSCRIBE 建立的唯一模式数量。同一个模式被多个客户端订阅，只计一个模式；普通 SUBSCRIBE 频道也不计入这个结果。

先把 NUMPAT 的统计对象说清楚

PSUBSCRIBE news:* 和 PSUBSCRIBE order:* 是两个模式。即使两个客户端都订阅了 news:*，模式集合仍然只有两个成员，所以 NUMPAT 返回 2。相反，SUBSCRIBE alerts 属于普通频道订阅，不会让这个数字增加。

这个区别很适合用来做订阅结构排查：数字突然变大，先找模式字符串是否被业务动态拼接；数字一直为 0，则检查连接是否真的发出了 PSUBSCRIBE，不要只看普通频道的订阅。

用一个最小场景读取模式数量

准备订阅时开两个客户端连接：一个订阅 news:*，另一个订阅 order:*。再让第三个客户端重复订阅 news:*，就能观察“模式数量”和“客户端数量”不是同一个维度。

# 终端 A：建立第一个模式订阅，连接会保持在订阅状态
redis-cli PSUBSCRIBE 'news:*'

# 终端 B：建立第二个模式订阅，使用不同的模式字符串
redis-cli PSUBSCRIBE 'order:*'

# 终端 C：重复订阅 news:*，用于验证 NUMPAT 按唯一模式计数
redis-cli PSUBSCRIBE 'news:*'

# 终端 D：只读取模式数量，不返回订阅消息内容
redis-cli PUBSUB NUMPAT

最后一条命令的结果应是一个整数；在这个场景中预期为 2。这里的“预期”是对示例状态的解释，不是对线上环境的固定断言。客户端断开、执行 PUNSUBSCRIBE 或模式字符串发生变化，结果都会随连接状态改变。

NUMPAT、NUMSUB 和 CHANNELS 怎么分工

三个查询解决的是不同问题。排查时先写清楚要回答“有多少种模式”“某频道有多少订阅者”，还是“当前有哪些活跃频道”，再选命令。

NUMPAT 的时间复杂度是 O(1)，适合放进轻量排查脚本；但它不是完整的审计数据，不能告诉你哪些客户端、哪个连接或哪条业务链路创建了模式。要定位来源，仍需结合客户端连接管理、应用日志和订阅生命周期记录。

集群环境要把单节点结果拆开看

Redis Cluster 的 Pub/Sub 会在节点之间转发消息，但 PUBSUB 查询返回的是发起命令那个节点的 Pub/Sub 上下文信息。于是，直接在一个节点执行 NUMPAT，不能自动当成整个集群的全局模式总数。

我的处理方式是把节点作为排查维度：记录节点地址、采样时间和返回值，再对照应用连接分布。不要未经定义就把各节点结果相加；如果同一个模式在多个节点各有连接，相加得到的是“节点观察值之和”，未必等于业务所说的唯一全局模式数。

# 对每个相关节点分别执行，保留节点标签便于比较
for host in redis-a redis-b redis-c; do
  # NUMPAT 只代表当前连接所访问节点的 Pub/Sub 上下文
  printf '%s ' "$host"
  redis-cli -h "$host" PUBSUB NUMPAT
done

相关问题

NUMPAT 返回 0 是不是没有任何 Pub/Sub 连接？

不一定。可能没有模式订阅，但仍有普通频道订阅；也可能查询访问了没有模式订阅的节点。

重复执行 PSUBSCRIBE 会让 NUMPAT 一直增加吗？

不会。相同模式按唯一模式计数；增加新的模式字符串才会改变模式集合。

为什么 NUMPAT 不能直接定位哪个客户端订阅了模式？

它只返回计数，不包含客户端身份。需要另行记录订阅生命周期，或从连接与应用日志建立对应关系。

因此，PUBSUB NUMPAT 最适合回答“这个节点当前有多少种模式订阅”。把统计对象、节点范围和客户端来源分开记录，结果才不会被误读成全局连接数。