PubSub REST 订阅拉取未返回所有消息

Question

我们使用REST 服务 API从 PubSub 订阅中提取消息。准备好接受服务的消息被确认，而其他消息则在稍后的执行周期中未被确认而需要接受服务。

在执行周期中，我们使用和向服务 REST API发送单个请求。pullreturnImmediately=truemaxMessages=100

在测试时，我们遇到了这样的情况：每个执行周期仅返回 3 条“旧”消息。新发布的消息从未包含在 的请求中pull。我们通过监控 Stackdriver 监控中的未送达消息来验证新消息是否已成功到达订阅。

• REST API是否pull不包含所有未传递的消息？
• 它会忽略该maxMessages参数吗？
• 应如何使用 REST API 读取所有消息（最多指定的最大值）？

笔记：

pull我们通过向API 发送 2 个并行请求并合并结果来解决该问题。我们找到了此处讨论的解决方法（需要并行请求）。

2018 年 2 月 22 日更新

我在我们的博客上写了一篇文章，解释了为什么我们强制使用 PubSub 服务 REST API。

Answer 1

单个pull调用不一定会返回所有未传递的消息，尤其returnImmediately是当设置为 true 时。承诺pull最多返回maxMessages，并不意味着maxMessages如果有那么多可用消息，它总是会返回。

APIpull尝试在返回更多消息与保持较低的端到端延迟之间取得平衡。它宁愿快速返回几条消息，也不愿等待很长时间才返回更多消息。需要从存储或其他服务器检索消息，因此有时无法立即传递所有这些消息。随后的pull请求将接收稍后检索的其他消息。

如果您希望最大限度地提高通过请求接收更多消息的机会pull，请设置returnImmediately为 false。这仍然不能保证消息将在单个pull请求中全部传递，即使maxMessages大于尚未传递的消息数量。您仍然应该发送后续pull请求（或者更理想的是，pull同时发送多个请求）来检索所有消息。

或者，您应该考虑切换到Google Cloud Pub/Sub 客户端库，它会在后台处理所有这些操作，并在消息可用时立即将消息传递到您指定的回调。