Использование Single SQS для нескольких подписчиков на основе идентификатора сообщения - PullRequest
0 голосов
/ 12 января 2019

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

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

Есть ли способ, которым я могу использовать одну SQS, из которой все подписчики могут использовать сообщения, основанные на идентификаторе сообщения. Проблемы должны быть покрыты в этом дизайне:

  1. Каждый подписчик может получить свое сообщение на основе идентификатора
  2. Задержки не должно быть, если один издатель публикует очень мало сообщений, а другой публикует его миллионами.
  3. У нас может быть один SQS для каждого издателя, но один SQS для всех подписчиков этого издателя.

Может ли кто-нибудь предложить любую архитектуру, использующую аналогичную реализацию.

Спасибо

1 Ответ

0 голосов
/ 15 января 2019

Я думаю, что вы можете достичь этого, настроив одну очередь SQS. Вы бы хотели настроить лямбда-триггер в этой очереди, который будет служить диспетчером служб (SM). SM будет иметь статический JSON-файл, который определяет соответствие между идентификатором сообщения и его subscriber/worker. SM получит событие сообщения SQS, найдет атрибут сообщения, используемый для идентификатора, а затем заглянет в JSON, чтобы найти соответствующего подписчика. Если подписчик найден, SM вызовет его.

Рассмотрите возможность использования пакетного триггера SQS.

enter image description here

...