PHP и Gearman, что и как?

Question

[Anton Kuzmichev]

Здравствуйте!


Интересуют следующие аспекты работы с Gearman в PHP:


— чем концептуально отличается GearmanJob от GearmanTask и какой из них следует использовать для оформления отложенного задания?


— везде в интернете описывается режим работы, когда и воркер, и клиент — демоны. Можно ли демоном сделать только воркера, а клиентскую часть, которая будет помещать задания в Gearman — оформить в коде, вызываемом по HTTP. Чтобы, скажем, обратился я к странице, которая отображает результат длительной операции, в коде формирования страницы ставится задание, а пользователю отдается «Try later». Пользователь жмет F5, вновь запущенный код, что задание уже поставлено и имеет определенный статус выполнения, и возвращает его, или — если задание выполнено — отобразит его результат?


— этот вопрос вытекает из предыдущего: понятно дело, когда клиент — демон, он поставил задание и просто ждет результата, или регулярно опрашивает Gearman на предмет результата, имея handle поставленного задания. В документации php.net/manual/ru/book.gearman.php я не нашел способа, как вновь запущенному скрипту. имея ID задачи, который самому можно задавать. спросить у сервера о ее статусе. handle имеет текстовый вид («H:CompName:4», H:CompName:5, ..), но тут едва ли подойдет так как их нумерация начинается сначала после падения/перезапуска Gearman, Опытным путем я выяснил, что повторный запуск doBackground с теми же параметрами, что и в прошлый раз. вернут тот же handle, НО это если только задача еще в процессе выполнения. Когда задача выполнена, повторный ее запуск будет воспринят как совершенно новая задача. Городить стороннее хранилище, в которое клиент будет помещать задачи (помимо того что он их Gearman'у отдает). а воркер рапортовать о результатах выполнения?


Пользуясь случаем, хочу еще узнать: если вы имели дело с этой темой, какое из решений вы выбрали для организации выполнения отложенных задач? Я в настоящее время выбираю между RabbitMQ, Gearman и php-resque.

Answer 1

[Константин Кияшко]

Доброго :)
Отвечаю на вопросы

— чем концептуально отличается GearmanJob от GearmanTask и какой из них следует использовать для оформления отложенного задания?

Job — это то, что поступает воркеру.
Task — это то, что передает клиент

То есть клиент кидает Task на сервер очередей, там два агрумента — имя ф-и и сериализованные данные (в виде строки).
Если у воркера есть ф-я, указанная в Task, то есть он готов ее обработать, то он принимает задачу, а данные получает в виде Job.
Извлекаются данные вот так (кусок реального кода):

function create_campaign(GearmanJob $job){

$rawData = $job->workload();
$data = unserialize($rawData);
…

А передаются на сервер вот так (я использую не Task, а чуть проще — просто doBackground)

$gclient = new GearmanClient();
$gclient->addServer('localhost');

$new_offers = $client_db->select_new_offers();

if(is_array($new_offers) AND count($new_offers) > 0){
foreach($new_offers as $item){
$data_for_gearman = array(
'item' => $item,
'client_class_name' => 'axxa',
);
$gclient->doBackground('new_offer', serialize($data_for_gearman));
}
}

echo «Для добавления товаров на сервер очередей добавлено ».count($new_offers)." задач \n";

Comments

[Anton Kuzmichev]

Спасибо за разъяснение насчет Job и Task!
А как быть с последующим отслеживанием заданий?

В тестовом коде я ставлю задачу так:

$handle = $client->doBackground($task['name'], serialize( $task['workload'] ), $task['id']);
И вот я имею handle в виде строки и заранее определенный id (скажем, md5 от task[name]+task[workload] );
И то и то — строка.
Я запускаю скрипт client.php с этим кодом, он помещает задание в gearman и завершается. Тестовый воркер-демон получает задание и делает его (некая фейковая нагрузка в цикле от 0 до 10000 + слипы, в общем секунд 20-30, как захочу).

Клиентский же скрипт, если запущу его еще раз, пытается поместить ту же задачу, и если она еще в процессе выполнения — возвращается тот же handle, и корректный статус выполнения (x/y, которые я также регулярно в воркере обновляю). Как только задание воркером выполнено, клиентский скрипт помещает новую, точно такую же задачу.

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

Answer 2

[Константин Кияшко]

Пользуясь случаем, хочу еще узнать: если вы имели дело с этой темой, какое из решений вы выбрали для организации выполнения отложенных задач? Я в настоящее время выбираю между RabbitMQ, Gearman и php-resque.

Gearman — великолепен. Я свой выбор сделал

Answer 3

[Константин Кияшко]

у меня демоны — только воркеры

Comments

[Anton Kuzmichev]

Кстати, по результатам полудневного копания и тестирования могу сказать, что скрипт-воркер неплохо демонизируется и поддерживается с помощью supervisord. В конфиг-файле указываешь команду (/usr/bin/php /var/www/path/to/file/worker.php), число процессов и прочие настройки, service supervisor start — и нужное число скриптов воркеров ждут заданий)

