Создание сообщений Amazon SNS для обработки в будущем

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

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

Существуют ли какие-либо дизайнерские подходы, альтернативные услуги, хитрые приемы, которые мы могли бы использовать, чтобы добиться этого?

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


person northernMonkey    schedule 01.12.2014    source источник


Ответы (3)


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

Служба Amazon Simple Notification Service (SNS) предназначена для немедленной отправки уведомлений. Отложенная отправка не предусмотрена (хотя некоторые типы уведомлений повторяются в случае сбоя).

Amazon Simple Queue Service (SQS) имеет функцию задержки, но только до 15 минут. Это полезно, если вам нужно выполнить какую-то работу до обработки сообщения, например скопировать связанные данные в Амазон С3.

Учитывая, что ваше требование состоит в том, чтобы дождаться некоторого будущего произвольного времени (фактически, как система планирования), вы можете либо запустить процесс и сказать ему спать в течение определенного периода времени (плохая идея в случае перезапуска систем) или продолжить ваш подход опроса из базы данных.

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

person John Rotenstein    schedule 08.12.2014
comment
Моя ситуация такая же, как и в первом абзаце вопроса. Вы сказали, что это самый мудрый подход. Не могли бы вы пояснить философию дизайна, стоящую за этой структурой, и, возможно, объяснить какие-либо другие передовые методы? Я тоже искал SNS, но не нашел нужной функции планирования. Теперь я собираюсь сделать простое приложение для оповещения в дополнение к моему основному приложению, которое просто просматривает БД и запускает оповещения. Действительно ли так делают корпоративные приложения? - person trademark; 16.02.2018
comment
@trademark, пожалуйста, задайте новый вопрос, а не задавайте его в комментарии к старому вопросу. - person John Rotenstein; 17.02.2018

Неделя может быть слишком долгой, так как само хранение сообщений SQS составляет всего 15 дней. Если у вас все в порядке с максимальным сроком хранения 15 дней, одна из идей состоит в том, чтобы сохранять изменение видимости сообщения каждый раз, когда вы получаете, пока оно не будет готово к обработке. Максимально допустимое время ожидания видимости составляет 12 часов. Подробнее о времени ожидания видимости и API для их изменения см.

http://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html

http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/AboutVT.html

person shadowfax    schedule 18.12.2014