psubscribe性能瓶颈源于publish时线性遍历所有pattern做glob匹配。无索引、无缓存、无短路，pattern越多越慢；大小写敏感且*不匹配空字符串，易误配；超20个pattern或100qps即引发cpu毛刺。
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照算，消息却发不出去。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
性能影响直接体现在高频发布场景：假设每秒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，就能拖慢整个实例的发布吞吐。
