RedisPSUBSCRIBE耗CPU原因解析

Redis的PSUBSCRIBE看似灵活，实则暗藏性能陷阱：每次PUBLISH都需在服务端线性遍历所有已注册pattern，逐个执行CPU密集型glob匹配，无索引、无缓存、无短路优化，导致pattern数量或发布频次稍一上升（如超20个pattern或100qps）就引发显著CPU毛刺和延迟飙升；更棘手的是，大小写敏感、*不匹配空字符串等隐含规则常致误配却照耗资源，而缺乏调试工具和前缀分流机制让问题定位困难——真正高效的做法不是堆砌pattern，而是转向Streams或应用层路由，把匹配逻辑从核心发布路径中剥离出来。

PSUBSCRIBE每次PUBLISH都要遍历全部pattern做glob匹配

Redis服务端没有为pattern建立索引或前缀树，PSUBSCRIBE注册的每个pattern都存于一个链表中。每次执行PUBLISH channel message时，Redis必须遍历所有已注册的pattern，对当前channel字符串逐个调用glob匹配函数（类似shell的*?[abc]规则）。这不是正则引擎，但仍是纯CPU密集型操作。

常见错误现象：PUBSUB NUMPAT返回值达200+，而单次PUBLISH延迟从0.1ms升至1.8ms——这几乎全是glob循环+字符串比对开销。

• pattern越多，遍历成本线性上升：100个pattern ≈ 100次独立匹配
• pattern越长（如service.order.v2.us-east-1.*.failed），单次匹配CPU耗时越长
• 不支持短路优化：即使第一个pattern就匹配成功，仍要检查完全部

glob匹配无大小写控制且不支持空字符通配

Redis的glob实现是严格区分大小写的，且*不会匹配空字符串——这两个限制常被误用，导致本应命中的pattern实际未触发，但CPU照样白跑一遍。

使用场景上，如果你写了PSUBSCRIBE order.*，它能匹配order.pay、order.123，但**不匹配order**（末尾无点）；写了PSUBSCRIBE order.*.*，它能匹配order.user.created，但PSUBSCRIBE order.*.?*这种带冗余符号的写法，不仅无效，还让匹配逻辑更慢。

• order.* → 不匹配order（*不匹配空）
• Order.* ≠ order.*（默认大小写敏感）
• order.*.? → 要求channel至少有两个点，否则失败；?必须对应一个真实字符，不能“跳过”

客户端无法预判pattern是否生效，只能靠发布后观察

Redis没提供TESTPATTERN channel pattern这类调试命令，你没法在订阅前验证PSUBSCRIBE user.*能否覆盖user:123——因为冒号:不等于点.，所以根本不会命中。结果就是：pattern挂了，CPU照算，消息却发不出去。

性能影响直接体现在高频发布场景：假设每秒PUBLISH 1000次，平均每个有5个pattern匹配成功，但背后是每秒1000 × N次glob调用（N = 总pattern数）。若N=80，就是每秒8万次字符串扫描。

• 没有缓存机制：相同channel反复发布，每次仍重做全部pattern匹配
• 无法按channel前缀分流：所有pattern一视同仁，无分组、无优先级
• 运维排查困难：收不到消息时，得手动比对channel名、pattern写法、大小写、连接状态三层才能定位

替代方案比硬扛PSUBSCRIBE更可控

如果业务真需要多维路由（比如按tenant + type + status组合过滤），别堆pattern。用Redis Streams配合消费者组，或者在应用层做二级分发（如用HSET存订阅关系，PUBLISH后由worker查表投递）。

真正适合PSUBSCRIBE的，只有低频、粗粒度、可预测的场景，比如config.*、alert.critical这类固定前缀的运维通知。一旦pattern数量超过20个，或发布频率超过100qps，就得警惕CPU毛刺和延迟抖动。

最易被忽略的一点：pattern匹配开销发生在PUBLISH路径上，不是订阅端——也就是说，哪怕只有一个客户端PSUBSCRIBE，只要它挂了几十个pattern，就能拖慢整个实例的发布吞吐。

以上就是《RedisPSUBSCRIBE耗CPU原因解析》的详细内容，更多关于的资料请关注golang学习网公众号！