Стандартная SQS AWS Queue, проверка на двойную доставку

Question

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

Какой идеальный способ проверить это? У меня в основном есть лямбда-установка, которая активируется элементами, идущими в очередь. Некоторый расчет сделан на предмете, а данные записаны обратно в БД.

Достаточно ли проверить, записаны ли эти данные в БД, прежде чем записать их снова, если сообщение уже доставлено ранее?

Или есть более причудливый способ сделать это?

Есть ли способ получить очередь FIFO для подачи в лямбду?

Answer 1

Существует несколько вариантов:

1. Наиболее очевидным является наличие в сообщениях уникального идентификатора, а затем его сохранение в каком-либо постоянном механизме (в идеале DynamoDB) для проверки перед обработкой каждого сообщения.Чтобы вы знали, обработано ли это сообщение или нет.В случае, если вы выбрали именно этот маршрут, вы можете использовать этот идентификатор как часть атрибутов сообщения, а не тела сообщения, чтобы вам не приходилось анализировать все тело, чтобы выяснить, является ли он дубликатом
   • Плюсы: обработка сообщений в режиме реального времени
   • Минусы: у вас есть накладные расходы на сохранение идентификаторов и дедупликацию на вашем конце
2. Второй вариантчтобы использовать очереди FIFO и затем иметь запланированную лямбду (используя AWS Cloudwatch Alarms ), опрашивает очереди FIFO по указанному расписанию и, если сообщения присутствуют, обрабатывает их
   • Плюсы: вы экономите накладные расходыСохранение идентификаторов и дедупликация на вашем конце
   • Минусы: не в реальном времени
3. Третий причудливый вариант (только потому, что вы запросили более причудливый вариант) - это иметь2 очереди SQS (1 стандартная и другая FIFO), и ваш производитель сообщений должен поместить сообщения в обе очереди SQS.Теперь у вас есть лямбда-триггер, основанный на стандартной очереди, но когда вызывается лямбда, читайте сообщения из очереди FIFO.Таким образом, если Lambda запускается для дублированных сообщений, то для этого вызова Lambda ничего не будет доступно в очереди FIFO, и вы не будете выполнять какую-либо обработку
   • Плюсы: обработка сообщений в реальном времени, у вас нет проблем с обслуживаниемуникальные идентификаторы
   • Минусы: 2 очереди

Answer 2

Для такой проблемы вы можете попробовать множество обходных путей из ваших сервисов, таких как проверка на наличие дубликатов message_ids или ведение двух очередей для этой цели. Все это кажется законным, но потребляет дополнительную вычислительную мощность. Хорошим решением было бы использование внутренней функциональности самого AWS SQS. Но, тем не менее, этого может быть недостаточно для удовлетворения наших требований. Ниже приводятся несколько подходов, которые можно использовать для этой цели.

1. Стандартная очередь SQS + Lambda + База данных

Это подход, который вы предложили, когда мы проверяем базу данных на предмет обработанных message_ids и стараемся не обрабатывать одно и то же сообщение дважды. Убедитесь, что вы добавили индекс для столбца message_id для более быстрой проверки.

2. Издатель сообщений + Стандартная очередь SQS + Лямбда + База данных

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

3. Стандартная очередь SQS + EC2 + База данных

Вы можете использовать экземпляр EC2 вместо лямбды, чтобы можно было сохранить уже обработанные значения message_id в EC2. Это сохранит операции ввода-вывода базы данных при получении сообщения. Недостатком является то, что вы должны использовать опрос и затраты EC2 намного больше, чем использование лямбды.

4. SQS FIFO Очередь + Лямбда (или EC2) + База данных + Опрос

Вы можете использовать Очередь FIFO и принудительно выполнять ее только один раз, чтобы гарантировать, что дубликаты сообщений не отправляются в SQS. Это включает в себя лямбда (используя CloudWatch) или и опрос экземпляра EC2 для сообщений. Это может быть связано с высокой производительностью, но мы можем обеспечить выполнение нашего требования.

На данный момент лямбда-триггер поддерживается только в стандартных очередях SQS. Следовательно, переход на FIFO не будет вариантом. Если мы посмотрим на практическую перспективу, вариант номер два будет идеальным решением. Это гораздо проще и понятнее, чем делать всю архитектуру спагетти. Надеюсь, это поможет.

Answer 3

Я столкнулся с подобной проблемой и смог решить эту проблему, проверив, что в DynamoDB этот уникальный идентификатор сообщения уже присутствовал. Если бы он уже присутствовал, данные не были бы обработаны. Если ключа еще не было, он будет сохранен в динамо. К этому моменту вы можете использовать потоки динамо-базы данных AWS для выполнения любой необходимой обработки после сохранения динамо-машины с новым ключом через AWS lambda .