Answer 4

[Константин Кияшко]

их можно запускать из консоли или скриптом.
кстати, я готовлю новую публикацию — веб-интерфейс для сервера очередей. Он давно готов, сыроват, но рабочий, я его юзаю, руки не доходят
Вот код
code.google.com/p/gearman-monitor-and-control/

Answer 5

[Константин Кияшко]

— этот вопрос вытекает из предыдущего: понятно дело, когда клиент — демон, он поставил задание и просто ждет результата, или регулярно опрашивает Gearman на предмет результата…

Я делаю «в лоб» — как только задачи определенной группы начали выполняться, я делаю инкремент одной переменной в БД, как только задача завершается — делаю декремент. В итоге, когда хоть какие-то задачи выпоняются — переменная отлична от 0, как готовы все — там 0. Из веб-приложения аяксом просто опрашиваю БД

Answer 6

[Константин Кияшко]

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

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

Comments

[Anton Kuzmichev]

Да, я видел. Там у вас клиент — демон, пока задача не кончится, он висит. Я же рассматриваю иную модель. Скрипт ставит задачу, и при последующих своих запусках (юзер жмет F5 на странице) проверяет, что с этой задачей6 если еще не поставлена — ставит, если в процессе — пишет ее текущий статус, если выполнена — выдает результаты. Основная проблема — я не нашел способа управлять задачами из клиента из коробки, кроме как ставить их

[Anton Kuzmichev]

Кстати, когда я запустил второй пример из Вашей статьи (раздел Передача данных по частям и дополнительный обмен данными с клиентом) калбэки в клиенте молчали, только серверный скрипт выводил в консоль. Может это связано с версиями gearman'а, хотя я ставил так же, как и в статье.

Answer 7

[justthefish]

Пользуясь случаем, хочу еще узнать: если вы имели дело с этой темой, какое из решений вы выбрали для организации выполнения отложенных задач? Я в настоящее время выбираю между RabbitMQ, Gearman и php-resque.

Уже выбрали, RabbitMQ.
Причина правда не в том, что кролик удобнее для отложенных заданий, а в том, что
1) используется не только PHP, а у rabbitmq очень хорошие биндинги к популярным языкам (не знаю как у gearman)
2) через очередь передаются не только задания, но и «сырые» данные. В rabbitmq это делать (на мой взгляд) удобнее.

Comments

[Anton Kuzmichev]

Да и в германе данные передавать тоже не так сложно, правда не понимаю, что имеется ввиду под «сырыми»: если бинарные какие-нибудь — то еще не проверял, а если много ascii (xml, json, etc) — то легко. Биндинг с PHP хорош (правда справочник по функциям не такой добротный как хотелось бы, помогли туториалы, мануалы и то что сам пробовал и гонял у тебя), на сайте еще пишут про c, perl, java, python, ruby, go.
А когда выбирали, Gearman вообще рассматривался? А то я тоже, сначала выбирал между кроликом и форком rescue из мира ruby… А потом на тебе, третья альтернатива вылезла, и в общем-то уже почти прижилась.

[justthefish]

«Сырые» — это как раз ascii, бинарники передавать черезь очередь не пробовали :)

Рассматривался rabbitmq, gearman или писать свой велосипед (с использованием zeroMQ). Третий вариант отпал, т.к. долго и результат непредсказуем. В том числе выбрали rabbitmq, поскольку с ним были знакомы несколько человек, а с gearman — всего один.