Асинхронный или синхронный режим для подсчета потоковых данных в pub sub pub / sub?

Question

Я хотел бы посчитать количество сообщений за последний час (последний час относится к полю отметки времени в данных сообщения ).

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

Мой код будет повторно запрашиватьподписка на заранее определенное (я установил ее более 100) количество раз, так что я уверен, что за последний час больше не будет сообщений, выходящих из строя.
Это неприемлемый дизайн, потому что это означает, чтопользователь должен ждать 5-10 минут, чтобы служба посчитала сообщения, когда им нужна метрика!

Существуют ли рекомендации в Pub Sub , предназначенные для решения такого рода проблем?
Кажется, что это простая задача (подсчитать количество событий за последний X период)поэтому я подумал, что может быть.

Поможет ли асинхронный дизайн? Как будет работать асинхронный дизайн? Я не слишком уверен в концепции асинхронности и Python future (я использую клиентскую библиотеку Python GCP Pub / Sub).

Answer 1

Я постараюсь поймать сообщение иначе. Мое решение основано на ведении журнала и BigQuery. Идея состоит в том, чтобы написать журнал, например message received with timestamp xxxxx, чтобы отфильтровать этот шаблон журнала и сохранить результат в BigQuery.

Затем, когда пользователь спрашивает, вам просто нужно запросить BigQuery и посчитать сообщение за нужный промежуток времени. У вас также есть преимущество, чтобы изменить временные рамки, чтобы иметь историю, ...

Для записи этого журнала, 2 решения

• Дешевле, но недействительно рекомендуется, процесс, который потребляет сообщение, регистрирует его вместе с ним. Однако вы зависите от внешней службы. И у этого сервиса есть 2 обязанности: его работа, и этот журнал (для метрик). НЕ ТВЕРДЫЙ. Может быть, это может быть роль издателя с балконом, подобным этому: message published at XXXX. Однако это подразумевает, что все издатели или все подписчики находятся в GCP.
• Лучше подключить функцию, дешевле (128 МБ памяти) просто обработать сообщение и записать журнал.