Архитектура сервиса обработки задач [PHP]?

Question

[i-c-stars]

Приветствую!

Есть тривиальная задача - отправлять письма, смс, вызывать какие-то эндпоинты и прочее, по тригеру

Текущая реализация -
Прилетает, скажем, запрос на создание заказа от пользователя, в сопутствующий эндпоинт
Происходит всякая подкапотная работа скрипта и добавляется в таблицу задач, задача на отправку письма "Спасибо за заказ бла-бла-бла"
В фоне, в бесконечном цикле, работает php скрипт, который обрабатывает задачи из таблицы

Проблема - не хвататет скорости поточной обработки, а асинхронности в PHP нет

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

Есть библиотеки для работы с потоками. На данный момент остановился именно на такой реализации, брать пачку задач и для каждой запускать свой поток, дожидаться выполнения всех, изменять статусы задач и брать новую пачку

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

Comments

[Виталий Артемьев]

Ничего не мешает запустить скрипт в несколько инстансов
Только при выборке записей из БД нужно их блокировать чтобы другие инстансы не брали их в работу

[Виталий Артемьев]

Вот так
"select * for update"

Ну либо использовать очереди

[Дмитрий]

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

но по факту все что вы тут расписали - решается очередью. сидит демон и мониторит очередь на наличие задач - получил обрабатывает. не получил - сидит ждет. профит по сравнению с чем? с вашей реализацией манагера потоков на php? ну при всем уважении к вам и пхп по стабильности я поставлю на какой нибудь rabbitmq, да и по скорости тоже на него.

[Vitsliputsli]

Дмитрий, со стабильностью у php нет никаких проблем. Да и, правильно организованная очередь в БД работает также хорошо, как и при использовании брокера сообщений. Проблема у автора в том, что единственный воркер получив задание обрабатывает его долго, та же отправка email процесс не быстрый, все время пока воркер ждет ответ при обработке задания новых он не берет. Соответственно те же проблемы будут и с брокером очередей, воркер один, и время работы будет очень большим.
Самое простое решение, как уже указали, использовать несколько воркеров, столько, сколько будет оптимальным. Для этого проще всего запускать их в разных процессах, чем использовать потоки или подключать асинхронность.

[Дмитрий]

Vitsliputsli, у меня нет претензий к пхп. претензии будут к попытке написать манагер процессов на пхп. это несколько разные вещи.

Соответственно те же проблемы будут и с брокером очередей, воркер один, и время работы будет очень большим.

И можете продолжить - ровно те же проблемы будут с манагером процессов. Потому что через неделю после того как вы напишите манагер процессов без ограничения спавна процессов - вы либо сами себе по шапке дадите, либо кто либо еще прибежит - и у вас будут лимиты. Собственно далеко ходить не надо php-fpm ровно такой Process Manager, ровно с лимитам. А разницы между тем что бы в манагере процессов мониторить количество воркеров, либо в каком нибудь супервизоре количество менять - я не вижу. если вы видите, то хотелось бы услышать

[Vitsliputsli]

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

[Дмитрий]

Vitsliputsli, а какая разница в том что вы в своем манагере процессоров запустите 20 процессов изначально, или в супервизоре пропишете 20 демонов которые будут смотреть в очередь? разница только в том что надо будет самому написать свой манагер процессов на каком нибудь swoole. Когда я года полтора назад с ним возился, segmentation fault я ловил запросто, а в octane который его использовал - писали честно на свой страх и риск. Не вопрос - у меня руки кривые, а с тех пор там все пофиксили - но по факту я думаю будет куча сложностей.
Манагер процессов нужен что бы получать задачу, создавать воркер - отправлять туда на исполнение и ловить оттуда отлуп успешного/неуспешного выполнения. Если мы используем прослойку для общения между не связанными между собой процессами на php - то о каких потоках которые собирается запускать автор идет речь? В качестве прослойки берем тот же rabbitmq - и вперед.

[Vitsliputsli]

