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

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

在执行周期中，我们发送一个single请求给pull服务 REST API with returnImmediately=true and maxMessages=100.

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

• 是否pullREST API 不包括所有未发送的消息？
• 它是否忽略了maxMessages范围？
• 应如何使用 REST API 读取所有消息（最多指定的最大值）？

Notes:

我们通过向 2 个并行请求发送来解决这个问题pullAPI 并合并结果。我们找到了讨论的解决方法（需要并行请求）here.

2018 年 2 月 22 日更新

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

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

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

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

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