pubsub 流式处理 pull nack 与无确认行为

Posted 2023-03-24

【中文标题】pubsub 流式处理 pull nack 与无确认行为

【英文标题】：pubsub streaming pull nack vs no acknowledge behaviour

【发布时间】：2019-12-01 17:33:45

【问题描述】：

nack() 有以下行为

nack() """拒绝确认给定的消息。 这将导致消息被重新传递给订阅。

现在在流式拉取中，我正在拉取taxiride streaming data 测试以下行为。

用 nack() 流式拉取继续接收之前被 nacked() 的消息

nack() 或 ack() 都不是 流式传输会读取最初的一堆消息并等待很长时间。我等了将近 15 分钟，但它没有拉出任何新消息。

现在我的问题是，在消息既不是 ack() 也不是 nack() 的流式拉取中，处理这些消息的预期行为和正确方法是什么？ 假设我想将每分钟积压的消息数作为处理要求吗？

【参考方案1】：

当消息既未确认也未确认时，Cloud Pub/Sub 客户端库会维护消息的租约，直至 maxAckExtensionPeriod。一旦该时间段过去，消息将被nack并重新传递。当您既不确认也不确认时，您没有收到更多消息的原因可能是因为您遇到了flowControlSettings 中指定的值，这限制了可能未完成且尚未确认或确认的消息的数量。

一般来说，既不确认也不确认消息是一种反模式。如果你成功处理了消息，你应该确认它。如果您无法处理它（例如发生某种类型的瞬态异常），那么您应该对其进行处理。尝试在不执行这些操作之一的情况下接收消息并不是计算积压中消息数量的有效方法。

【讨论】：

感谢 Kamal Aboul-Hosn 的解释。