Как реализовать приоритетную архитектуру очереди с использованием лямбды и SQS?

Question

Я использую SQS и lambda для обработки некоторых конкретных запросов.Каждый запрос может содержать сообщения от 1 сообщения до сотен тысяч сообщений.Работает нормально, единственная проблема в том, что маленькие запросы иногда должны ждать тех больших запросов, которые уже находятся в очереди (потому что все параллельные лямбда заняты, и я не хочу увеличивать мой лямбда-параллелизм).Поэтому я думаю иметь две очереди, одну для маленьких запросов и одну для больших запросов, чтобы маленький запрос мог быть обработан быстрее.но проблема состоит в том, как назначить номер лямбда-параллелизма каждой очереди.Прямо сейчас я установил лямбда-параллелизм на 30, но если большой запрос поступит, то все 30 лямбда будут заняты.Можно ли как-то сказать лямбде использовать частично параллельную лямбду (скажем, 20 для больших и 10 для маленьких запросов) на основе очереди SQS, которая ее запускает?или есть ли другие лучшие практики для реализации такого рода требований?

Answer 1

Есть ли способ указать лямбде использовать частично лямбду одновременно

Нет, после развертывания они будут работать как настроено.

Плюс я не думаю, что этодолжна быть проблема Lambda использования.Вы можете контролировать свою активную длину очереди, имея многоуровневую очередь.Чрезмерно упрощенным решением будет

• Создать 2 очереди ожидания , по одной для больших и коротких сообщений.
• Создать одну активную очередькоторый направляет сообщение в ваш Lambda потребитель.
• Производители отправляют запросы в wait очереди.
• Пишут логику для перемещения сообщений из wait очередей в активных очередей.Этот фрагмент кода должен иметь логику для распространения сообщений в соответствии с требованиями вашего бизнеса.

Answer 2

У вас может быть две копии вашей функции: одна для больших запросов с 20 зарезервированным параллелизмом, а вторая для небольших запросов с 10 зарезервированным параллелизмом.

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

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