GCP 中的确认截止日期、消息保留期限、死信和重试策略
Ack Deadline, Message Retention Duration, Dead Lettering and Retry Policy in GCP
我有几个与 GCP 中的上述主题相关的问题。如果有人可以详细解释它们，那将有很大帮助。谢谢你。我浏览了一些文档，但找不到简明的答案。
我的理解：
- 确认截止时间：例如，如果此功能设置为 10 秒，则它会等待订阅者在 10 秒内确认消息，否则在 10 秒后它会重新发送消息。
问题一：
在推送订阅者的情况下，pubsub 服务 redelivers/pushes 在等待 ack 截止时间结束 10 秒后再次向订阅者发送消息。
在拉取消息的情况下，订阅者第一次尝试拉取消息，一旦他拉取，10secs ack deadline 时钟开始，所以在这段时间内如果订阅者再次尝试拉取消息，他们会不会收到作为队列的消息将关闭 10 秒？
- 消息保留期限：默认设置为 7 天。所有发送给订阅者但未被订阅者确认的消息，在某些重试尝试之后，例如 5 次，在 5 次重试后，它们在主题中停留 7 天，7 天后被删除。
问题二：
但是订阅者是否会在他们对主题所做的每次拉动中收到这些消息，即使在最大重试之后也是如此？
- 死信：死信主题是您可以创建的主题，用于将 bad/erroneous 从主要主题转发到死信主题。
问题三：
这里的错误消息，是指无法通过 pubsub 服务传递给订阅者的消息，还是订阅者无法确认的消息。但在第二种情况下，订阅者无法确认。这也可能意味着消息可能很好，但订阅者没有确认它们。在这种情况下，由于消息保留设置为 7 天，它们是否会留在同一主题中，或者如果死信是由订阅创建的，是否由 pubsub 服务负责将消息转发到死信主题？
- 重试策略：这里有两个选项 1. 立即重试：选择后，如果订阅者在确认截止日期前没有确认消息，则发布订阅服务会立即重试将消息传递给订阅者。第二个选项：使用指数退避重试：选择后，pubsub 服务会尝试在将消息重新传递给订阅者之前延迟，它可以做的最大延迟是最大指数退避。
问题四：
让我们在这里举个例子：
假设我将确认截止日期设置为 10 秒。并将重试策略设置为最小指数退避为 30 秒，最大为 600 秒。因此，在这种情况下，如果订阅者第一次拉取消息但不确认它，则确认截止时间时钟开始并可以说它结束，然后如果订阅者第二次拉取它，pubsub 服务会再等待 30 秒（最小指数退避）在它尝试重新传递消息之前？
谢谢。
我们建议使用我们支持的客户端库，它应该会自动延长确认截止日期。一般而言，请在下面找到答案：
so during this time if the subscriber tries to pull the message again, will they not receive the messages as the queue will be closed for 10secs
您不会在该时间段内再次收到相同的消息。您仍然可以从积压中提取其他消息。请注意，这是一项尽力而为的功能，有时您可能会在确认截止日期内再次收到消息。
But will the subscriber be getting these messages in each pull they do on the topic, even after max retries
您在哪里配置最大重试次数？ Cloud Pub/Sub 仅将此最大投递尝试次数作为死信队列的一部分提供。如果您配置了死信队列，消息将在一定次数的重试后中继到死信主题，并从父订阅中删除。否则，消息将保留在父订阅中，Cloud Pub/Sub 将在可能时尝试传递它。
Bad messages here, do they mean the messages which cannot be delivered by the pubsub service to the subscribers or the messages which the subscribers are not able to ack. But in the second case where the subscribers are not able to ack. It can also mean that messages might be good but the subscriber is not acking them. In this case, as message retention is set for 7 days, will they stay in the same topic or if the dead letter is created by the subscription, will it be the responsibility of the pubsub service to forward the messages to the dead letter topic?
在此上下文中的错误消息将是 the messages which the subscribers are not able to ack。如果订阅者不想死信一条消息，即使他们无法处理它们，他们也不应该使用死信队列。如果您同意在失败情况下从订阅中删除消息，那么死信队列是理想的选择。超过 7 天保留期 window 的消息不会系统地移动到死信主题。
Say I set the ack deadline to 10 secs. And set the retry policy to minimum exponential backoff to 30 secs and maximum to 600 seconds. So in this case if the subscriber pulls the message for the first time but doesn't acknowledge it, the ack deadline clock starts and lets say it ends, then if the subscriber pulls it the second time does the pubsub service wait for another 30 seconds (minimum exponential backoff) before it tries to redeliver the message?
没错。这个答案也可能有用：.
希望对您有所帮助。
我有几个与 GCP 中的上述主题相关的问题。如果有人可以详细解释它们，那将有很大帮助。谢谢你。我浏览了一些文档，但找不到简明的答案。
我的理解：
- 确认截止时间：例如，如果此功能设置为 10 秒，则它会等待订阅者在 10 秒内确认消息，否则在 10 秒后它会重新发送消息。
问题一： 在推送订阅者的情况下，pubsub 服务 redelivers/pushes 在等待 ack 截止时间结束 10 秒后再次向订阅者发送消息。 在拉取消息的情况下，订阅者第一次尝试拉取消息，一旦他拉取，10secs ack deadline 时钟开始，所以在这段时间内如果订阅者再次尝试拉取消息，他们会不会收到作为队列的消息将关闭 10 秒？
- 消息保留期限：默认设置为 7 天。所有发送给订阅者但未被订阅者确认的消息，在某些重试尝试之后，例如 5 次，在 5 次重试后，它们在主题中停留 7 天，7 天后被删除。
问题二： 但是订阅者是否会在他们对主题所做的每次拉动中收到这些消息，即使在最大重试之后也是如此？
- 死信：死信主题是您可以创建的主题，用于将 bad/erroneous 从主要主题转发到死信主题。
问题三： 这里的错误消息，是指无法通过 pubsub 服务传递给订阅者的消息，还是订阅者无法确认的消息。但在第二种情况下，订阅者无法确认。这也可能意味着消息可能很好，但订阅者没有确认它们。在这种情况下，由于消息保留设置为 7 天，它们是否会留在同一主题中，或者如果死信是由订阅创建的，是否由 pubsub 服务负责将消息转发到死信主题？
- 重试策略：这里有两个选项 1. 立即重试：选择后，如果订阅者在确认截止日期前没有确认消息，则发布订阅服务会立即重试将消息传递给订阅者。第二个选项：使用指数退避重试：选择后，pubsub 服务会尝试在将消息重新传递给订阅者之前延迟，它可以做的最大延迟是最大指数退避。 问题四： 让我们在这里举个例子： 假设我将确认截止日期设置为 10 秒。并将重试策略设置为最小指数退避为 30 秒，最大为 600 秒。因此，在这种情况下，如果订阅者第一次拉取消息但不确认它，则确认截止时间时钟开始并可以说它结束，然后如果订阅者第二次拉取它，pubsub 服务会再等待 30 秒（最小指数退避）在它尝试重新传递消息之前？
谢谢。
我们建议使用我们支持的客户端库，它应该会自动延长确认截止日期。一般而言，请在下面找到答案：
so during this time if the subscriber tries to pull the message again, will they not receive the messages as the queue will be closed for 10secs
您不会在该时间段内再次收到相同的消息。您仍然可以从积压中提取其他消息。请注意，这是一项尽力而为的功能，有时您可能会在确认截止日期内再次收到消息。
But will the subscriber be getting these messages in each pull they do on the topic, even after max retries
您在哪里配置最大重试次数？ Cloud Pub/Sub 仅将此最大投递尝试次数作为死信队列的一部分提供。如果您配置了死信队列，消息将在一定次数的重试后中继到死信主题，并从父订阅中删除。否则，消息将保留在父订阅中，Cloud Pub/Sub 将在可能时尝试传递它。
Bad messages here, do they mean the messages which cannot be delivered by the pubsub service to the subscribers or the messages which the subscribers are not able to ack. But in the second case where the subscribers are not able to ack. It can also mean that messages might be good but the subscriber is not acking them. In this case, as message retention is set for 7 days, will they stay in the same topic or if the dead letter is created by the subscription, will it be the responsibility of the pubsub service to forward the messages to the dead letter topic?
在此上下文中的错误消息将是 the messages which the subscribers are not able to ack。如果订阅者不想死信一条消息，即使他们无法处理它们，他们也不应该使用死信队列。如果您同意在失败情况下从订阅中删除消息，那么死信队列是理想的选择。超过 7 天保留期 window 的消息不会系统地移动到死信主题。
Say I set the ack deadline to 10 secs. And set the retry policy to minimum exponential backoff to 30 secs and maximum to 600 seconds. So in this case if the subscriber pulls the message for the first time but doesn't acknowledge it, the ack deadline clock starts and lets say it ends, then if the subscriber pulls it the second time does the pubsub service wait for another 30 seconds (minimum exponential backoff) before it tries to redeliver the message?
没错。这个答案也可能有用：
希望对您有所帮助。