У меня есть лямбда-функция с фиксированным параллелизмом 1, для которой настроен триггер SQS с batchSize
из 10. Эта функция Lambda публикует только все, что встречается в теме SNS (код занимает всего пару строк). Я использую его, чтобы ограничить огромное количество получаемых сообщений, чтобы мой бэкэнд мог их обрабатывать, не задыхаясь.
Теоретически эта Lambda никогда не должна отправлять ничего в очередь недоставленных сообщений SQS, но 80% сообщений попадают туда! Я не понимаю, почему, поскольку журналы Lambda показывают, что ни одно выполнение не завершается неудачно. Не возникает никаких исключений, и в журналах отображаются только успешные выполнения.
В какой момент Lambda решает, что конкретное сообщение должно быть помещено в очередь недоставленных сообщений? (моя политика повторного получения имеет максимум 3).
Похоже, ты не удаляя полученные сообщения в вашей лямбда-функции после обработки.
Я предполагаю, что происходит следующее:
В конечном итоге все сообщения из-за этого попадают в DLQ.
Я прав? :)
Не отвечая прямо на ваш вопрос, но почему ваш бэкэнд опрашивает SQS и обрабатывать по одному сообщению в своем собственном темпе? Это был бы более распространенный образец.
Тогда вы могли бы также масштабировать серверную часть обработка (если применимо) путем добавления дополнительных узлов в зависимости от глубины очереди SQS. Если ваши сообщения приходят чаще, например в рабочее время и реже в ночное время, ваша серверная часть должна быть в состоянии догнать поток в более спокойное время.
В качестве альтернативы, если вас интересуют только самые свежие сообщения, вы можете установить срок годности примерно до 1 минуты, по истечении которой сообщение исчезнет из очереди, а серверная часть получит более свежее сообщение.
Я думаю, что это лучшая архитектура, чем пытаться ограничить скорость передачи сообщений через Lambda в SNS, и надеюсь, что серверная часть не отстает.
Если делать Опрос SQS в серверной части невозможно, дайте нам знать, и мы еще раз рассмотрим вашу проблему с Lambda / DLQ;)
Надеюсь, это поможет :)
Еще одна идея - поскольку срок действия сообщений в SQS составляет до 4 дней, можно процесс опроса SQS с некоторой устойчивой скоростью (в зависимости от пропускной способности RDS) и повторной отправкой в SNS. Который обработать будет реализовывать необходимое регулирование - вести счетчик сообщений, обработанных за последнюю минуту, и откладывать следующий опрос SQS до тех пор, пока пропускная способность не станет ниже предела. Простой алгоритм скользящего окна должен помочь. Вы можете получить вдохновение от ограничение скорости сети у него та же цель - ограничить пропускную способность для получателя.
Это будет намного проще реализовать, чем иметь Лямбда, запускаемая SQS и пытается ограничить его с помощью ограничений параллелизма и размера пакета - такой метод может иметь довольно непредсказуемый профиль пропускной способности.
Вы можете проводить опрос в долго работающей Lambda (я считаю, до 10 минут на запуск) или, может быть, лучше в качестве службы в контейнере, работающем на Fargate или ECS. Все, что дешевле.
Мог ли это быть ответ?