Возможно ли дублирование сообщений pubsub обратно в pubsub с потоком данных?

Question

У меня есть приложение, записывающее данные в pubsub Google Cloud, и, согласно документации pubsub, дублирование из-за механизма повторных попыток может происходить время от времени.Существует также проблема неупорядоченных сообщений, которая также не гарантируется в pubsub.

Кроме того, для каждой документации можно использовать Google Cloud Dataflow для дедупликации этих сообщений.

Iхочу сделать эти сообщения доступными в очереди сообщений (имеется в виду облачный pubsub) для использования службами и облачным хранилищем данных. Поток данных, похоже, имеет средство записи pubsubio, однако разве вы не вернетесь к той же самой проблеме, когда запись в pubsub может создать дубликаты?Разве это не было бы той же самой проблемой с заказом?Как я могу передавать сообщения по порядку, используя pubsub (или любую другую систему в этом отношении)?

Можно ли использовать облачный поток данных для чтения из темы pubsub и записи в другой pubsub с гарантией отсутствия дубликатов?Если нет, то как еще вы могли бы сделать это с поддержкой потоковой передачи относительно небольшого объема данных?

Также я очень плохо знаком с Apache beam / Cloud Dataflow.Как бы выглядел такой простой вариант использования?Я полагаю, что могу дедуплицировать, используя идентификатор, сгенерированный самой pubsub, так как я позволяю библиотеке pubsub выполнять внутреннюю повторную попытку, а не делать это самостоятельно, поэтому идентификатор должен быть одинаковым при повторных попытках.

Answer 1

Облачный поток данных / Apache Beam - это грузовики Mac. Они предназначены для распараллеливания больших источников данных / потоков. Вы можете отправлять огромные объемы данных в PubSub, но обнаружение дубликатов не является задачей для Beam, поскольку эту задачу необходимо сериализовать.

Чтение PubSub и последующая запись в другую тему не устраняет проблему дубликатов, поскольку дубликаты могут возникать в новой теме, в которую вы пишете. Кроме того, распараллеливание записи в очереди еще больше увеличивает проблему с сообщениями о неисправности.

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

Обработка непоследовательных сообщений также должна быть предусмотрена в вашем приложении.

PubSub разработан как легкая недорогая система очереди сообщений. Если вам нужен гарантированный порядок сообщений, без дубликатов, FIFO и т. Д., Вам нужно использовать другое решение, которое, конечно, намного дороже.

Answer 2

Невозможно использовать облачный поток данных для чтения из темы паба / вложенной темы и записи в другую тему паба / вложенной темы, которая может гарантировать отсутствие дубликатов. Дубликаты могут возникать одним из двух способов:

1. Издатель публикует одно и то же сообщение дважды. С точки зрения службы Pub / Sub, это два отдельных сообщения, и оба будут доставлены. Это может произойти, если, например, издатель выполняет публикацию, и он завершается неудачно с DEADLINE_EXCEEDED, и издатель повторяет попытку. В этой ситуации возможно, что первая попытка публикации действительно удалась, но ответ не был доставлен издателю вовремя.

2. Служба Pub / Sub доставляет подписчику сообщение, и оно либо не подтверждает это сообщение, либо подтверждение теряется при передаче обратно в службу. У Pub / Sub есть хотя бы раз гарантии доставки. Одним из основных источников этого является тот факт, что подтверждение является наилучшим способом, а это означает, что даже если подписчик отправляет подтверждение, он может не вернуться обратно к услуге, например, если произойдет прерывание сети.

Учитывая эти два различных режима дубликатов, единственный способ дедупликации сообщений состоит в том, чтобы сделать это в конечном подписчике, получающем сообщения, либо через Поток данных, либо с помощью какого-либо другого механизма, например, записи идентификаторов, полученных в базе данных. Обратите внимание, что в любом случае может быть недостаточно использовать идентификаторы, сгенерированные службой Pub / Sub, поскольку повторные публикации возможны в случае повторных запросов после ошибки.