Как использовать Amazon SQS? Сценарий импорта/процесса

Question

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

Сервер: Главная Выделенный сервер сервер B: Cloud Process Server

• Сервер отправляет сообщение SQS через SNS сказать "Начало процесса"
• Сервер B постоянно опрашивает SQS для "Начать процесс" сообщение
• Сервер B находит "Start Process" сообщение на SQS
• Сервер B запускает файл "process.sh"
• Сервер B завершает работает файл "process.sh"
• Сервер B удаляет "Start Process" из SQS
• Сервер B посылает сообщение SQS через SNS сказать "Start Import"
• опросы Сервер постоянно опросы SQS для "Start Import" сообщение
• Сервер находит сообщение «Start Import» на SQS
• Сервер работает import.sh
• Сервер завершает работы «import.sh»
• Сервер удаляет «Start Import» из SQS

Это как SQS следует использовать, или я полностью теряю точку?

Answer 1

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

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

Например: требуется изменить, и вы хотите добавить процесс C, который также запускается каждый раз, когда «Start Process» запускается на Sever B. Прямо через консоль AWS SNS вы можете направить вторую копию сообщения другому Очередь, которая ранее не существовала, и настроить сервер C, который опросит эту очередь (шаблон выключения).

Кроме того, то, что мне часто нравится делать во время первоначального развертывания, заключается в добавлении уведомлений в SNS, поэтому я знаю, что происходит, т.е. каждый раз, когда происходит событие «start process», я подписываю свой мобильный телефон (или адрес электронной почты) на тему, поэтому я получаю уведомление - я могу контролировать в реальном времени то, что (или нет) происходит. По прошествии некоторого времени после развертывания производства я могу войти в консоль AWS и просто отказаться от подписки на свою электронную почту/ячейку процесса - без всякого прикосновения к любым серверам или коду.

Answer 2

Мне почти жаль, что Amazon предлагает SQS как услугу. Это не «простая очередь» и, вероятно, не лучший выбор в вашем случае. В частности:

• имеет плачевную производительность при низкой громкости сообщений (некоторые сообщения будут принимать 90 секунд, чтобы прибыть)
• порядка сообщений не сохраняются
• он любит доставлять сообщения более чем один раз
• они взимать плату за опрос

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

Answer 3

Ну ... SQS не поддерживает маршрутизацию сообщений, чтобы назначить сообщение серверу A или B, почему одно из доступных решений: создать темы SNS «сервер a» и «сервер b». Эти темы должны помещать сообщения в SQS, которые ваше приложение будет тянуть. Также возможно реализовать веб-крючок - подписчика на SNS-событиях, которые будут анализировать сообщение и выполнять обратный вызов для вашего приложения.