Дмитрий, вы описываете более сложную архитектуру, здесь достаточно простой.
Очередь - брокер сообщений или просто таблица в БД.
Воркер - скрипт работающий демоном. При запуске он подключается к Очереди, затем переходит в бесконечный цикл. В каждой итерации, забирает задание из Очереди, затем выполняет его, затем рапортует в Очередь, что это задание завершено. И заново тоже самое.
При необходимости можно запустить еще один воркер, и еще, и еще... Они независимы и не требуют специального управления. Это очень простая схема и не требуются ни потоки, ни асинхронность.

[Дмитрий]

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

[Vitsliputsli]

Дмитрий, "демон + очередь" у автора уже есть, но 1 демон не вытягивает по скорости. Отсюда собственно и вопрос автора о параллелизме, который он хотел решить потоками, а ему предложили процессами. Т.к. решать это потоками или асинхронностью будет гораздо сложнее и вряд ли выигрышнее. Собственно об этом я и написал в первом комментарии: "Самое простое решение, как уже указали, использовать несколько воркеров, столько, сколько будет оптимальным. Для этого проще всего запускать их в разных процессах, чем использовать потоки или подключать асинхронность."
Если нет возражений по поводу этого решения, то значит мы друг друга недопоняли и спорим не о том.

[Дмитрий]

Vitsliputsli,

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

Видимо. Вы только что написали ровно то что я писал - решать такую задачу на PHP потоками и сложнее и невыигрышнее. и ровно то что вы решили оспорить.

[Vitsliputsli]

Дмитрий, если просто согласиться нельзя, а нужно потыкать, кто не прав. То вот ваш комментарий:

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

но по факту все что вы тут расписали - решается очередью. сидит демон и мониторит очередь на наличие задач - получил обрабатывает. не получил - сидит ждет. профит по сравнению с чем? с вашей реализацией манагера потоков на php? ну при всем уважении к вам и пхп по стабильности я поставлю на какой нибудь rabbitmq, да и по скорости тоже на него.

Здесь нет ни слова о параллелелизме, а все упоминания воркера в единственном числе. Как решение здесь предлагается очередь и лучше rabbitmq. Собственно это я и оспаривал, что проблема автора не в очереди (она у него уже есть, разве что может нужно добавить защиту от гонки), а в отсутствии параллелизма. Именно об этом, я и написал:

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

А далее вы ввели зачем то менеджер процессов и с ним спорили, а я в каждом ответе писал, что это не нужно и все более подробнее описывал простую архитектуру с несколькими процессами.
Может вы это и подразумевали, но в тексте этого нет.

[Дмитрий]

Vitsliputsli, окей. тыкайтесь
1. Читаем вопрос автора.

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

В этом заявлении автора определенная доля истины. Особенно когда у вас в качестве очереди используется какая нибудь бд, и вы стоите перед выбором - побыстрее забирать задачу, или не нагружать бд лишними запросами. У вас может быть определенный оверхеад между положить задачу в очередь - и тем когда очередь кто то опросит на наличие задач и заберет эту задачу в обработку. На первый взгляд это решается манагером процессов - то есть сидит какой то демон, котором в лоб пуляют задачу, он спаунит воркера и тот начинает работу. никакого оверхеада.
Я ж пытался сказать - что писать на пхп этот манагер процессов будет занятием неблагодарным. и когда решат эту не благодарность - выяснится что оверхеад был и не таким большим. А когда всплывет что надо контроллировать количество воркеров, как то решать проблему с ожиданием когда все воркеры заняты, а задачи поступают, рассматривать какую то персистентность на случай - а у нас все упало - выяснится что оверхеда вообще нет. Типа юзайте какую нибудь нормальную очередь, супервизор и все будет хорошо.
И все бы было действительно хорошо, если в тему с ноги не ворвались вы с криком "со стабильностью у php нет никаких проблем"

2. Слушайте вы 4 дня спать не могли от того что в этих ваших интернетах кто то с вами не согласен? Господи, да расслабьтесь вы, скоро новый год

[Vitsliputsli]

