使用 Google Pub/Sub 时如何处理“毒丸”消息？答案

【问题标题】：How do I deal with 'poison pill' messages when using Google Pub/Sub?使用 Google Pub/Sub 时如何处理“毒丸”消息？
【发布时间】：2017-02-24 10:30:15
【问题描述】：

例如，当使用 Amazon 的 SQS 时，我可以定义一个死信队列 (DLQ)，其中任何在 X 次重试后未能删除 (ack'd) 的消息将被路由到单独处理.. 但它是 Google Cloud平台我没有看到任何提及这个

【问题讨论】：

这能回答你的问题吗？ What is the equivalent of AWS Dead Letter Queue in Google Cloud Platform?
问题是关于毒信的，但细节是关于死信的，这些绝不是一回事。如果不对管道中某处的代码进行更改，毒消息就无法成功处理。死信是由于临时中断而延迟后可以成功处理的信。

标签： google-cloud-pubsub

【解决方案1】：

Google Cloud Pub/Sub 目前没有任何自动死信队列。如果您担心“毒丸”消息，您将不得不通过持续保持从消息 ID 到消息已传递次数的映射来以某种方式自己支持这一点。在读取消息中的数据之前，您将在订阅者中更新此映射。确认后，您从地图中删除。如果计数超过某个阈值，您可以将其发布到单独的 Cloud Pub/Sub 主题，用于跟踪此类消息，然后确认消息。

【讨论】：

距离最初的回应仅 1.5 年多一点，我很好奇这方面是否有任何更新的最佳实践。 pub/sub 是否提供任何用于错误处理/路由的原语？或者这个逻辑是否需要被加入到订阅中以“重新发布”任何 nacked 消息？
正在考虑中，但这个答案仍然是正确的。
@Tkwon123 请看我对这个问题的回答，终于有可能了；）
确实！谢谢@grzechoo - 添加一个链接到您的评论 - stackoverflow.com/questions/55568906/… 和更新的文档以供参考 cloud.google.com/sdk/gcloud/reference/pubsub/subscriptions/…

【解决方案2】：

Cloud Pub/Sub 现在支持Dead Letter Queues，可用于处理毒丸消息。

【讨论】：