成功确认后，发布/订阅消息仍未传递答案

【问题标题】：Pub/sub messages remain undelivered after successful acknowledgment成功确认后，发布/订阅消息仍未传递
【发布时间】：2021-02-15 06:45:03
【问题描述】：

我很困惑为什么我的 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]}
        )

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

但队列的大小仍然完全相同：

这里发生了什么？关于我做错了什么有什么想法吗？

【问题讨论】：

标签： python gcloud google-cloud-pubsub

【解决方案1】：

您没有订阅您的 PUBSUB，示例中有这样的内容。

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

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

【讨论】：

这是异步订阅的解决方案。我正在尝试实现同步拉取，如下所示：cloud.google.com/pubsub/docs/pull#synchronous_pull

【解决方案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 始终有机会在您的信息准备就绪时传递您的信息。

【讨论】：

谢谢。在回答您的问题时，1）最旧的未确认消息肯定在稳步增加。 2) 你可以看到这些都是成功的确认，所以问题不是在截止日期之后尝试确认消息。关于 3）你是说如果我没有与其他订阅者发出拉取请求，那么之前确认的消息将不会被清除？
我应该补充一点，没有新消息发布到该主题，所以订阅者不可能根本跟不上。
回复：3，是的，如果你想清除积压，你需要继续拉订阅（通过这个或其他订阅工作）直到 num_undelivered_messages 为 0。
我不关注。我不能一次拉和确认一条消息？

【解决方案3】：

我建议延长消息的租约，这样它们的确认截止日期就不会过期（目前可能有一些确认截止日期已过期，导致消息被重新传递）。

确保您没有对消息进行 nacking，同时增加您发送的拉取请求的数量。最佳做法是在任何给定时间打开大量重叠拉取以获得更好的订阅者吞吐量。

【讨论】：