Пул REST PubSub не возвращается со всеми сообщениями

Question

Мы используем API сервиса REST для извлечения сообщений из подписки PubSub. Сообщения, готовые к обслуживанию, подтверждаются, оставляя другие сообщения неподтвержденными для обслуживания в течение более позднего цикла выполнения.

Во время цикла выполнения мы отправляем один запрос pull API REST службы с returnImmediately=true а также maxMessages=100,

Во время тестирования мы столкнулись с ситуацией, когда только 3 "старых" сообщения будут возвращаться в течение каждого цикла выполнения. Недавно опубликованные сообщения никогда не включались в запрос pull, Мы убедились, что новые сообщения успешно поступают в подписку, отслеживая недоставленные сообщения в мониторинге Stackdriver.

• Ли pull REST API не включает все недоставленные сообщения?
• Это игнорирует maxMessages параметр?
• Как все сообщения, вплоть до указанного максимума, должны читаться с помощью REST API?

Заметки:

Мы решили эту проблему, отправив 2 параллельных запроса pull API и слияние результатов. Мы нашли обходной путь (требующий параллельных запросов), обсуждаемый здесь.

Обновление 22 февраля 2018

Я написал статью в нашем блоге, в которой объясняется, почему мы вынуждены использовать REST API службы PubSub.

Answer 1

Один pull Вызов не обязательно вернет все недоставленные сообщения, особенно когда returnImmediately установлен в true. pull обещает вернуться максимум maxMessages, это не значит, что он всегда вернется maxMessages если есть так много доступных сообщений.

pull API пытается сбалансировать возвращение большего количества сообщений с сохранением сквозной задержки на низком уровне. Скорее, он вернет несколько сообщений быстрее, чем долго будет ждать, чтобы вернуть больше сообщений. Сообщения необходимо извлекать из хранилища или с других серверов, поэтому иногда все эти сообщения не сразу доступны для доставки. Последующий pull Затем запрос будет получать другие сообщения, которые были получены позже.

Если вы хотите максимально увеличить вероятность получения большего количества сообщений с pull запрос, установить returnImmediately ложно. Это все еще не гарантирует, что все сообщения будут доставлены в одном pull запрос, даже если maxMessages больше, чем количество сообщений, которые еще предстоит доставить. Вы все еще должны отправить последующий pull запросы (или, что еще лучше, несколько pull запросы одновременно), чтобы получить все сообщения.

В качестве альтернативы вам следует рассмотреть возможность перехода к клиентским библиотекам Google Cloud Pub/Sub, которые обрабатывают все это внутри системы и доставляют сообщения на указанный вами обратный вызов, как только они становятся доступными.