каков будет возможный подход к go: SQS или SNS?


Я собираюсь сделать приложение rails, которое интегрирует облачные сервисы Amazon.

  • у меня есть сервис explore amazon SNS, который дает возможность публичной подписки, которую я не хочу делать. Я хочу уведомить только конкретного абонента. Например, если у меня есть 5 подписчиков в одной теме, то уведомление должно быть отправлено конкретному подписчику.
  • я также изучил SQS amazon, в которых мне нужно написать опросник, который отслеживает очередь для сообщений. SQS также имеет механизм блокировки, но проблема в том, что он распределен таким образом, что был бы шанс получить то же самое сообщение из другой копии очереди для процесса.

Я хочу знать, каков был бы возможный подход, чтобы пойти.

1 8
ruby-on-rails amazon-web-services amazon-sns amazon-sqs

1 ответ:

SQS звучит так, как вы хотите.

Можно запустить несколько "рабочих" процессов, конкурирующих за сообщения в очереди. Каждое сообщение используется только один раз. Логика "блокировки" / тайм-аута, о которой Вы упомянули, заключается в следующем: если один из ваших сотрудников должен был умереть после загрузки сообщения, но до его обработки, то вы хотите, чтобы это сообщение в конечном итоге истекло и было повторно загружено для обработки на другом узле.

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

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

Мой первоначальный расчет состоял в том, что мелкая работа крона будет стоить $0.04 (теперь $0.02) в месяц. С тех пор SQS добавила функцию "Long-Polling", которая позволяет достичь субсекундной задержки при обработке новых сообщений, отправляя 1 сообщение "long-poll" каждые 20 секунд для опроса бездействующей очереди. Плюс они снизили цену на 50%. Таким образом, в месяц это 131 тыс. сообщений (~$0.06), немного дороже, но с запросом почти в реальном времени обработка.

имейте в виду, что описанная мною мелкая работа cron стоит только ~$0.04 / месяц при загрузке запроса (30d*24h*60m * 1c / 10k msgs). Так что в мельчайших деталях стоимость не должна быть проблемой здесь. Даже если опрашивать каждую секунду, цена растет только до $ 2,59 / мес, а не совсем банковский бустер.

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

15