我们最近将google pubsub集成到了我们的应用程序中，我们一些长期运行的任务现在遇到了问题，因为有时它们需要1分钟以上的时间。我们已经将订阅者的确认截止时间配置为600秒，但是，花费超过600ms的所有内容都将被pubsub重试。
这是我们的配置：
gcloud pubsub subscriptions describe name
ackDeadlineSeconds: 600
expirationPolicy: {}
messageRetentionDuration: 604800s
不确定是什么问题。因此，我们的大多数任务都会重复执行
答案 0 :(得分：0)
Pub / Sub具有内置的At-least-once传递系统，该系统将重试未确认的消息。在这种情况下，经过600秒后，您第一次发送的消息将无法确认，因此Pub / Sub将重试该消息。它将持续重试600秒，直到达到messageRetentionDuration或您确认为止。
请记住，在文档中已指定订户应该是幂等的。因此，使您的代码能够处理多个消息应该是解决此问题的最佳方法。
您还可以将messageRetentionDuration减少到600s（最低），这样任何超过10分钟标记的内容都将不会重试。
此外，FAQs中指出：
为什么重复消息太多？
Cloud Pub / Sub确保至少一次发送消息，这意味着 偶尔会有重复。但是， 重复项可能表明客户端未在确认消息 在已配置的
ack_deadline_seconds中，并且Cloud Pub / Sub是 重试邮件传递。这可以在monitoring metrics中看到。pubsub.googleapis.com/subscription/pull_ack_message_operation_count用于请求订阅，以及pubsub.googleapis.com/subscription/push_request_count进行推送 订阅。在中查找过期的高值或webhook_timeout值/response_code。如果有很多，这尤其可能 小消息，因为Cloud Pub / Sub可能会在内部批量处理消息，并且 部分确认的批次将完全重新交付。另一种可能性是订户没有确认一些 消息，因为处理这些特定消息的代码路径 失败，并且永远不会进行确认调用；或推送端点 永远不要回应或回应错误。