GCP 中的确认截止日期、消息保留时间、死信和重试策略

Posted 2023-02-16

【中文标题】GCP 中的确认截止日期、消息保留时间、死信和重试策略

【英文标题】：Ack Deadline, Message Retention Duration, Dead Lettering and Retry Policy in GCP

【发布时间】：2021-10-16 21:25:50

【问题描述】：

我有几个与 GCP 中的上述主题相关的问题。如果有人可以详细解释它们，那将是非常有帮助的。谢谢你。我浏览了一些文档，但找不到简明的答案。

我的理解：

确认截止日期：例如，如果此功能设置为 10 秒，则它会在 10 秒内等待订阅者确认消息，否则在 10 秒后重新传递消息。

问题1： 在推送订阅者的情况下，pubsub 服务在等待 10 秒以使 ack 截止日期结束后再次将消息重新传递/推送给订阅者。 在pull消息的情况下，subscriber第一次尝试pull消息，一旦他pull，10secs ack截止时间时钟就会开始，所以在此期间如果subscriber再次尝试pull消息，他们会不会收到消息作为队列将关闭 10 秒？

消息保留时间：默认设置为 7 天。所有已传递给订阅者但未得到订阅者确认的消息，经过某些重试尝试（例如 5 次）后，在 5 次重试后，它们会在主题中停留 7 天，并在 7 天后被删除。

问题 2： 但是订阅者是否会在每次拉取主题时收到这些消息，即使在最大重试次数之后？

Dead lettering：Dead lettering 主题是您可以创建的主题，用于将主要主题中的坏/错误转发到死信主题。

问题 3： 这里的坏消息，是指无法通过 pubsub 服务传递给订阅者的消息还是订阅者无法确认的消息。但在第二种情况下，订阅者无法确认。这也可能意味着消息可能很好，但订阅者没有确认它们。在这种情况下，由于消息保留设置为 7 天，它们会留在同一个主题中，还是如果订阅创建了死信，是否由 pubsub 服务负责将消息转发到死信主题？

Retry Policy: There are two options here 1. retry immediately: which when selected the pubsub servcie retries to deliver the message immediately to the subscriber if the subscriber doesn't ack the message before the ack deadline.第二个选项：使用指数退避重试：选择该选项后，发布订阅服务会尝试在将消息重新传递给订阅者之前给出延迟，并且它可以做的最大延迟是最大指数退避。 问题4： 让我们在这里举个例子： 假设我将确认截止日期设置为 10 秒。并将重试策略设置为最小指数退避为 30 秒，最大为 600 秒。因此，在这种情况下，如果订阅者第一次拉出消息但没有确认，则确认截止时间时钟开始并假设它结束，那么如果订阅者第二次拉出消息，pubsub 服务会再等待 30 秒（最小指数退避）在尝试重新传递消息之前？

谢谢。

【参考方案1】：

我们建议使用我们支持的客户端库，它会自动延长确认期限。一般而言，请在下面找到答案：

所以在此期间如果订阅者再次尝试拉取消息，他们会不会收到消息，因为队列将关闭 10 秒

您不会在该时间段内再次收到相同的消息。您仍然可以从积压中提取其他消息。请注意，这是一项尽力而为的功能，有时您可能会在确认截止日期内再次收到该消息。

但订阅者是否会在每次拉取主题时收到这些消息，即使在最大重试次数之后也是如此

您在哪里配置最大重试次数？ Cloud Pub/Sub 仅在死信队列中提供此最大传递尝试次数。如果您配置了死信队列，则消息将在重试一定次数后转发到死信主题并从父订阅中删除。否则，消息将保留在父订阅中，Cloud Pub/Sub 将尽可能尝试传递它。

这里的错误消息，是指无法通过 pubsub 服务传递给订阅者的消息还是订阅者无法确认的消息。但在第二种情况下，订阅者无法确认。这也可能意味着消息可能很好，但订阅者没有确认它们。在这种情况下，由于消息保留设置为 7 天，它们会留在同一个主题中，还是如果订阅创建了死信，是否由 pubsub 服务负责将消息转发到死信主题？

此上下文中的错误消息将是the messages which the subscribers are not able to ack。如果订阅者即使无法处理消息也不想死信，那么他们不应该使用死信队列。如果您同意在失败情况下从订阅中删除消息，死信队列是理想的选择。超过 7 天保留期的邮件不会系统地移至死信主题。

假设我将确认截止日期设置为 10 秒。并将重试策略设置为最小指数退避为 30 秒，最大为 600 秒。因此，在这种情况下，如果订阅者第一次拉取消息但没有确认，确认截止时间时钟开始并假设它结束，那么如果订阅者第二次拉取消息，pubsub 服务会再等待 30 秒（最小指数退避）在尝试重新传递消息之前？

没错。这个答案也可能有用：GCP PubSub retry backoff timing。

我希望这会有所帮助。

【讨论】：

这个答案非常有用。谢谢@Mahesh Gattani。但唯一有点令人困惑的是最小和最大指数退避如何为拉动订阅者工作。

是的。重试策略适用于所有订阅类型。