我们最近将 google pubsub 集成到我们的应用程序中,我们的一些长期运行的任务现在遇到了问题,因为它们有时需要超过 1 分钟。我们已将订阅者的 ack 截止时间配置为 600 秒,但是,任何超过 的时间600ms
都会被 pubsub 重试。
这是我们的配置:
gcloud pubsub subscriptions describe name
ackDeadlineSeconds: 600
expirationPolicy: {}
messageRetentionDuration: 604800s
不知道是什么问题。我们的大部分任务都会因此而重复
Pub/Sub 有一个内置的At-least-once传递系统,它会重试未被确认的消息。在这种情况下,经过 600 秒后,您第一次发送的消息将变为未确认状态,因此 Pub/Sub 会重试该消息。它将继续重试 600 秒,直到达到messageRetentionDuration
或您确认为止。
请记住,文档中指定您的订阅者应该是幂等的。因此,让您的代码能够处理多条消息应该是解决此问题的最佳方法。
您还可以将 减少messageRetentionDuration
到600s
(它是最小值),这样任何超过 10 分钟标记的东西都不会被重试。
此外,常见问题解答中指出:
为什么重复消息太多?
Cloud Pub/Sub 保证至少一次消息传递,这意味着偶尔会出现重复。但是,较高的重复率可能表明客户端未确认配置的 内的消息
ack_deadline_seconds
,并且 Cloud Pub/Sub 正在重试消息传递。这可以在监控指标中观察到。pubsub.googleapis.com/subscription/pull_ack_message_operation_count
用于请求订阅和pubsub.googleapis.com/subscription/push_request_count
推送订阅。查找升高过期或webhook_timeout
中值/response_code
。如果有很多小消息,这种情况尤其可能发生,因为 Cloud Pub/Sub 可能会在内部对消息进行批处理,并且部分确认的批处理将被完全重新传送。另一种可能是订阅者没有确认某些消息,因为处理这些特定消息的代码路径失败,并且从未进行 Acknowledge 调用;或者推送端点永远不会响应或响应错误。
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句