Назад | Перейти на главную страницу

У меня SQS -> Lambda -> SNS (мои сообщения попадают в очередь недоставленных сообщений)

У меня есть лямбда-функция с фиксированным параллелизмом 1, для которой настроен триггер SQS с batchSize из 10. Эта функция Lambda публикует только все, что встречается в теме SNS (код занимает всего пару строк). Я использую его, чтобы ограничить огромное количество получаемых сообщений, чтобы мой бэкэнд мог их обрабатывать, не задыхаясь.

Теоретически эта Lambda никогда не должна отправлять ничего в очередь недоставленных сообщений SQS, но 80% сообщений попадают туда! Я не понимаю, почему, поскольку журналы Lambda показывают, что ни одно выполнение не завершается неудачно. Не возникает никаких исключений, и в журналах отображаются только успешные выполнения.

В какой момент Lambda решает, что конкретное сообщение должно быть помещено в очередь недоставленных сообщений? (моя политика повторного получения имеет максимум 3).

Похоже, ты не удаляя полученные сообщения в вашей лямбда-функции после обработки.

Я предполагаю, что происходит следующее:

  1. сообщение M1 поступает в SQS,
  2. ваша Lambda принимает его, отправляет в SNS, не удаляет его из SQS и завершает работу.
  3. через некоторое время (после Тайм-аут видимости по умолчанию = 30 с) то же сообщение M1 повторно вставляется в очередь, поскольку оно было получено, но не удалено после обработки.
  4. это происходит 3 раза (в соответствии с вашей политикой Redrive), а затем отправляется на Очередь мертвых писем.

В конечном итоге все сообщения из-за этого попадают в DLQ.

Я прав? :)

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

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

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

Я думаю, что это лучшая архитектура, чем пытаться ограничить скорость передачи сообщений через Lambda в SNS, и надеюсь, что серверная часть не отстает.

Если делать Опрос SQS в серверной части невозможно, дайте нам знать, и мы еще раз рассмотрим вашу проблему с Lambda / DLQ;)

Надеюсь, это поможет :)

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

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

Вы можете проводить опрос в долго работающей Lambda (я считаю, до 10 минут на запуск) или, может быть, лучше в качестве службы в контейнере, работающем на Fargate или ECS. Все, что дешевле.

Мог ли это быть ответ?