Дмитрий,
1. В принципе оно правильно, только к вопросу автора не имеет отношения. В который раз пишу, автор правильно определил проблему и задал конкретный вопрос про параллелизм. Вы же ему ответили как и сейчас на все что угодно, только не на вопрос. И на это я указал тогда, и сейчас.
2. Это прям самонадеянно, жизнь не только этот форум. И я предлагал выше, остановиться на том, что пришли к единому решению, но вам захотелось докопаться кто был неправ.

[Дмитрий]

В принципе оно правильно,

Уф спасибо а то теперь бы я 4 дня не спал. А ведь новый год.

только к вопросу автора не имеет отношения

Что ж читаем дальше. У автора есть

В фоне, в бесконечном цикле, работает php скрипт, который обрабатывает задачи из таблицы

Но ему не хватает силенок обработать и автор собирается:

Есть библиотеки для работы с потоками. На данный момент остановился именно на такой реализации, брать пачку задач и для каждой запускать свой поток, дожидаться выполнения всех, изменять статусы задач и брать новую пачку

То есть мастер процесс получает задачи, и для выполнения их запускает потоки. Хммм. Как бы это назвать. Вот в голове верится что то, а вспомнить не могу. Может вы скажете?
А когда скажете - я скажу это писать не надо, по причинам выше описанным, юзайте очереди и воркеры через супервизор, и все будет хорошо. php стабилен.

Это прям самонадеянно, жизнь не только этот форум

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

Answer 1

[rPman]

асинхронности в PHP нет

Если основная причина того что обработчик событий не успевает - в том что он долго:
* отправляет сетевой запрос (отправка sms или почта)
* просто таймеры, например запросы сетевые отправлять нужно с интервалами
* работа с файлами (асинхронно будет быстрее)
то на это вполне существуют асинхронные фреймворки, например очень мощный ReactPHP, у него очень хорошая база, большое коммунти и мне кажется на любой чих найдется библиотека.

Если же речь о чем то абстрактном

(например запускается внешний процесс и нужно ждать его ответ) то тут асинхронность вполне реализуется самостоятельно. да конечно есть готовые библиотеки (в зависимости от того можно ли держать очередь в памяти или в базе данных, тот же брокер событий reactPHP вполне можно взять за основу).

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

Скрипт обработки событий смотрит на текущие события и при необходимости тупо запускает фоновый процесс на каждое действие (можно считать количество процессов со статусом "Запущено и ожидает окончание" и если их больше лимита - ничего не делать, пропускать, т.е. ждать изменений в очереди или просто сбыдлокодить sleep).

Так же этот скрипт может следить за временем исполнения задач (например повторы), достаточно просто сохранить время последней попытки и где то определить, какие задачи какие временные лимиты (я это определял в коде php, никто не мешает это прямо в базе данных у задачи определять)

Задача фонового процесса отметиться в базе данных, правкой состояния
- Ожидает исполнения -> Запущено и ожидает окончания
- Запущено и ожидает окончания -> Окончено ...

Скрипт может сам следить за pid процессов, отмечая у себя какой процесс был запущен для какой задачи, таким образом можно отлавливать вмешательство администратора или ОС (например из-за нехватки памяти) и как то интерпретировать это (повторить попытку или отвести в статус фатальных).

В итоге, любая задача будет запущена в виде процесса ОС, в linux это делается с помощью bash ... & а в windows - например start /min. Сам процесс обработки очередей будет занят сном, чтением списка процессов и проверкой pid уже запущенных, на это не требуется никаких особых ресурсов (при необходимости очередью может рулить этот процесс, буквально вместо базы данных слушать сокеты и принимать заявки на исполнение, в phpreact для этого все готово, даже слабые машины могут легко тянуть десятки тысяч запросов, я эксприментировал с websocket)

p.s. самый тупой демон параллелизации запуска процессов - это командная утилита linux parallel, ей можно отдавать список команд через linux pipe, построчно, он будет ждать новую команду если всю работу выполнил и тормозить основной процесс, если буфер пайпа переполнен (он настраивается). Само собой следить за тем как все исполняется придется самому.