PubSub: горизонтально масштабируемые абонентские пересылки

Question

Из документации по https://cloud.google.com/pubsub/architecture#basic_architecture мы понимаем, как pubsub может передавать сообщения между серверами пересылки издателей и абонентами, а изображение в расположении https://cloud.google.com/pubsub/images/wp_msg_lifecycle.svg визуализирует эту информацию.

Из всей предоставленной информации я могу понять, что в любой данный момент времени неподтвержденные сообщения в нескольких общедоступных источниках сообщений sh могут быть использованы сервером пересылки и общим количеством опубликованных сообщений sh. источники зависят от серверов пересылки.

В сценарии, где предполагается, что данные потребляются в режиме реального времени, как pubsub масштабирует серверы пересылки, чтобы избежать отставания. Поскольку каждый сервер пересылки издателя в любой данный момент времени может подключиться к одному серверу пересылки, а поскольку масштабирование сервера пересылки издателя и пересылки подписчика является независимым / разъединенным, это может увеличить отставание в системе, поскольку предполагается, что сервер пересылки подписчика передает несколько сообщений абонентов.

Answer 1

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

1. Иметь достаточную пропускную способность абонента для обработки с пропускной способностью.
2. Быстро подтверждать сообщения, порядка миллисекунд или секунд.
3. Избегайте взлома сообщений, особенно для подписок pu sh, где взломы вызывают откат в скорости доставки сообщений.