GCP PubSub过滤器未按预期生效的相关技术咨询

核心异常问题排查 #

你遇到的过滤器未生效、两条消息均被投递的情况，大概率是以下原因导致：

• 属性键名大小写不匹配：PubSub 的消息属性键区分大小写，如果发布消息时属性键是SomeHeader，但过滤器写的是someHeader，会导致匹配失败，所有消息都进入订阅。
• 过滤器语法错误：比如使用了中文引号、多余空格，或者表达式格式不正确（正确格式为attributes.someHeader = "x"）。
• 过滤器未成功应用：检查订阅的过滤器是否真的保存生效，可通过命令行确认：

  gcloud pubsub subscriptions describe XYZ-Sub
  

  查看输出中的filter字段是否与预期一致。
• 消息属性设置错误：确认发布消息时，someHeader属性的值确实是"a"和"x"，没有额外的空格、换行或特殊字符。

疑问解答 #

1. 未确认消息数上升但控制台拉取不显示消息 #

PubSub 过滤器是在服务端路由阶段生效的，不符合条件的消息不会进入订阅的消息队列。出现这种情况可能是：

• 控制台指标存在延迟：GCP 控制台的未确认消息数更新通常有1-5分钟的延迟，实际不符合过滤条件的消息并未进入订阅，显示的是旧数据。
• 过滤器实际未生效：所有消息都进入了订阅，但拉取时客户端或控制台的展示逻辑过滤了不符合的消息，导致你看不到，但实际它们存在于订阅队列中。

2. 过滤器是在客户端还是 Topic 层面评估？ #

过滤器是在服务端的订阅层面评估，消息从 Topic 路由到订阅时就会执行过滤逻辑，不符合条件的消息直接被拦截，不会进入订阅队列，完全不需要客户端参与过滤操作。

3. 使用 PubSub 过滤器的意义是什么？ #

• 降低客户端负载：让订阅只接收业务需要的消息，减少客户端的无效处理和带宽消耗。
• 实现消息分流：同一个 Topic 下可以创建多个带不同过滤器的订阅，将不同类型的消息分发给对应的消费者，无需在客户端做分流逻辑。
• 优化成本：不符合过滤条件的消息不会进入订阅，因此不会产生该订阅的消息存储、投递或拉取费用。

4. 非目标消息的投递会产生计费吗？ #

不会。只有被成功路由到订阅的消息才会产生相关计费（存储、投递、拉取），不符合过滤器的消息不会进入订阅队列，因此不会产生任何与该订阅相关的费用。

内容的提问来源于stack exchange，提问作者Alex Tbk