我试图确保如果没有发送确认/否,Cloud Pub / Sub将重新传递我的消息。即使我等待了10分钟以上,它似乎也没有执行此操作,这应该是“确认截止”的最长时间。
我以此处的示例为起点: https://cloud.google.com/pubsub/docs/quickstart-py-mac
本质上,我评论了确认消息的回调函数中的这一行。我使用了两个终端,一个用于发布消息,另一个用于作为订户接收消息。由于没有发送确认,我希望Cloud Pub / Sub尝试在确认期限内的某个时候将消息重新传递给订阅服务器,但事实并非如此。
此处的文档
https://godoc.org/cloud.google.com/go/pubsub#hdr-Deadlines
说“ ACK期限被客户端定期延长...最多10分钟”,所以我等了10分钟,以防ACK期限被延长到该最大值,但是我仍然没有收到重新发送的消息。
这是我使用的经过编辑的回调方法。这是我对示例代码所做的唯一更改。
def callback(message):
print('Received message {} of message ID {}'.format(
message, message.message_id))
# Acknowledge the message. Unack'ed messages will be redelivered.
# message.ack()
print('Acknowledged message of message ID {}\n'.format(
message.message_id))
如果我杀死订阅者(sub.py)并重新启动它,则该消息将重新发送。难道我做错了什么?另外,当我发送Nack而不是完全不发送任何内容时,该邮件会迅速重新发送。
编辑:
似乎有人问过类似的问题
https://github.com/googleapis/google-cloud-python/issues/5005
https://github.com/googleapis/google-cloud-python/issues/5044
我想确认的事情:
订阅中设置的“确认截止时间”并不总是使用的值。视需要发布/订阅而扩展。
最长10分钟的确认截止时间实际上不是重新发送邮件之前可以经过的最长时间
此最大时间由flow_control.max_lease_duration变量确定(默认为2小时)
答案 0 :(得分:0)
ackDeadline
是消息在没有确认,无确认或modAckDeadline
的情况下可以发送给订户的最长时间。一旦过了这个时间,邮件可能会成为要重新发送的候选者,尽管重新发送可能不是立即的。此字段的最大值为十分钟。
Cloud Pub / Sub客户端库在收到消息后会自动发送对消息的modAckDeadline请求,直到被确认,取消确认或经过flow_control.max_lease_duration
期为止。从本质上讲,它延长了ack截止日期。客户端库的目标是跟踪ack截止日期,并根据需要扩展消息本身,以便用户不必这样做。
这就是为什么您看到客户端库行为与订阅上配置的ackDeadline
之间存在差异的原因。使用客户端库时,应将max_lease_duration
设置为希望邮件对订阅者有效的最长时间。