谷歌云平台中的 AWS Dead Letter Queue 相当于什么？

Question

谷歌云平台中的 AWS Dead Letter Queue 相当于什么？ Google Cloud Platform 中如何管理失败的记录？

Answer 1

从 2020 年开始，Google Pub/Sub 现在支持在创建订阅时配置死信主题（就像其他主要排队系统一样）：

$ gcloud pubsub subscriptions create SUBSCRIPTION \
  --topic=TOPIC \
  --topic_project=TOPIC_PROJECT \
  --max-delivery-attempts=NUMBER_OF_RETRIES \
  --dead-letter-topic=DEAD_LETTER_TOPIC \
  --dead-letter-topic-project=DEAD_LETTER_TOPIC_PROJECT

在达到NUMBER_OF_RETRIES后，未能传递到TOPIC的消息将改为发布到DEAD_LETTER_TOPIC （这对于进一步分析、触发警报或其他自动操作等很有用）

如文档中所述，与封闭订阅的父项目（即service-{project_number}@gcp-sa-pubsub.iam.gserviceaccount.com ）关联的 Cloud Pub/Sub 服务帐户必须有权Publish()到此此订阅上的主题和Acknowledge()消息。

文档： https : //cloud.google.com/sdk/gcloud/reference/pubsub/subscriptions/create#--max-delivery-attempts

Answer 2

简短的回答：没有。 Google PubSub 缺少其他所有排队系统的核心功能。

更长的答案：您可以尝试自己实现 DLQ，但 Google Pub/Sub 缺少一些功能，因此很难正确实现。

1. PubSub 不会跟踪消息已传递的次数，因此您可以在 X 次尝试失败后将其发送到 DLQ。 因此，您必须在诸如 Redis 之类的东西中创建自己的数据存储，以通过消息 ID 跟踪传递计数。
2. PubSub 不支持重新交付的指数回退。 如果您想要重新传送消息，则不要确认或确认（这只会导致立即重新传送），而是什么都不做，让消息超时。
3. 无法将消息配置为转到 DLQ。 因此，您必须创建第二个 PubSub 主题，然后使用客户端逻辑来确定是否/何时将消息发送到 DLQ 主题。 如果您需要重新处理 DLQ 中的消息，则必须将它们从 DLQ 主题中拉出并将它们推回到主主题中。 请注意，这意味着它将重新交付给每个订阅者！ 无法将消息重新传递给特定订阅。 因此，每个订阅者都必须是幂等的，以避免重复处理消息。

Answer 3

使用Cloud Scheduler，您可以将通过HTTP（S）或发布/订阅调用的Cloud Functions调度到一分钟的时间间隔。 这使您可以按重复的时间表执行Cloud Functions，这对于每天生成报告或定期处理死信队列等操作特别有用