SQS звучит так, как вы хотите.
Вы можете запустить несколько «рабочих» процессов, которые конкурируют за сообщения в очереди. Каждое сообщение используется только один раз. Логика «блокировки» / тайм-аута, о которой вы упомянули, заключается в следующем: если один из ваших работников умрет после загрузки сообщения, но до его обработки, то вы хотите, чтобы это сообщение в конечном итоге истекло и было повторно загружено для обработки на другом узле.
Да, SQS построен на модели опроса. Например, у меня есть несколько вариантов использования, в которых я использую мельчайшее задание cron для опроса новых сообщений в очереди и выполнения действий над любыми найденными сообщениями. Этот шаблон глупо просто построить и творит чудеса для множества вариантов использования - удобный маленький «клиентский» скрипт, который помещает сообщение в очередь, и активированный cron скрипт, который обработает это сообщение в течение минуты или около того.
Если ваш шаблон сообщений крайне скудный - например, всего несколько сообщений в день - проводить опрос постоянно, пока очередь пуста, может показаться расточительным. Это вряд ли имеет значение.
Мой первоначальный расчет состоял в том, что минимальная работа за крон будет стоить $ 0,04 (теперь $ 0,02) в месяц. С тех пор в SQS добавлена функция «Long-Polling», которая позволяет достигать задержки в секунду при обработке новых сообщений, отправляя 1 сообщение «long-poll» каждые 20 секунд для опроса очереди ожидания. Плюс они упали на 50%. Таким образом, в месяц это 131 тыс. Сообщений (~ 0,06 доллара), немного дороже, но с обработкой запросов почти в реальном времени.
Имейте в виду, что описанная мною крона работа, которую я описал, стоит всего $ 0,04 / месяц при загрузке запроса (30д * 24ч * 60м * 1с / 10k мсг). Таким образом, в любой момент цена не должна быть проблемой здесь. Даже опрашивая каждую секунду, цена поднимается только до $ 2,59 / мес, не совсем так, как банкрот.
Однако можно избежать частых опросов, используя веб-сервис, который принимает HTTP-сообщение SNS. Такая архитектура будет работать следующим образом: клиент отправляет сообщение в SNS, который отправляет сообщение в SQS и направляет HTTP-запрос в ваш веб-сервис, вызывая его опустошение очереди. Вы все равно хотите опрашивать очередь ежечасно или ежедневно, на случай, если HTTP-запрос будет отброшен. В конце концов, я не уверен, что могу придумать любой сценарий, который действительно оправдывает такую сложность. Я бы предпочел платить по 0,04 доллара в месяц за то, чтобы в моей очереди был простой грязный задание.