我有几个问题与GCP中的上述主题有关。如果有人能详细地解释一下，那将是非常有帮助的。非常感谢。我查阅了一些文档，但找不到简明的答案。
我的理解：
- 确认截止日期：例如，如果此功能设置为10秒，则它会在10秒内等待订阅者确认消息，否则在10秒后它会重新发送消息
问题1：在推送订户的情况下，pubsub服务在等待确认截止日期结束10秒后再次向订户重新发送/推送消息。在拉取消息的情况下，订阅者第一次尝试拉取消息，一旦他拉取，10秒ack截止日期时钟就会启动，所以在这段时间内，如果订阅者再次尝试拉取该消息，他们会不会收到消息，因为队列将关闭10秒？
- 消息保留持续时间：默认设置为7天。所有发送给订阅者但未被订阅者确认的消息，在某些重试尝试(例如5次)后，在5次重试后，它们在主题中停留7天，7天后被删除
问题2：但是，即使在最大重试次数之后，订阅者在对主题进行的每次拉取中都会收到这些消息吗？
- 死信：死信主题是一个可以创建的主题，用于将坏/错误从主主题转发到死信主题
问题3：这里的坏消息是指pubsub服务无法传递给订阅者的消息，还是订阅者无法确认的消息。但在第二种情况下，订阅者无法确认。这也可能意味着消息可能很好，但订阅者没有确认。在这种情况下，由于消息保留期设置为7天，它们会停留在同一主题中吗？或者，如果死信是由订阅创建的，那么pubsub服务是否有责任将消息转发到死信主题？
- 重试策略：这里有两个选项1。retryimmediate：选择后，如果订阅者在ack截止日期前没有确认消息，pubsub-servcie会尝试立即将消息传递给订阅者。第二个选项：使用指数退避重试：当选择该选项时，pubsub服务会在将消息重新发送给订阅者之前尝试提供延迟，它可以做的最大延迟是最大指数退避。问题4：让我们在这里举一个例子：假设我将确认截止日期设置为10秒。并将重试策略设置为最小指数回退为30秒，最大回退为600秒。因此，在这种情况下，如果订阅者第一次拉取消息，但没有确认，ack截止日期时钟开始，假设它结束，那么如果订阅者第二次拉取，pubsub服务是否会再等待30秒(最小指数后退)，然后再尝试重新传递消息
谢谢。
我们建议使用我们支持的客户端库，它应该自动延长ack截止日期。一般来说，请找到以下答案：
因此，在此期间，如果订阅者再次尝试拉取消息，他们将不会收到消息，因为队列将关闭10秒
在该时间段内，您将不会再次收到相同的消息。您仍然可以从积压工作中提取其他消息。请注意，这是一个尽最大努力的功能，有时您可能会在ack截止日期内再次收到消息。
但是，即使在重试次数达到最大值后，订阅者在对主题进行的每次拉取中都会收到这些消息吗
您在哪里配置最大重试次数？Cloud Pub/Sub仅将此最大交付尝试作为死信队列的一部分提供。如果配置了死信队列，则在重试一定次数后，消息将中继到死信主题，并从父订阅中删除。否则，消息将保留在父订阅上，Cloud Pub/Sub将在可能的情况下尝试传递消息。
这里的错误消息，是指pubsub服务无法传递给订阅者的消息，还是订阅者无法确认的消息。但在第二种情况下，订阅者无法确认。这也可能意味着消息可能很好，但订阅者没有确认。在这种情况下，由于消息保留期设置为7天，它们会停留在同一主题中吗？或者，如果死信是由订阅创建的，那么pubsub服务是否有责任将消息转发到死信主题？
此上下文中的错误消息将为the messages which the subscribers are not able to ack。如果订阅者不想对消息进行死信处理，即使他们无法处理这些消息，他们也不应该使用死信队列。如果您同意在失败情况下从订阅中删除消息，那么死信队列是理想的选择。超过7天保留期的邮件不会系统地移至死信主题。
假设我将ack截止日期设置为10秒。并将重试策略设置为最小指数回退为30秒，最大回退为600秒。因此，在这种情况下，如果订阅者第一次拉取消息，但没有确认，ack截止日期时钟开始，假设它结束，那么如果订阅者第二次拉取，pubsub服务是否会再等待30秒(最小指数后退)，然后再尝试重新传递消息？
这是正确的。这个答案可能也很有用：GCP PubSub重试回退时间。
我希望这会有所帮助。