Несколько лямбд, нанизанных на SQS, не попадают в пункты назначения - PullRequest
0 голосов
/ 11 февраля 2020

У нас есть ряд лямбда-функций, связанных с рядом очередей SQS. В основном это выглядит примерно так:

Lambda(foo) => Queue(Alpha) => Lambda(bar) => Queue(Beta) => Lambda(baz)

В этом случае Очередь (Альфа) является Пунктом назначения Lambda (foo) и источником событий для Lambda (bar).

Мы ожидаем, что Lambda (foo) успешно выполнится, затем передадим сообщение в Queue (Alpha), которое запускает Lambda (bar). Затем, если Lambda (bar) завершается успешно, он передает сообщение в Queue (Beta), которое запускает Lambda (baz).

В действительности, вызов Lambda (foo) отправит сообщение в Queue (Alpha) , который стреляет лямбда (бар); но затем обработка останавливается. Мы проверили логи, и все прошло успешно, но в очередь (бета-версия) не отправлено никаких сообщений. Чтобы исключить проблемы с разрешениями, мы вызвали Lambda (bar) напрямую, который отправляет сообщение в Queue (beta) и вызывает Lambda (baz), как мы надеемся.

Все целевые соединения настроены как асинхронные c. Тестовый вызов, который мы выполняли, выполняется следующим образом (например, при названии, поэтому можно игнорировать детали):

aws2 lambda invoke --function-name Queue(foo) --invocation-type Event --payload '{ \"input\": \"jphenow\" }' response.json

У кого-нибудь есть идеи, чего нам здесь не хватает? На момент установки все это асин c nodejs функций, которые выполняют context.callbackWaitsForEmptyEventLoop = false;, но скоро они будут представлять собой смесь различных языков.

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

Буду признателен за любую помощь или подсказки!

-

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

1 Ответ

2 голосов
/ 11 февраля 2020

Ваши и @ JasonWadsworth выводы абсолютно верны. Это довольно просто на самом деле.

  • Лямбда-функции, «запускаемые» событием сообщения SQS, вызываются синхронно , согласно документации :

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

  • Пункты назначения работают только тогда, когда лямбда-функция вызывается асинхронно , как указано в ваша ссылка :

... AWS Lambda Назначения для асинхронных вызовов.

( Хотя ни в коем случае не говорится, что синхронные вызовы не поддерживаются, быстрый Google проверит это из других источников.)

  • Вы вызвали свою функцию из CLI асинхронно .

--invocation-type Event

Согласно документации :

Чтобы вызвать функцию асинхронно, установите InvocationType в Событие.

Поэтому произошло следующее:

  1. Lambda(foo) был вызван асинхронно. Поскольку вызов был асинхронным,
  2. Результат функции был записан в Queue(Alpha). Поскольку вы установили Lambda(bar) как лямбда-триггер в этой очереди, и поскольку Lambda вызывает функции синхронно на основе сообщений SQS,
  3. Lambda(bar) был вызван синхронно. Поскольку он был вызван синхронно,
  4. Queue(Beta) не был записан, и конвейер остановился там.

У нас очень похожий конвейер с лямбда-функциями и очередями, единственное отличие наши функции пишут в следующую очередь в конвейере, используя SQS sdk. Не уверен, что это лучший способ, но это, безусловно, один из способов сделать это.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...