Использование ASA Amazon с несколькими потребителями

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

Служба регистрации:
- Выдает событие "registration-new", когда регистрируется новый пользователь.
Служба пользователя.
- При обновлении пользователя обновляется событие "обновлено пользователем".
Служба поиска:
- Считывает из очереди 'registration-new' и индексирует пользователя в поиске.
- Считывает из очереди "обновляемый пользователем" и обновляет пользователя в поиске.
Сервис показателей.
- Считывается из очереди 'registration-new' и отправляется в Mixpanel.
- Считывается из очереди "обновляется пользователем" и отправляется в Mixpanel.

У меня возникает ряд проблем:

При проведении опроса сообщение может быть получено несколько раз. Я могу создать много систем, чтобы быть идемпотентными, но для некоторых сервисов (таких как служба показателей) было бы намного сложнее.
Сообщение должно быть удалено вручную из очереди в SQS. Я думал о внедрении "службы обработки сообщений", которая обрабатывает удаление сообщений, когда все службы получили их (каждая служба будет выдавать сообщение "подтвержденное сообщением" после обработки сообщения).

Я предполагаю, что мой вопрос таков: какие шаблоны я должен использовать, чтобы гарантировать, что у меня может быть несколько потребителей для одной очереди в SQS, гарантируя, что сообщения также будут надежно доставлены и удалены. Благодарим вас за помощь.

Ответ 1

Я думаю, что вы делаете это неправильно.

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

Вместо того, чтобы помещать событие в очередь "регистрация-новый" , а затем иметь две разные службы, опрошенные в этой очереди, и BOTH нужно читать это сообщение и делать с ним что-то другое (а затем нужен третий процесс, который предполагается для удаления этого сообщения после того, как другие 2 обработали его).

Одна очередь должна использоваться для одной цели.

Создайте очередь "индекс-пользовательский поиск" и очередь "отправить в микспанели", поэтому служба поиска считывает из поисковых очередей, индексирует пользователя и немедленно удаляет сообщение.
Служба mixpanel читает из очереди микширования, обрабатывает сообщение и удаляет сообщение.

Служба регистрации вместо того, чтобы выпустить "registration-new" в одну очередь, теперь отправляет ее в две очереди.

Чтобы сделать это на один шаг лучше, добавьте SNS в микс здесь, и служба регистрации выдает сообщение SNS в тему "регистрация-новый" (не очередь), а затем подписаться на обе очереди, упомянутые выше, на эта тема в шаблоне "разветвления".

https://aws.amazon.com/blogs/aws/queues-and-notifications-now-best-friends/

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

Ответ 2

Я хотел бы добавить то, что я прочитал в этом сообщении в блоге.

Когда исходное сопоставление источника событий SQS изначально создано и включено или когда сообщения впервые появляются после периода без трафика, служба Lambda начнет опрос очереди SQS, используя пять параллельных соединений с длинным опросом. Служба Lambda отслеживает количество сообщений в полете, и когда она обнаруживает, что это число имеет тенденцию к увеличению, она увеличивает частоту опроса на 20 запросов ReceiveMessage в минуту и параллелизм функции на 60 вызовов в минуту.

Если AWS Lambda может выполнять параллельную обработку SQS, то почему не могут домашние приложения?

Источник: https://aws.amazon.com/blogs/aws/aws-lambda-adds-amazon-simple-queue-service-to-supported-event-sources/