SQS Lambda - повторить логику? - PullRequest
Новая
       15

SQS Lambda - повторить логику?

0 голосов
/ 30 сентября 2018

Когда сообщение добавлено в очередь SQS и настроено для запуска лямбда-функции (nodejs).

Когда запускается лямбда-функция - я могу повторить попытку через 5 минут, не удаляя сообщение из очереди.Причина, по которой я хочу сделать это, если Lambda не может подключиться к внешнему хосту (например, API) - я хотел бы повторить попытку через 5 минут только для 3 попыток.

Как это можно записать в узле js?

Например, в Laravel мы можем использовать Specifying Max Job Attempts функциональность.Количество попыток выполнения задания с использованием public $tries = 5;

Источник: https://laravel.com/docs/5.7/queues#max-job-attempts-and-timeout

Как мы можем сделать подобный способ в node.js?

Я думаюдобавление сообщения в другую очередь (для повтора).Лямбда-функция читает все сообщения из этой очереди через 5 минут и отправляет это сообщение обратно в основную очередь, и она будет запускать лямбда-функцию.

Ответы [ 4 ]

0 голосов
/ 27 марта 2019

Повторные попытки и повторные попытки «тайм-аут» могут быть настроены непосредственно в очереди SQS.

При создании очереди установите следующие атрибуты:

SQS Queue Attributes

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

Если вы хотите попробовать только 3 раза, вы должны установить политику перезапуска SQS (очередь недоставленных сообщений AKA)

Dead Letter Queue Settings

Политика перезапускапозволит вашей очереди перенаправлять сообщения в очередь недоставленных сообщений (DLQ) после повторного появления сообщения в очереди N количество раз, где N - это число от 1 до 1000.

Важно понимать, что лямбда будет продолжать обрабатывать сообщение об ошибке (сообщение, которое генерирует исключение в коде) до тех пор, пока:

  1. не будет обработано без ошибок (лямбда удалит сообщение)
  2. Срок действия Message Retention Period истекает (SQS удаляет сообщение)
  3. Он отправляется на DLQ, установленный в политике перезапуска очереди SQS (SQS "перемещает" сообщение в DLQ)
  4. Вы удаляете сообщение изочередь в вашем коде (пользователь удаляет сообщение)

В противном случае Lambda не избавится от этого плохого сообщения.

Важные замечания

Lambda не будетиметь дело с ошибочными сообщениями

Основываясь на нескольких экспериментах, которые я провел, чтобы понять поведение интеграции SQS (документация при повторных попытках является неоднозначной ATM), lambda не будет удалять ошибочные сообщения и будетпродолжайте пробовать их снова.Даже если у вас настроен Lambda DLQ, сообщения не будут отправляться в DLQ, он полностью полагается на конфигурацию очереди SQS для этой цели, как указано в документации lambda DLQ .

Рекомендация:

  • Всегда используйте политику повторного вождения в своей очереди SQS.

Исключения приводят к сбою целого пакета сообщений

Как я уже говорил ранее, если во время обработки сообщения в вашем коде есть исключение, вся партия сообщений повторяется, не имеет значения, были ли некоторые сообщения обработаны правильно.Если по какой-либо причине произошел сбой в нисходящем сервисе, вы можете в конечном итоге увидеть сообщения, которые были обработаны в DLQ.

Рекомендация:

  • Вручную удалите сообщения, которые былиобработано правильно
  • Убедитесь, что ваша лямбда-функция может обрабатывать одно и то же сообщение более одного раза

Ограничения лямбда-параллелизма и SQS побочные эффекты

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

Рекомендация:

Сообщение и рекомендации Amazon:

  • Установите видимость очередитайм-аут, по крайней мере, в 6 раз превышающий тайм-аут, настроенный для вашей функции.
  • Дополнительное время позволяет Lambda повторить попытку, если выполнение вашей функцииОтрегулировано, пока ваша функция обрабатывает предыдущий пакет.
  • Установите для maxReceiveCount в политике перенаправления очереди значение не менее 5. Это поможет избежать отправки сообщений в очередь недоставленных сообщений из-за регулирования.
  • Сконфигурируйте недоставленное письмо так, чтобы сохранять сообщения о сбоях достаточно долго, чтобы вы могли переместить их позже для последующей обработки
0 голосов
/ 01 октября 2018

Вот как я это сделал.

  1. Создание обычных очередей (немедленная доставка), Q1
  2. Создание очередей с задержкой (задержка 5 минут), Q2
  3. Создать DLQ (после повторных попыток), DLQ1

(Q1 / Q2) SQS Trigger -> Lambda L1 (в случае неудачи удалить на (Q1 / Q2), сбросить на Q2) --> On Failure DLQ

Когда сообщения приходят в Q1, он запускает Lambda L1, если успех идет оттуда.Если не удается, сбросьте его на Q2 (который является отложенной очередью).Каждое сообщение, поступающее в Q2, будет иметь задержку в 5 минут.

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

Если у вас возникнет ошибка кода при обработке инфраструктуры Q1 / Q2, то aws немедленно повторится три раза, прежде чем это произойдет.отправляет его на DLQ1.Если вы исправите ошибку в коде, вы сможете настроить конвейер для работы с указанными вами временами.

Очереди задержки SQS:

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-delay-queues.html

SQS Lambda Architecture:

https://nordcloud.com/amazon-sqs-as-a-lambda-event-source/

enter image description here Надеюсь, это поможет.

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

Согласно этому блогу:

https://www.lucidchart.com/blog/cloud/5-reasons-why-sqs-lambda-triggers-are-a-big-deal

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

0 голосов
/ 30 сентября 2018

Довольно просто и без необходимости делать какое-либо кодирование.Прежде всего: если ваш код выдаст ошибку, AWS Lambda попытается еще 3 раза выполнить ваш код.В этом случае, если внешний API не был доступен, происходит большое изменение, которое в третий раз повторяет попытку AWS - API будет работать.Кроме того, задержка между повторными попытками означает случайную задержку, между попытками существует задержка.

Если произойдет худшее, а внешний API еще не задействован, вы можете воспользоватьсяфункция очереди недоставленных сообщений (DLQ), которая есть у каждой лямбды.Это приведет к тому, что в SQS появится сообщение о том, что пошло не так, чтобы вы могли предпринять дополнительные действия.В этом случае продолжайте повторную попытку, пока не сделаете это.

Вы можете прочитать больше здесь: https://docs.aws.amazon.com/lambda/latest/dg/dlq.html

...