Уведомления об очереди недоставленных сообщений AWS SQS - PullRequest
Новая
       18

Уведомления об очереди недоставленных сообщений AWS SQS

1 голос
/ 15 апреля 2019

Я пытаюсь спроектировать небольшую систему обработки сообщений на основе SQS, Lambda и SNS.В случае неудачи я бы хотел, чтобы сообщение было помещено в очередь в очереди недоставленных сообщений (DLQ) и чтобы был вызван веб-крюк.

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

В настоящее время, если все идет хорошо, процесс должен быть следующим:

  1. SQS (на месте для обработки повторов) ставит в очередь сообщение
  2. Lambda вызывается SQS и обрабатывает сообщение
  3. Lambda отправляет веб-крючок и нормально завершает

Если что-то в лямбде идет не так (успех webhook не может быть вызван, задача под рукой не может быть обработана), проще всего добиться того, чего я хочу, - настроить DLQ1, в который SQS будет помещать сообщения о сбоях.Затем будет вызвана вспомогательная лямбда для обработки этого сообщения, передачи его в SNS, который вызовет webhook с ошибкой, а также пересылки сообщения в DLQ2, окончательный / истинный DLQ.

Это лучший подход?

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

Спасибо!

1 Ответ

2 голосов
/ 15 апреля 2019

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

Вот что я бы сделал в случае неудачи:

  1. Определите DLQ в исходной очереди SQS и установите для maxReceiveCount значение i.e 3, означающее, что если сообщения три раза не будут выполнены, они будут перенаправлены на настроенный DLQ
  2. Создайте лямбду, которая слушает этот DLQ.
  3. Запустите веб-крючок внутри этой лямбды.
  4. Поскольку шаг 3 автоматически удаляет сообщение из очереди, как только оно было обработано, и, очевидно, вы хотите, чтобы сообщения сохранялись где-то, сохраните содержимое сообщения в файле на S3 и сохраните метаданные файла (ведро и ключ) в таблице в DynamoDB, так что вы всегда можете запросить сообщения с ошибками.

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

Таким образом, вам нужно поддерживать только один DLQ, и вы можете избавиться от SNS, поскольку это только добавляет дополнительный уровень сложности вашей архитектуре.

...