Блог

Для определенного приложения я думал о настройке с использованием разветвления SNS — SQS и подписки на лямбды в очередях SQS. Является ли излишним использовать очереди SQS между SNS и лямбдой или я должен подписаться на лямбду в моих разделах SNS? Я не хочу терять сообщения, которые не удалось обработать во время обработки, но, возможно, я смогу решить это с помощью DLQ, привязанного к lambda? Есть ли конкретное преимущество / разница в использовании SQS между ними?

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

Например, в потоке бронирования новое бронирование может публиковаться в разделе SNS, в котором есть очередь для уведомления склада, очередь для отправки клиенту электронного письма с подтверждением и очередь для обновления некоторых баллов лояльности на основе этого заказа.

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

Если у вас есть один элемент, вы бы просто использовали SQS. SQS поддерживает DLQ для Lambda, поэтому вы сможете использовать это для отладки в случае, если какие-либо элементы не будут успешно обработаны.

Одним из преимуществ SQS перед SNS является то, что с помощью SQS вы можете группировать несколько записей для распространения одновременно (до 10), тогда как с помощью SNS он будет содержать только одно сообщение. По умолчанию вы можете поддерживать до 1000 одновременных вызовов. Если вы используете больше, чем это, элементы могут быть заблокированы (если ваша пропускная способность достаточна).

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

Сначала вам нужно задать эти вопросы :

1. Могут ли пользовательские лямбды масштабироваться до количества сообщений, отправляемых в SNS?
2. Достаточно ли у вас зарезервированного параллелизма для потребительского lambda? (Если не задан параметр, lambda может масштабироваться до 1000 (ограничение регионального параллелизма). Хотя это может быть увеличено с помощью запроса в службу поддержки AWS об ограничении обслуживания)
3. Все ли лямбды в учетной записи / регионе имеют достаточный параллелизм? (в lambda предусмотрено регулирование уровня региона на уровне учетной записи)

Если ответ на все вышеперечисленные вопросы положительный, то промежуточный sqs вам не нужен. Очередь dl, подключенная к lambda, должна быть в порядке.