Блог

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

Проект основан на платформе на основе drop-wizard.

Опции:

1. Lambda — Исключил эту опцию, поскольку огромная загрузка сообщений в sqs приводит к большему количеству сбоев (в конечном итоге в dlq) в случае lambda. Также мне нужно выполнить более одной операции с данными, где lambda подходит только для одной операции с ним.
2. AWS SQS SDK — необходимо записать логику потока для этого (для опроса и обработки сообщений)
3. AWS предоставила sqs sdk на основе jms (amazon-sqs-java-messaging-lib) — похоже, он идеально подходит для моего варианта использования. Поскольку он будет обрабатывать логику опроса и параллелизма. Но проблема в том, что последняя версия для этого jar была выпущена в апреле 2019 года. Прошло почти 2 года, до сих пор нет обновлений для этой библиотеки. Также остается много открытых вопросов без ответа.

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

Может кто-нибудь, пожалуйста, просветить меня, могу ли я использовать эту библиотеку или лучше просто придерживаться ванильного aws sqs sdk? Если есть какие-либо другие варианты, пожалуйста, укажите это также.

———————————————————ОБНОВЛЕНИЕ————————————————————- Спасибо за предложение использовать lambda или step, увеличив количество одновременных ограничений, чтобы справиться с большой нагрузкой в 1000 tps. Я также провел еще некоторый анализ варианта использования моего проекта и решил перейти к контейнерному приложению, используя простой ванильный AWS SQS sdk для взаимодействия с SQS.

Причины этого решения:

SQS -> My_APP -> Другое приложение

1. Как вы можете видеть поток, из My_APP мне нужно взаимодействовать с другим приложением, которое может поддерживать определенные tps. Если у меня есть контроль над логикой опроса, я могу решить эту проблему.
2. Также My_APP — это не простой процесс. здесь будет происходить более 1 процесса. (Преобразование, некоторое сопоставление, …)
3. Причина, по которой я опубликовал этот вопрос, — получить некоторые обновления библиотеки amazon-sqs-java-messaging-lib. В итоге я не пошел по этому пути, поскольку не уверен в поддержке aws этой библиотеки в будущем.

Я не понимаю, «лямбда оптимален для решения только одной операции». Что заставляет вас так говорить? Единственным ограничением является время, необходимое для выполнения серии операций. Если вы постоянно получаете тайм-ауты при выполнении нескольких операций, вы можете использовать пошаговые функции. См. https://docs.aws.amazon.com/step-functions/latest/dg/connect-lambda.html .