Блог

Я разрабатываю серверную часть для веб-сайта, который использует API Gateway и Lambda для обработки запросов API, многие из которых нацелены на базу данных MySQL на RDS. Некоторые процессы должны выполняться асинхронно, но я обсуждаю, что является лучшей практикой или более чистым.

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

Вариант 1: В лямбде, который обрабатывает запрос API, сначала выполните запись в экземпляр MySQL, чтобы добавить новую строку. Когда ответ от MySQL возвращается успешным, напишите что-то вроде SQS, которое позже будет прочитано из другого лямбда-выражения, отправляющего электронное письмо. Когда ответ от SQS будет успешным, что запись была добавлена в очередь, отправьте 201 ответ, в котором говорится, что вызов REST API был успешным.

Вариант 2: В лямбде, который обрабатывает запрос API, напишите в экземпляр MySQL, чтобы добавить новую строку. Когда ответ от MySQL возвращается успешным, отправьте 201 ответ, в котором говорится, что вызов REST API был успешным. Затем настройте задачу DMS (служба миграции данных), которая выполняется бесконечно, для отправки двоичных журналов изменений базы данных в поток kinesis, который запустит лямбда-код, который обработает все изменения в БД, прочитает изменение как новую строку в определенной таблице и отправит электронное письмо.

Вариант 1:

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

Вариант 2:

• дополнительная инфраструктура (задача dms, экземпляр репликации)
• масштабирование сегментов может означать потерю упорядоченности при обработке событий binlog, если упорядоченность является требованием (это так)
  • дополнительный вопрос: Можете ли вы выбрать хэш-ключ для kinesis для задач dms из mysql?
• единая кодовая база для реагирования на все изменения в БД может фактически упростить следующую логику в коде

Это компромисс или я что-то упускаю? Какова наилучшая практика в этом сценарии?

Вариант 1, на мой взгляд, кажется наиболее логичным, но я бы заменил SQS и вторую лямбду на SNS. Итак, модифицированный вариант 1 может быть:

Вариант 1: В лямбде, который обрабатывает запрос API, сначала выполните запись в экземпляр MySQL, чтобы добавить новую строку. Когда ответ от MySQL будет успешным, опубликуйте сообщение с подтверждением в SNS, которое отправляет электронное письмо. Когда ответ от SNS будет успешным, отправьте 201 ответ, в котором говорится, что вызов REST API был успешным.

Это должно быть быстрее, дешевле и проще в реализации, чем использование SQS и второго лямбда-выражения для отправки электронной почты.