PHP Lang
  1. PHP Lang
  3. Как использовать AWS SQS / SNS в качестве push-очереди уведомлений для задач большой обработки через PHP?
Intereting Posts
Как работает «неустановленная» конструкция PHP внутри? Переменные переменные в PHP – Какова их цель? Запись в xml-файл, когда оператор javascript if равен true Предупреждение: Division by Zero Работа с PHP и MySQL Свяжитесь с нами по электронной почте не работает в codeigniter php Как создать входы / элементы формы в ZF2 Регулярное выражение для удаления начальных и конечных символов из строки? LOAD DATA LOCAL INFILE запрещен в … PHP Как обрабатывать ошибку json-декодирования с помощью try and catch 500 – Произошла ошибка! Функция DB сообщает об ошибках при добавлении новой статьи в Joomla! foreach и simplexml PHP fopen () Предел перенаправления достигнут PHP Цитирование по датам Бесплатная библиотека входа PHP Какова самая эффективная проверка того, заканчивается ли строка PHP другой строкой?

Как использовать AWS SQS / SNS в качестве push-очереди уведомлений для задач большой обработки через PHP?

У меня есть один сервер, работающий на rackspace, где размещается одно веб-приложение 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.

Мои проблемы с примером архитектуры разветвления (как я понимаю):

  1. сервер, который отправляет сообщение в SQS или SNS, также будет тем же сервером, который обрабатывает задачу генерации метаданных. На самом деле это одно и то же веб-приложение.
  2. SQS выполняет часть очереди (потому что я хочу выполнять задачи в FIFO, и задачам требуется много времени). Однако для этого требуется, чтобы мое веб-приложение постоянно проводило опрос SQS. Я хочу получить push-уведомление (от AWS к моему веб-приложению), а не опробовать веб-приложение AWS непрерывно, чтобы проверить выполнение задач.

Я нашел возможное решение, предложенное здесь

Предлагаемое решение:

  1. отправьте сообщение в тему SNS.

  2. В теме SNS будут указаны как очередь SQS, так и мое веб-приложение.

  3. Мое веб-приложение после запуска будет опросить ту же очередь SQS, которая теперь ставит в очередь сообщение до тех пор, пока очередь не будет пуста

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

Каков наилучший способ реализации push-очередей с использованием служб AWS?

мое веб-приложение будет опросить очередь до того, как сама очередь получит сообщение

Вы ведь не пробовали? 🙂 Боюсь, вы слишком задумываетесь об этом. SQS имеет длительный опрос , что приводит к приостановке запроса опроса на стороне SQS до тех пор, пока не будет доступно хотя бы одно сообщение, после чего будет возвращено сообщение (до максимального количества, которое вы запросили). Вы можете установить длительное время ожидания опроса от 1 до 20 секунд. Если в течение этого временного интервала нет сообщений, ответ возвращается без сообщений.

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

Другая проблема, однако, заключается в том, что вы не хотите, чтобы приложение постоянно проводило опрос SQS. Я часто сталкиваюсь с этим возражением, и это часто бывает неуместным. При длительном опросе SQS «постоянный» опрос пустой очереди означает один запрос каждые 20 секунд. Это 3 req / minute, 180 req / hour, 4320 req / day, 129600 req / month …, которые кажутся менее 1 миллиона бесплатных запросов, разрешенных каждый месяц.

Проблема с вашим сервером, реагирующим на уведомления, а не на опрос очереди в фоновом режиме с соответствующим количеством работников, заключается в том, что вы потенциально легко перегружаетесь большой партией рабочих мест, прибывающих примерно в одно и то же время. Если вы получаете 10 одновременных запросов, можете ли вы справиться с этим? 100? 1000? Часто для заданий, которые являются асинхронными, как это, он стоит меньше (с точки зрения ресурсов) для запроса задания, чем для выполнения задания (например, для загрузки изображения требуется гораздо меньше ЦП, чем для изменения размера изображения). Если вы не согласовываете реакцию реакции, вы можете подавить свою систему.

Не попадайте в концептуальную ловушку «опрос – это плохо, толчок хорош», где он не применяется. Подавляющее большинство времени, это настроение абсолютно правильное … опрос – это почти всегда неправильное решение … но с длинным опросом SQS, то, что у вас действительно есть, – это механизм push, завершенный таким образом, который делает его совместимым с HTTP , и большая часть присущего злу опроса … исчезает. Если вы находитесь в середине длинного опроса, очередь пуста, и приходит сообщение, ваш длинный опрос вернется с этим сообщением почти сразу. Он не сидит, ожидая, когда будет время ожидания. Фоновый процесс, наблюдающий за очередью, может быть хорошим способом пойти в конце концов.