Pub Sub 推送订阅中一次可以有多少条未确认的消息答案

【问题标题】：At a time how many unacked messages can be in a Pub Sub push subscriptionPub Sub 推送订阅中一次可以有多少条未确认的消息
【发布时间】：2021-04-23 13:39:07
【问题描述】：

Pub Sub 推送订阅中一次可以有多少未确认的消息。

如果订阅的消息超过 100 条，它将如何影响新的消息传递。

【问题讨论】：

“在 Pub Sub 推送订阅中”是什么意思？突出到推送端点？存储以交付到推送端点？
我的意思是未确认的消息数

标签： google-cloud-platform google-cloud-functions google-cloud-pubsub

【解决方案1】：

订阅中未确认消息的数量没有限制。限制因素是订阅的消息保留时间，可以配置在 10 分钟到 7 天之间。一旦消息年龄超过此值，即使订阅者未确认该消息，该消息也会被删除。

消息可以在以下两种状态之一中被取消确认：已交付给订阅者或尚未交付给订阅者。如果订阅者处理消息的能力跟不上消息发布的速度，则消息将不会传递给订阅者。如果您的推送端点一直在响应错误或截止日期已过，则 Cloud Pub/Sub 会在传递更多消息时退出。

如果您有很多未确认的消息，但已经未处理到推送端点，那么这可能会延迟新发布的消息的传递，具体取决于当前允许的同时未处理消息的数量，即“推送窗口”。

quotas, limits and delivery rate section of the documentation 有更多详细信息。

【讨论】：

我有这个云功能推送端点，它将根据用例在需要时通过返回错误来处理消息。也有退避时间 10（最小退避）到 15 秒（最大退避）和最大交付尝试为 5。保留期设置为 1 小时。 5 次尝试后配置的死信。请注意，当未确认的消息计数超过 100 条左右时，新消息不会传递到推送端点（云功能）。预计每分钟大约 1000 条消息。在最坏的情况下，一半的消息可以被 nack 重试。
几个问题 1. 如果 Pub 订阅由于推送端点的错误而延迟交付，那么订阅中声明的退避重试将不会被兑现。那是对的吗？ 2. 考虑到推送点/推送窗口的未完成消息的数量，我们什么时候应该使用重试机制，有什么指导方针吗？ 3.更改保留时间，在这种情况下，很多未完成的消息到推送点，发布订阅延迟新消息。这是个好主意吗？
订阅重试设置和推送回退是不同的：前者只影响未确认的消息，而后者影响所有发送。对于推送，单个 nack 会减慢所有消息的传递速度。我不确定你说的第二个问题是什么意思。没有选择是否在 nacks 上的推送端点发生退避，它总是发生并且无法配置。当您需要更改您认为订阅者在出现故障时赶上和处理消息需要多长时间时，更改保留时间非常有用。
nack 上的推送端点是否发生退避没有选择，它总是发生并且无法配置 如果由于推送点导致单个 nack发生错误，然后在重试设置的退避时间，pub sub 不会重试传递它。这真的取决于推送窗口。
当您需要更改您认为订阅者在出现故障时赶上和处理消息需要多长时间时，更改保留时间很有用我们不能当订阅中有太多 nacked 消息（由于错误）并由于 nack 而延迟新消息传递时，正确配置保留。如果推送窗口相对于 nacked 消息的数量呈指数增长，则可能会丢失数据。如果我们将保留时间配置得更少，我们可能会丢失数据。