веб-сервисы Amazon — Как использовать AWS SQS / SNS в качестве очереди push-уведомлений для сложных задач обработки через PHP?
У меня есть один сервер, работающий на стойке, на котором размещается одно веб-приложение PHP.
Веб-приложение PHP примет отправку формы, которая затем должна будет выполнить задачу на основе записей поля формы.
Задача (назовем ее задачей генерации метаданных) требует довольно много времени на обработку. Мне было интересно, как сделать так, чтобы отправка формы была простым сохранением в базе данных и сразу показывала страницу успеха пользователю при выполнении задачи создания метаданных в фоновом режиме.
Я установил "aws/aws-sdk-php": "~3.11" используя композитор в том же веб-приложении.
Мой план изначально такой:
код, который обрабатывает отправку формы
$result = $model->save($_POST);
// this code will send the information to either SQS or SNS
$awsClient->sendsMessage($_POST);
if ($result) {
$this->redirect('success.html');
}
Я читал о разветвленная архитектура заявлено AWS.
Мои проблемы с примером архитектуры разветвления (насколько я понимаю) таковы:
- сервер, который отправляет сообщение в SQS или SNS, также будет тем же сервером, который обрабатывает задачу создания метаданных. На самом деле это одно и то же веб-приложение.
- SQS выполняет часть очереди (потому что я хочу выполнять задачи в FIFO, а задачи занимают много времени). Однако для этого требуется, чтобы мое веб-приложение постоянно опрашивало SQS. Мне нужно push-уведомление (от AWS к моему веб-приложению), а не к тому, чтобы мое веб-приложение непрерывно опрашивало AWS для проверки выполнения задач.
Я нашел возможное решение, предложенное Вот
Предлагаемое решение:
-
отправить сообщение в тему SNS.
-
В теме SNS будет отображаться как очередь SQS, так и мое веб-приложение.
-
Мое веб-приложение после запуска будет опрашивать ту же очередь SQS, которая теперь постоянно помещала в очередь сообщение, пока очередь не станет пустой.
Из этого я вижу недостаток, заключающийся в том, что мое веб-приложение будет опрашивать очередь, прежде чем сама очередь получит сообщение.
Каков наилучший способ реализации push-очередей с использованием сервисов AWS?
Решение
мое веб-приложение будет опрашивать очередь, прежде чем сама очередь получит сообщение
Вы тогда не пробовали, верно? Я боюсь, что вы думаете об этом. SQS имеет длительный опрос, что приводит к тому, что запрос опроса приостанавливается на стороне SQS до тех пор, пока не будет доступно хотя бы одно сообщение, после чего будет возвращено это сообщение (до максимального количества, которое вы запросили). Вы можете установить длительное время ожидания опроса от 1 до 20 секунд. Если в течение этого периода времени нет доступных сообщений, ответ возвращается без сообщений.
Если вы опросите очередь в ответ на уведомление от SNS, вы будут найти сообщения там, если вы используете длинный опрос. Сообщения могут быть отложены, но высоко навряд ли.
Другая проблема, однако, заключается в том, что вы не хотите, чтобы приложение постоянно опрашивало SQS. Я сталкиваюсь с этим возражением довольно часто, и он часто неуместен. При длинном опросе SQS «постоянный» опрос пустой очереди означает один запрос каждые 20 секунд. Это 3 рэк / минута, 180 рэк / час, 4320 рэк / день, 129600 рэк / месяц … что оказывается меньше, чем 1 миллион бесплатных запросов, разрешенных каждый месяц.
Проблема, связанная с тем, что ваш сервер реагирует на уведомления, а не опрашивает очередь в фоновом режиме с соответствующим количеством работников, заключается в том, что вы будете потенциально перегружены большой партией заданий, поступающей примерно в одно и то же время. Если вы получаете 10 одновременных запросов, можете ли вы справиться с этим? 100? 1000? Зачастую для таких асинхронных заданий запрашивать задание дешевле (с точки зрения ресурсов), чем для его выполнения (например, загрузка изображения должна потребовать гораздо меньше ресурсов ЦП, чем требуется для изменения размера этого изображения). Если вы не координируете свою реакцию, вы можете разрушить свою систему.
Не попадайтесь в концептуальную ловушку «опрос — это плохо, толчок — это хорошо», где он не применим. В подавляющем большинстве случаев это мнение абсолютно правильное … опрос почти всегда является неправильным решением … но при длительном опросе SQS у вас действительно есть механизм push, заключенный таким образом, что он совместим с HTTP и многое из присущего злу опроса … исчезает. Если вы находитесь в середине длинного опроса, очередь пуста, и приходит сообщение, ваш длинный опрос вернется с этим сообщением практически сразу. Он не сидит в ожидании тайм-аута. Фоновый процесс, отслеживающий очередь, может быть хорошим способом продвинуться.
Другие решения
Других решений пока нет …
detector