Как Google Cloud Pub / Sub избегает перекоса часов

Question

Я изучаю способы заказа списка сообщений из облачного паба / подписки Google. В документации написано:

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

... возможно с помощью Cloud Monitoring для отслеживания метрики pubsub.googleapis.com/subscription/oldest_unacked_message_age. Подписчик временно помещает все сообщения в какое-то постоянное хранилище и проверяет сообщения. Он будет периодически проверять возраст самого старого неопознанного сообщения и сверяться с отметками времени публикации сообщений в хранилище. Все сообщения, опубликованные до самого старого неупакованного сообщения, гарантированно будут получены, поэтому эти сообщения могут быть удалены из постоянного хранилища и обработаны по порядку.

Я проверил это локально, и этот подход работает нормально.

У меня есть одно замечание, и я не могу легко это проверить.

В этом решении используется атрибут, присвоенный серверной стороне (от Google) publish_time. Как Google избегает проблем с перекосом часов?

Если мой продюсер публикует сообщения A, а затем сразу B, как я могу быть уверен, что A.publish_time < B.publish_time верно? Особенно с учетом того, что на той же странице документации упоминаются внутренние балансировщики нагрузки в архитектуре решения. Использует ли Google Pub / Sub атомные часы для синхронизации времени на самых первых компьютерах, которые видят сообщения и обогащают эти сообщения текущим временем?

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

Уведомление. Меня интересует только относительный порядок подтвержденных сообщений, публикуемых после друг друга. Если два сообщения публикуются одновременно, меня не волнует их порядок между собой. Это может быть A, B или B, A. Я только хочу убедиться, что если B публикуется после публикации A, то я могу отсортировать их в этом порядке при извлечении.

Является ли вышеупомянутое решение только «лучшим из возможных» или существуют реальные гарантии в отношении такого поведения?

Answer 1

Заказанная доставка сообщений имеет две стороны: установление порядка сообщений на стороне публикации и наличие установленного порядка обработки сообщений на стороне подписки. Документ, на который вы ссылаетесь, в основном касается последнего, особенно когда речь идет об использовании oldest_unacked_message_age. При использовании этого метода можно знать, что если сообщение A имеет метку времени публикации, которая меньше, чем метка времени публикации для сообщения B, то подписчик всегда будет обрабатывать сообщение A перед обработкой сообщения B. По существу, после установления порядка (посредством публикации метки времени), это будет согласованно. Это работает, если для самой службы Cloud Pub / Sub все в порядке, чтобы установить порядок сообщений.

Отметки времени публикации не синхронизируются между серверами, и поэтому, если издателям необходимо установить порядок, издателям необходимо будет указать отметку времени (или порядковый номер) в качестве атрибута, используемого для упорядочения. в подписчике (и синхронизируется между издателями). Подписчик будет сортировать сообщения по этой предоставленной пользователем метке времени, а не по метке времени публикации. oldest_unacked_message_age больше не будет точным, поскольку оно связано с отметкой времени публикации. Можно было бы быть более консервативным и рассматривать только упорядоченные сообщения, которые старше oldest_unacked_message_age минус некоторая дельта, чтобы учесть это несоответствие.

Answer 2

Google Cloud Pub-sub не гарантирует порядок получения событий для потребителей в том виде, как они были созданы.Причиной этого является Google Cloud Pub-sub, также работающий на кластере узлов.Существует вероятность того, что событие B может дойти до потребителя до события A. Для обеспечения порядка необходимо внести изменения как для производителя, так и для потребителя, чтобы определить порядок событий. Здесь - раздел из документов.