订阅者永远不会获得整个队列

Question

我们正在与 PubSub 合作，将多个系统相互集成。某些系统可能会将数据作为 JSON 推送到 PubSub，而其他系统则可以提取该数据并使用它。（注意：由于接收应用程序的其他限制，我们必须从 PubSub 拉取而不是推送到应用程序）每个拉取应用程序都会获得每个主题的自己的订阅者。

\n\n

我注意到，如果触发过于频繁，PubSub 拉取不会获取队列中当前的所有数据。该问题最初发生在具有相应库的 Java Spring 应用程序中，但云控制台中的 gcloud 命令表现出相同的行为，因此我将仅使用该示例。我删除了 ack-id 和边框以使其适合此窗口。请注意，我不使用“--auto-ack”标志，因此队列应保持不变，没有其他系统从该订阅者中提取数据。

\n\n

首先拉取（完整内容）： \nmax_binnewies@cloudshell:~ $ gcloud pubsub subscriptions pull testSubscriber --limit=100

\n\n

\xe2\x94\x82    DATA   \xe2\x94\x82    MESSAGE_ID   \xe2\x94\x82 \n\xe2\x94\x82 4 - FOUR  \xe2\x94\x82 189640873208084 \xe2\x94\x82\n\xe2\x94\x82 5 - FIVE  \xe2\x94\x82 189636274179799 \xe2\x94\x82 \n\xe2\x94\x82 2 - TWO   \xe2\x94\x82 189638666587304 \xe2\x94\x82 \n\xe2\x94\x82 3 - THREE \xe2\x94\x82 189627470480903 \xe2\x94\x82  \n\xe2\x94\x82 1 - ONE   \xe2\x94\x82 189639207684195 \xe2\x94\x82\n

\n\n

第二次拉动（只有一次）： \nmax_binnewies@cloudshell:~ $ gcloud pubsub subscriptions pull testSubscriber --limit=100

\n\n

\xe2\x94\x82   DATA  \xe2\x94\x82    MESSAGE_ID   \xe2\x94\x82\n\xe2\x94\x82 1 - ONE \xe2\x94\x82 189639207684195 \xe2\x94\x82\n

\n\n

第三次拉动（两个不同的）： \nmax_binnewies@cloudshell:~ $ gcloud pubsub subscriptions pull testSubscriber --limit=100

\n\n

\xe2\x94\x82   DATA   \xe2\x94\x82    MESSAGE_ID   \xe2\x94\x82 \n\xe2\x94\x82 4 - FOUR \xe2\x94\x82 189640873208084 \xe2\x94\x82 \n\xe2\x94\x82 5 - FIVE \xe2\x94\x82 189636274179799 \xe2\x94\x82\n

\n\n

第四次拉动（再次拉动第一个）： \nmax_binnewies@cloudshell:~ $ gcloud pubsub subscriptions pull testSubscriber --limit=100

\n\n

\xe2\x94\x82   DATA  \xe2\x94\x82    MESSAGE_ID   \xe2\x94\x82\n\xe2\x94\x82 1 - ONE \xe2\x94\x82 189639207684195 \xe2\x94\x82\n

\n\n

这种行为让我感到困惑。这是正常的 PubSub 行为还是我做错了什么？我唯一发现的是这个链接，它说 PubSub 使用拉取方法的负载平衡：\n https://cloud.google.com/pubsub/docs/subscriber \n所以我认为订阅者认为多个客户端正在订阅如果呼叫来得太快，则会分散数据。那是对的吗？这里到底发生了什么？\n如果我等一会儿，我会再次获得更多数据，但即使我等五分钟，我似乎也永远不会获得所有数据......这非常令人困惑。\n这会给消费应用程序带来问题吗？即使拉取非常频繁，如何确保所有数据都到达接收应用程序？有办法关掉它吗？

\n

Answer 1

有几种原因会导致您每次都没有收到所有消息：

1. 对于拉取请求，无法保证所有消息都会在特定请求中返回，即使可用消息数少于最大消息数。这是因为 Pub/Sub 尝试在返回更多消息与最小化端到端延迟之间取得平衡。

2. 消息有一个确认截止时间，该截止时间在订阅创建时间上指定（默认为 10 秒）。这意味着，当您拉取消息并且不对其进行 ack 或 nack 时，它们将不会在 ack 截止日期期间重新传送，基本上为拉取消息的进程提供了租约。如果您希望立即重新传送消息，nack并且您使用的是Java 客户端库（与 Cloud Pub/Sub 交互的首选方式），或者您需要发送设置为 0 的ModifyAckDeadline请求，则需要它们ack_deadline_seconds。