pubsub 中订阅者的重试设置是什么？如何在 spring 应用程序中正确设置它们？
what are the retry settings for subscriber in pubsub and how to set them correctly in a spring application?
我有一个 spring 服务订阅来自 google 云 pubsub（拉取）中的主题的消息。它通常工作正常。但我想更好地控制重新发送的消息。我的服务有时需要 nack 消息或只是让 ackDeadline 通过，以便我稍后再次收到消息。在使用单个消息进行测试时，nacked 消息几乎立即返回给我，而那些我根本不确认或 nack 的消息在 ackDeadline 默认值 10 秒后返回。我希望它推迟重复使用这些消息。我认为重试设置是为这种情况设计的。
我还应该提到，我目前正在使用模拟器在本地进行测试，并通过代码创建订阅。我正在使用 PubSubAdmin 进行管理。
根据这个 docu 我已经尝试在我的配置文件配置中设置这些配置。像这样：
spring.cloud.gcp.pubsub.subscriber.retry.initial-retry-delay-second: 4
spring.cloud.gcp.pubsub.subscriber.retry.max-attempts: 5
spring.cloud.gcp.pubsub.subscriber.retry.initial-rpc-timeout-seconds: 4
spring.cloud.gcp.pubsub.subscriber.retry.max-rpc-timeout-seconds: 8
spring.cloud.gcp.pubsub.subscriber.retry.max-retry-delay-seconds: 7
spring.cloud.gcp.pubsub.subscriber.retry.total-timeout-seconds: 3000
但对消息重现时间没有影响。
我是不是理解错了重试设置的意思？也许它们只有在存在一些连接问题时才会生效，但不会在 nacking 或缺乏确认的情况下生效？或者我是否必须在使用 deploymentManager 创建订阅时设置设置并且不允许从代码中设置它们？或者在（开发）配置文件配置中设置它们不适用于 PubSubAdmin？
感谢您的任何建议！
编辑：我希望第一次重试在 5 秒后发生，但下一次重试会在 10 秒后，依此类推。另外我想设置最大重试次数。所以我不感兴趣的是将 ackDeadline 设置为更大的数字。
edit2：为什么 nacking：其中一项服务（我们称它为桥接器）正在订阅消息，必须验证每条消息，如果可以，则将其传递给另一个外部系统。此服务充当此系统的桥梁，因为我们无法直接在第二个系统上工作。在某些情况下，消息需要一些额外的信息，因此桥会尝试在其他地方获取它（包含很多微服务），有时会发生这种情况，此时（还）没有额外信息。所以第一个想法是不确认消息，让它稍后再来。但我不想在接下来的 7 天内每 10 秒询问一次（使用 ackDeadline），我只想尝试几次，如果 2 小时后不存在，它将永远不会出现。所以我们尝试 nack 并希望这些重试设置可以帮助管理重新发送。但由于他们没有，我想唯一的办法就是自己构建一些东西来管理桥中的这些消息。也许存储消息 ID 和重试次数，以便我可以在例如 5 次之后确认并将消息推送到另一个主题以不同方式处理它。或者有没有已知更好的解决方案？
您可以使用 PubSubSubscriberTemplate.modifyAckDeadline() 以编程方式延长通过拉取检索的一批消息的截止日期。每个人 AcknowledgeablePubsubMessage 也有一个 modifyAckDeadline() 方法，如果你只需要延长 select 少数掉队者的截止日期。
如果该特定订阅上的所有消息都需要更长的确认期，则可以通过编辑订阅并更新 "Acknowledgement Deadline" 字段在 GCP Console 中设置默认值。
Cloud Pub/Sub 不为特定消息提供指数退避。 nack 除了告诉 Cloud Pub/Sub 您无法处理该消息外没有其他作用。
如果您要记录为什么需要取消消息，我可以提供更有用的答案。如果您无法处理当前负载，您可以使用 here 中描述的流控制选项来减少发送给客户端的未完成消息或字节数。如果您有已知的不良消息，您应该在推送到另一个死信主题以单独处理后确认它们。
对编辑 2 的回复：
如果您遇到补充消息的操作可能会失败的情况，请在您的服务中自行实施您希望对该操作执行的任何退避机制。在构建您的订阅者时设置最大确认延长期（java 中的 setMaxAckExtensionPeriod）以确保您的客户端将每条消息的确认截止日期延长足够长的时间以进行重试。
编辑 2
请注意 Pub/Sub 现在内置了对 Dead Lettering 的支持。
我有一个 spring 服务订阅来自 google 云 pubsub（拉取）中的主题的消息。它通常工作正常。但我想更好地控制重新发送的消息。我的服务有时需要 nack 消息或只是让 ackDeadline 通过，以便我稍后再次收到消息。在使用单个消息进行测试时，nacked 消息几乎立即返回给我，而那些我根本不确认或 nack 的消息在 ackDeadline 默认值 10 秒后返回。我希望它推迟重复使用这些消息。我认为重试设置是为这种情况设计的。 我还应该提到，我目前正在使用模拟器在本地进行测试，并通过代码创建订阅。我正在使用 PubSubAdmin 进行管理。
根据这个 docu 我已经尝试在我的配置文件配置中设置这些配置。像这样：
spring.cloud.gcp.pubsub.subscriber.retry.initial-retry-delay-second: 4
spring.cloud.gcp.pubsub.subscriber.retry.max-attempts: 5
spring.cloud.gcp.pubsub.subscriber.retry.initial-rpc-timeout-seconds: 4
spring.cloud.gcp.pubsub.subscriber.retry.max-rpc-timeout-seconds: 8
spring.cloud.gcp.pubsub.subscriber.retry.max-retry-delay-seconds: 7
spring.cloud.gcp.pubsub.subscriber.retry.total-timeout-seconds: 3000
但对消息重现时间没有影响。 我是不是理解错了重试设置的意思？也许它们只有在存在一些连接问题时才会生效，但不会在 nacking 或缺乏确认的情况下生效？或者我是否必须在使用 deploymentManager 创建订阅时设置设置并且不允许从代码中设置它们？或者在（开发）配置文件配置中设置它们不适用于 PubSubAdmin？ 感谢您的任何建议！
编辑：我希望第一次重试在 5 秒后发生，但下一次重试会在 10 秒后，依此类推。另外我想设置最大重试次数。所以我不感兴趣的是将 ackDeadline 设置为更大的数字。
edit2：为什么 nacking：其中一项服务（我们称它为桥接器）正在订阅消息，必须验证每条消息，如果可以，则将其传递给另一个外部系统。此服务充当此系统的桥梁，因为我们无法直接在第二个系统上工作。在某些情况下，消息需要一些额外的信息，因此桥会尝试在其他地方获取它（包含很多微服务），有时会发生这种情况，此时（还）没有额外信息。所以第一个想法是不确认消息，让它稍后再来。但我不想在接下来的 7 天内每 10 秒询问一次（使用 ackDeadline），我只想尝试几次，如果 2 小时后不存在，它将永远不会出现。所以我们尝试 nack 并希望这些重试设置可以帮助管理重新发送。但由于他们没有，我想唯一的办法就是自己构建一些东西来管理桥中的这些消息。也许存储消息 ID 和重试次数，以便我可以在例如 5 次之后确认并将消息推送到另一个主题以不同方式处理它。或者有没有已知更好的解决方案？
您可以使用 PubSubSubscriberTemplate.modifyAckDeadline() 以编程方式延长通过拉取检索的一批消息的截止日期。每个人 AcknowledgeablePubsubMessage 也有一个 modifyAckDeadline() 方法，如果你只需要延长 select 少数掉队者的截止日期。
如果该特定订阅上的所有消息都需要更长的确认期，则可以通过编辑订阅并更新 "Acknowledgement Deadline" 字段在 GCP Console 中设置默认值。
Cloud Pub/Sub 不为特定消息提供指数退避。 nack 除了告诉 Cloud Pub/Sub 您无法处理该消息外没有其他作用。
如果您要记录为什么需要取消消息，我可以提供更有用的答案。如果您无法处理当前负载，您可以使用 here 中描述的流控制选项来减少发送给客户端的未完成消息或字节数。如果您有已知的不良消息，您应该在推送到另一个死信主题以单独处理后确认它们。
对编辑 2 的回复：
如果您遇到补充消息的操作可能会失败的情况，请在您的服务中自行实施您希望对该操作执行的任何退避机制。在构建您的订阅者时设置最大确认延长期（java 中的 setMaxAckExtensionPeriod）以确保您的客户端将每条消息的确认截止日期延长足够长的时间以进行重试。
编辑 2
请注意 Pub/Sub 现在内置了对 Dead Lettering 的支持。