Абонент никогда не получает всю очередь

Question

мы работаем с PubSub для интеграции нескольких систем друг с другом. Некоторые системы могут передавать данные в PubSub как JSON, в то время как другие могут извлекать эти данные и использовать их. (Примечание: мы вынуждены тянуть из PubSub вместо отправки в приложение из-за других ограничений, связанных с принимающим приложением). Каждое извлекающее приложение получает своего подписчика на каждую тему.

Я заметил, что приложение PubSub не получает все данные, находящиеся в очереди, если они запускаются слишком часто. Изначально проблема возникла в приложении Java Spring с соответствующей библиотекой, но команда gcloud в облачной консоли демонстрирует то же поведение, поэтому я просто собираюсь использовать этот пример. Я удалил ack-идентификаторы и границы, чтобы подогнать его под это окно Обратите внимание, что я не использую флаг '--auto-ack', поэтому очередь должна оставаться прежней, никакая другая система не получает от этого подписчика.

Первое нажатие (полное содержание): max_binnewies @ cloudshell: ~ $ gcloud pubsub подписки pull testSubscriber --limit = 100

│    DATA   │    MESSAGE_ID   │ 
│ 4 - FOUR  │ 189640873208084 │
│ 5 - FIVE  │ 189636274179799 │ 
│ 2 - TWO   │ 189638666587304 │ 
│ 3 - THREE │ 189627470480903 │  
│ 1 - ONE   │ 189639207684195 │

Второе нажатие (только одно): max_binnewies @ cloudshell: ~ $ gcloud pubsub подписки pull testSubscriber --limit = 100

│   DATA  │    MESSAGE_ID   │
│ 1 - ONE │ 189639207684195 │

Третье натяжение (два разных): max_binnewies @ cloudshell: ~ $ gcloud pubsub подписки pull testSubscriber --limit = 100

│   DATA   │    MESSAGE_ID   │ 
│ 4 - FOUR │ 189640873208084 │ 
│ 5 - FIVE │ 189636274179799 │

Четвертый пул (снова первый): max_binnewies @ cloudshell: ~ $ gcloud pubsub подписки pull testSubscriber --limit = 100

│   DATA  │    MESSAGE_ID   │
│ 1 - ONE │ 189639207684195 │

Такое поведение смущает меня. Это нормальное поведение PubSub или я делаю что-то не так? Единственное, что я нашел, это ссылка, в которой говорится, что PubSub использует балансировку нагрузки для метода pull: https://cloud.google.com/pubsub/docs/subscriber Поэтому я думаю, что подписчик считает, что на него подписываются несколько клиентов, и распространяет данные, если звонки приходят слишком быстро. Это верно? Что именно здесь происходит? Если я немного подожду, я снова получу больше данных, но я, кажется, никогда не получу все, даже если я жду пять минут ... Это очень сбивает с толку. Может ли это вызвать проблемы для потребляющего приложения? Как мне убедиться, что все данные поступают в принимающее приложение, даже если оно очень часто загружается? Есть ли способ отключить это?

Answer 1

Есть несколько вещей, в результате которых вы не получаете все сообщения каждый раз:

1. При использовании запросов на извлечение не гарантируется, что все сообщения будут возвращены в конкретном запросе, даже если доступно меньше сообщений, чем максимальное количество сообщений. Это потому, что Pub / Sub пытается сбалансировать возвращение большего количества сообщений с минимизацией сквозной задержки.

2. У сообщений есть крайний срок подтверждения, который указывается во время создания подписки (по умолчанию 10 секунд). Это означает, что когда вы извлекаете сообщения и не проверяете или не собираете их, они не будут доставляться в течение срока истечения срока подтверждения, в основном предоставляя процессу, который извлекал сообщения, их аренду. Если вы хотите, чтобы сообщения доставлялись немедленно, вам необходимо nack их, если вы используете клиентская библиотека Java (предпочтительный способ взаимодействия с Cloud Pub / Sub) или вам нужно отправить запрос ModifyAckDeadline с ack_deadline_seconds, установленным в 0.