Есть ли способ соединить несколько запросов / триггеров формы SQS с однопоточными лямбда-функциями?

Question

Мое приложение использует лямбда-функцию (1) для импорта данных на третий сервер базы данных. Когда-нибудь (1) выдаст ошибки, и я использую SQS для хранения сообщений throw от (1). И я использую лямбда-функцию (2), чтобы прочитать все сообщения в SQS и повторно импортировать по отзыву (1). (2) срабатывает всякий раз, когда SQS получает сообщение.

Полный поток ошибок: лямбда (1) => SQS => лямбда (2) => лямбда (1).

Проблема в том, что если сервер БД поддерживается, он будет бесконечным циклом, пока сервер БД снова не станет активным.

Мое решение состоит в том, чтобы создать лямбда-функцию (3), которая работает как флаг, проверяет состояние сервера БД. Он запустится, когда SQS получит новое сообщение, будет выполняться несколько раз, пока сервер БД снова не станет активным. На этот раз называется лямбда (2).

И я хочу, чтобы эта лямбда (3) представляла собой один поток (singleton?), Все запросы от SQS находятся в одном потоке.

=> При таком решении система должна повторить попытку только одного потока, если сервер БД не работает.

Новый поток: Lambda (1) => SQS => Одиночный поток Lambda (3) => Lambda (2) => Lambda (1)

Мой вопрос:

1. Мое решение возможно или нет?
2. Если это возможно, то как настроить Lambda (3)?
3. Если это невозможно, то есть ли способ решить мою проблему? Пожалуйста, помогите, спасибо!

Answer 1

Это возможно при использовании запланированных событий throttling и CloudWatch.

Вы можете настроить запланированное событие CloudWatch для периодического запуска лямбда-функции 3 (которая отвечает за проверку состояния БД). Я не уверен, что вы подразумеваете под однопоточностью, но я предполагаю, что вы имеете в виду, что не более одного экземпляра этой функции будет выполняться одновременно. Это легко, потому что запланированное событие CloudWatch будет запускать эту функцию только один раз за x - количество времени , которое вы можете указать.

Как только указанная выше функция (3) обнаруживает, что БД является нездоровой, она может установить ограничение параллелизма для вашей лямбда-функции, которая читает сообщения из SQS (2) и уменьшает ее до 0, так что лямбда-функция (2) не может быть выполнена на все.

Когда функция (3) обнаруживает, что БД исправна, она удаляет этот предел параллелизма из функции (2).

Так что код лямбда-функции (3) может выглядеть примерно так

if db_is_not_healthy:
    lambda.put_function_concurrency(
        FunctionName=function_2,
        ReservedConcurrentExecutions=0
    )
else:
    lambda.delete_function_concurrency(
        FunctionName=function_2
    )

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

Например, вы можете начать пинговать БД только после того, как с ней возникнут некоторые ошибки. Как только лямбда-функция (1) получает ответ об ошибке, она может включить проверки работоспособности - лямбда (3), отменив ее, и как только лямбда (3) решит, что БД снова исправна, она может сам себя ограничить, чтобы эти проверки работоспособности выполнялись только когда есть проблемы с БД.

Это определенно не самое элегантное решение, но оно должно работать после некоторой настройки.