Question

相当于Google Cloud Platform中的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

With Cloud Scheduler, you’ll be able to schedule Cloud Functions down to one-minute intervals invoked via HTTP(S) or Pub/Sub. This allows you to execute Cloud Functions on a repeating schedule, which is particularly useful for things like daily report generation or regularly processing dead letter queues

Answer 3

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

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

PubSub不会跟踪消息已传递多少次，因此您可以在X次尝试失败后将其发送到DLQ。因此，您必须在Redis之类的数据库中创建自己的数据存储区，才能按邮件ID跟踪传递计数。
PubSub不支持指数退还以便重新交付。如果您希望重新发送邮件，则不进行确认或不应答（这只会导致立即重新发送邮件），您什么也不做，而是让邮件超时。
无法配置将消息发送到DLQ的方法。因此，您必须创建第二个PubSub主题，然后使用客户端逻辑来确定是否/何时将消息发送到DLQ主题。如果需要重新处理DLQ中的消息，则必须将它们从DLQ主题中拉出，然后将其推回到主要主题中。请注意，这意味着它将重新交付给每个订户！无法将消息重新传递到特定的订阅。因此，每个用户都必须是幂等的，以避免对消息进行重复处理。

相当于Google Cloud Platform中的AWS Dead Letter Queue？

3 个答案: