我正在使用 PubSub 主题实现一个用于摄取数据的队列。 我的计划是使用推送订阅在数据发布时立即对其进行处理。
在使用 Pull Sub 时，我看到很多代码模式试图在每次运行中重新创建一个 Pull Subscription，以确保我们在下一个 pull 周期中有一个有效的订阅。
我应该使用推送订阅做同样的事情吗？恕我直言，不，但我担心在某种程度上推送订阅不是永恒的，应该进行监控以保证下次发布消息时推送订阅处于活动状态。
什么是推送订阅创建的良好设计模式？ 我应该使用 PubSub 管理界面创建一次推送订阅还是以编程方式创建（甚至重新创建）？
【问题讨论】：
标签： publish-subscribe google-cloud-pubsub
订阅者倾向于在启动时重新创建代码的原因可能是这样一个事实，即如果订阅存在 30 天未检测到订阅，则会对其进行垃圾收集（请参阅“如果订阅者不存在，消息是持久的还是持久的？”在Google Cloud Pub/Sub FAQ 中。此外，如果拉订阅被显式删除，则在启动时在代码中重新创建它可确保拉取请求不会失败。对于拉订阅者，检测存在的概念相当简单：检查对拉的调用。
对于推送订阅者来说，它有点模糊。如果要删除订阅，订阅者本身将无法知道它已被删除；它只会停止接收消息。如果您确定不会手动删除订阅，并且每 30 天至少发送一条消息，则无需担心在启动时创建订阅，只需通过 Pub/Sub 管理界面创建一次即可。
如果您想确认一下，您可以create a policy in Stackdriver 通知您的订阅在一段时间内没有推送任何消息（假设您发布相当稳定的流消息）。添加“Metric Absence”条件，资源类型选择“Cloud Pub/Sub Subscription”，订阅名称选择“Push Request Count”作为触发指标。
【讨论】：