Прочитайте очередь SQS от AWS Lambda

У меня есть следующая инфраструктура:

У меня есть экземпляр EC2 с процессом NodeJS + Express, прослушивающим порт для сообщений (процесс 1). Каждый раз, когда процесс получает сообщение, он отправляет его в очередь SQS. Затем у меня есть другой процесс на той же машине, читающей очередь, используя длительный опрос (процесс 2). Когда он находит сообщение в очереди, он вставляет данные в базу данных MariaDB, сидящую на экземпляре RDS.

(Чтобы уточнить, сообщения генерируются пользователями, они отправляют кусок данных, который может содержать произвольную информацию в конечной точке, где прослушивается процесс 1)

Теперь я хочу поместить процесс, который читает SQS (процесс 2) в функции Lambda, так что процесс, который записывает в очередь и тот, который читает из очереди, полностью независим. Проблема в том, что я не знаю, возможно ли это.

Я знаю, что функция Lambda вызывается в ответ на событие, а событиями, поддерживаемыми на данный момент, являются S3, SNS, SES, DynamoDB, Kinesis, Cognito, CloudWatch и Cloudformation, но НЕ SQS.

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

Сейчас я немного застрял, потому что не знаю, как продолжить. У меня такое ощущение, что создать эту инфраструктуру невозможно из-за существующих ограничений в услугах AWS. Есть ли другой способ сделать то, что я хочу, или я в тупике?

Просто, чтобы расширить мой вопрос с помощью некоторых исследований, которые я сделал, это github repo показывает, как читать Query QQS из функции лямбда , но функция лямбда работает только в том случае, если она запущена из командной строки

https://github.com/robinjmurphy/sqs-to-lambda

В readme автор упоминает следующее:

Обновление: теперь Lambda поддерживает уведомления SNS в качестве источника событий, что делает этот хак совершенно ненужным для SNS notifcations. Вы может по-прежнему считаться полезным, если вам нравится идея использования лямбда для обработки заданий в очереди SQS.

Но я думаю, что это не решает мою проблему, уведомление SNS может вызывать функцию Lambda, но я не вижу, как я могу создать уведомление, когда сообщение получено в очереди SQS.

Спасибо

Ответ 1

Существует несколько стратегий, которые можно использовать для соединения точек, (A) синхронно или Run-Sleep-Run, чтобы поддерживать поток данных между SNS, SQS, Lambda.

Стратегия 1: используйте функцию Lambda для SNS и обрабатывайте ее в режиме реального времени [обратите внимание, что очередь SQS может подписаться на тему SNS, которая могла бы быть полезными для регистрации/аудита/повторной обработки]

Стратегия 2. Учитывая, что вы получаете данные, полученные в очередь SQS. Вы можете попробовать с помощью двух лямбда-функций [Feeder and Worker].

Feeder будет scheduled lambda function, чья задача - взять элементы из SQS (если есть) и нажмите его как тему SNS (и продолжайте делать это навсегда)

Рабочий будет связан с прослушиванием темы SNS, которая будет выполнять actual data processing

Ответ 2

У меня была аналогичная ситуация (и теперь у меня есть рабочее решение). Я обратился к нему следующим образом:

введите описание изображения здесь

то есть. публикация событий в SNS; которые затем разворачиваются в Lambda и SQS.

ПРИМЕЧАНИЕ. Это не относится к событиям, которые необходимо обработать в определенном порядке.

Что есть некоторые getchas (w/возможные решения), такие как:

  • Состояние гонок: lambda может быть вызвано до того, как сообщения будут помещены в очередь
  • распределенный характер очереди SQS может привести к возврату сообщений, даже если есть сообщение note1.

Решение обоих случаев заключалось бы в длительном опросе очереди SQS; но это делает ваш лямбда-счет более дорогим.

Note1

Короткий опрос - это поведение по умолчанию, когда взвешенный случайный набор машин отбирается на вызов ReceiveMessage. Это означает, что возвращаются только сообщения на дискретизированных машинах. Если количество сообщений в очереди невелико (менее 1000), вероятно, вы получите меньше сообщений, чем вы запросили на звонок ReceiveMessage. Если количество сообщений в очереди крайне невелико, вы не можете получать сообщения в определенном ответе ReceiveMessage; в этом случае вам следует повторить запрос. http://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html

Ответ 3

У нас были некоторые подобные требования, поэтому мы закончили создание библиотеки и открыли ее, чтобы помочь с SQS для асинхронного Lambda. Я не уверен, что это заполняет ваш конкретный набор требований, но подумал, что это может стоить взгляда: https://read.iopipe.com/sqs-lambda-teaming-up-92c4096be49c