Question

我很困惑，为什么在同步确认消息后我的gcloud pub / sub队列没有缩小。我的队列很小（消息不超过几百条），并且使用的代码与gcloud文档中的代码非常相似：

from google.cloud import pubsub_v1 as pubsub

NUM_MESSAGES = 1
PROJECT = 'my_project'
SUBSCRIPTION = 'my_sub'

subscriber = pubsub.SubscriberClient()
subscription_path = subscriber.subscription_path(PROJECT, SUBSCRIPTION)

with subscriber:
    response = subscriber.pull(
        request={"subscription": subscription_path, "max_messages": NUM_MESSAGES}
    )

    todo = []
    for received_message in response.received_messages:
        todo += [received_message.message.data]
        subscriber.acknowledge(
            request={"subscription": subscription_path, "ack_ids": [received_message.ack_id]}
        )

我知道消息已成功确认，因为在监视中可以看到：

，但是队列的大小完全相同：

这是怎么回事？关于我在做什么错的任何想法吗？

Answer 1

您未订阅PUBSUB，示例中就是这样。

response = subscriber.subscribe(subscription_path, callback=callback)

https://cloud.google.com/pubsub/docs/quickstart-client-libraries

Answer 2

仅仅因为您成功了一些，并不一定意味着您的整个Pub / Sub积压工作都将被清除。这里有几件事需要检查以更好地了解正在发生的事情：

subscription/oldest_unacked_message_age指标的值是多少？它在增加吗？如果是这样，则意味着您的待办事项中至少有一条消息永远不会被确认。
您能否检查您的订阅者确认消息需要多长时间？（通常可以通过登录订阅作业来实现。）如果确认时间长于订阅的确认期限，则PubSub将尝试重新发送邮件。（请参阅：https://cloud.google.com/pubsub/docs/subscriber#at-least-once-delivery）这些重复的消息可能会积压在积压的订单中，并且需要自己进行拉取和确认。

最后，根据Pub/Sub synchronous pull documentation：

“请注意，通过同步可实现较低的消息传递延迟拉，重要的是要同时拥有许多出色的拉力请求。

您一次只拉出一条消息（在您的示例中，NUM_MESSAGES = 1），因此始终保持打开状态的Pull（至少在清除积压之前）尤其重要，这样Pub / Sub总是有机会在准备就绪时传递您的消息。

Answer 3

我建议您延长邮件的租约，以使它们的确认截止日期不过期（当前可能有一些确认截止日期到期，导致邮件重新发送）。

请确保您不对消息进行处理，也要增加发送的请求请求的数量。最佳做法是，在任何给定时间打开大量重叠的请求，以获得更好的订户吞吐量。

成功确认后，发布/订阅消息仍未送达

3 个答案: