Медленные и/или ресурсоёмкие задачи в коде: отложенные задания, очереди, задачи с ручной обработкой

    Публикую по просьбе eugenioz.

    При работе больших Web проектов бывают такие задачи, выполнение которых не является необходимым прямо сейчас, однако действия критические и выполнить их обязательно. Такие действия можно проводить прямо в коде и при неудачной попытке повторять. Но, на мой взгляд, подобное лучше сразу выполнять вне основного кода задачи: этим разгружается код и достигается однообразие выполнения.

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

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

    Код класса

    И теперь пояснения.

    Задачи хранятся во временной директории в виде файлов. Скрипт, запускаемый по крону, получает список задач и выполняет у каждой задачи метод execute. После успешного исполнения файл задачи удаляется. Класс можно переработать для работы с MySQL-базой. Это имеет смысл, поскольку можно делать DELAYED INSERT, который не блокирует исполнение, однако сейчас используется файловая система в силу её большей надёжности.

    Создаётся задача как обычный элемент алгоритма, не изменяя логики.

    Например, было:
    $q_upd=update_order_data($params);
    стало
    $q_upd=tasks::create("update_order_data", 'api', 0, $params);

    У задач есть уровень приоритета, благодаря чему можно при каждом запуске cron-скрипта выполнять задачи в порядке «важности». Чем больше параметр priority, тем дальше отложится задача.

    Вариант cron-скрипта: код.

    Рядом с классом Tasks в коде есть класс task_handlers — именно в task_handlers вы можете создать обработчик.
    Имя функции этого класса является именем обработчика, которое можно задать в момент создания задачи. В качестве примера приведены обработчики 'mysql' и 'mail' — их код мал, поэтому удобен для иллюстрации.

    Автор кода — eugenioz, разрешает использовать код под лицензией MIT.

    Несмотря на простоту и легковесность этого класса, он позволяет очень эффективно распределить нагрузку, не изменяя при этом логику алгоритмов.

    Ещё раз примеры применения:
    • на странице настройки профиля одного из сервисов нужно взаимодействовать с другим сайтом, подтверждая у него данные. Сайт этот тоже мог ответить «не сразу». Вывод лаконичного «проверяется» в одном из блоков — гораздо лучше, чем генерация всей страницы в несколько секунд из-за задержки в одной строке;
    • в данный момент для всех посетителей, которые зашли на wap-сайт с мобильного телефона, и чей IP не оказался в списке IP-гейтов операторов, создаётся задача проверки IP. В свободное время берётся whois-информация об IP и проверяется на наличие слов, которые могут указывать на принадлежность к оператору сотовой связи. При наличии таких слов IP добавляется в список «на проверку» и после «ручной» проверки этот IP может быть внесён в список IP-гейтов операторов;
    • работа с удалённым API, который может быть недоступен, но действие может быть отложено и должно быть исполнено. Например, зачастую реселлерские панели не повторяют заказов, что приводит к большому количеству жалоб и упущенной выгоде.


    eugenioz: Внимательно выслушаю конструктивную критику, вопросы и предложения по улучшению.

    Комментарии 96

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

      Надёжность FS выже надёжности MySQL просто потому что MySQL на FS опирается в работе.
        0
        > Надёжность FS выже надёжности MySQL просто потому что MySQL на FS опирается в работе.

        «надёжность IEEE 802.11b выше надёжности TCP/IP просто потому что TCP/IP опирается в работе на IEEE 802.11b»
          +3
          надёжность одного отдельного винчестера выше надёжности RAID-1 просто потому что RAID-1 опирается в работе на отдельные винчестеры
            +2
            Прикольно передёргиваете. Сразу видно профессионала.
              0
              я не передёргиваю, а опровергаю высказывание «если A опирается на B, то A надёжнее, чем B», которым вы неявно воспользовались, и привожу некорректные примеры, чтобы показать некорректность использованной вами логики :)
                +1
                во-первых, у вас ошибка в словах «MySQL на FS опирается в работе», потому что, в частности, InnoDB может работать без файловой системы, напрямую с RAW-партишном.

                во-вторых (и самое важное), у вас ошибка в «потому что», потому что высказывание «Надёжность FS выже надёжности MySQL» не находится в причинно-следственной связи с высказыванием «MySQL на FS опирается в работе».

                при этом своими комментариями я (внимание) не оспариваю и не подтверждаю, что «Надёжность FS выже надёжности MySQL» — я не знаю, так это или не так. я оспариваю, что, даже если надёжность FS выше надёжности MySQL, то это вовсе не потому, что «MySQL на FS опирается в работе»
                  0
                  InnoDB может работать без файловой системы
                  Everything is file. Нельзя работать с устройством без файловой системы: VFS и сотоварищи незримо присутствуют.

                  Сделайте перед запуском rm -f /dev/* и посмотрите, что получится у mysqld и InnoDB.

                  я оспариваю
                  Надёжность A не может быть выше надёжности B, если A в своей работе использует только один экземпляр B. А код FS у MySQL ровно один — одно ядро используется (mysql-cluster и подобные это другая история, они используют не один экземпляр FS).
                    0
                    замечательно.

                      –1
                      надёжность FS выже надёжности MySQL просто потому что можно удалить /dev/* или /etc/mysql/* НУ И ГДЕ ВАША MYSQL ТЕПЕРЬ?!?
                        0
                        обычно, когда говорят о «надёжности FS», то подразумевают такие штуки, как журналирование, алгоритм выделение блоков, записывается ли при перезаписи файл на старое место или на новое, всякие такие вещи. а вы, оказывается, говорили о том, что нужно отнять у mysql доступ к /dev/
                        super!
                          0
                          Да-да. Передёргивайте дальше :-)

                          У слова «Надёжность на некотором отрезке времени» есть ровно одно значение: $1 — вероятность отказа за этот отрезок времени$.

                          Я лишь показал, что MySQL зависит от FS на настолько простом уровне, что даже InnoDB не сможет стартовать если /dev созданы неправильно. Не говоря уже о записи в файлы.
                            0
                            мы говорим о сферических mysql в вакуумах?

                            ну, по-моему, довольно очевидно, что когда мы говорим о MYSQL, то мы подразумеваем, что MySQL установлена, все зависимые библиотеки тоже установлены, они лежат по тем путям, по которым их будет искать mysql, всё это работает, у mysql есть конфиг, mysql правильно сконфигурирована, мы знаем пароль, мы можем подключиться к ней, у нас есть права на доступ к конкретной БД, мы можем сделать запрос
                              0
                              Надёжность (англ. reliability) — свойство объекта сохранять во времени в установленных пределах значения всех параметров, характеризующих способность выполнять требуемые функции в заданных режимах и условиях применения, технического обслуживания, хранения и транспортирования (ГОСТ 27.002—89).
                              то есть да, вероятность, но при определённых условиях.
                              в частности, обеспечив существование /dev/… и /etc/mysql/my.cnf (что просто: достаточно сетевой загрузки и NFS'а), и сравнивая надежность mysql на отдельном диске против надежности ФС на том же диске, мы получим, что mysql надёжней.
                                0
                                >и сравнивая надежность mysql на отдельном диске против надежности ФС на том же диске, мы получим, что mysql надёжней.
                                Слова, конечно, не интересны. Покажите, почему mysql надёжнее. Простая задача: предоставить механизм когда mysql работает после 100 запросов после крушения файловой системы.
                                  0
                                  я соглашусь с утверждением, что mysql менее надёжен, чем ядро и devfs, благодаря которым он имеет доступ к raw partition.
                                    0
                                    devfs-то тут причём? Доступ к raw идёт только через VFS, а файлы устройств может создавать кто угодно.
                                      0
                                      tmpfs, ok. и ядро. mysql действительно менее надёжен, чем ядро линукса.
                                        0
                                        ОК. А FS это, случаем, не ядро?

                                        В основном, имелось ввиду, что если на устройстве кончится место, то и MySQL откажет (потому-что FS откажет), и FS.
                                          0
                                          FS — это вроде бы способ хранения упорядоченных данных с метаинформацией. ну а обычно подразумевается кто-то, кто её читает и пишет (модуль ядра) и собственно сама структура данных, записанная на носителе информации (жестком диске то есть).

                                          м. да, с этим-то я согласен.
                                      0
                                      И-таки приведите пример, когда mysql работает после 100 запросов.
                                        0
                                        да при чём тут 100 запросов?

                                        mysql. вы делаете insert'ы и update'ы в innodb/mysql в несколько потоков одновременно. и в середине этого процесса вырубаете питание. если клиент был удалённым, то незакоммиченные транзакции закоммитить уже не получается. при включении питания вы убеждаетесь, что те транзакции, которые закоммитились, действительно закоммитились. те транзакции, которые не закоммитились, действительно не закоммитились.

                                        теперь файлы. речь же у нас ФС на накопителе с постоянной памятью, правда? пишем файлы. во много потоков. отключаем питание. включаем питание. какие-то файлы добавились, какие-то — проебались. причём, если мы делали это с удалённого хоста, то какие-то файлы якобы сохранились, но на самом деле нет.

                                        соответственно, функцию «сохранить данные и сообщить об успехе, либо сообщить об ошибке» mysql выполняет надёжнее
                                          0
                                          Если вы вырубить питание внезапно в середине записи транзакций, то не факт что запись успеет дойти до всех кэшов. Можно и битую таблицу получить, то есть отказ.

                                          Сильно сомневаюсь, что MySQL в при COMMIT'е выполняет fsync().

                                          Мы какие-то разные надёжности рассматриваем. Я — на полный отказ, вы — на частичный.
                                            0
                                            If set to fdatasync (the default), InnoDB uses fsync() to flush both the data and log files.
                                              0
                                              Даже при записи в файлы, а не в девайс?
                                          0
                                          Странно, что MySQL'ю Вы прощаете незакоммиченые транзакци, а FS — не прощаете не до конца записанные файлы. То, что транзакция была отправлена но не была записана — это отказ.

                                          И если вы внезапно удалить устройство (физически), на которое пишется БД, то отказ у FS и у MySQL/InnoDB/device будет одинаковым. И тот и другой сообщат об ошибке, но это будет отказ в обоих случаях.
                                            0
                                            нет, я не прощаю ничего мусклю. просто mysql, если закоммитила транзакцию (и сообщила об успешном результате), то транзакция уже не потеряется, а если FS записала файл (и сообщила об успешном результате), то это ещё ничего не значит.
                                            собственно, поэтому fsck fsck fsck и делается.

                                            > И если вы внезапно удалить устройство (физически), на которое пишется БД, то отказ у FS и у MySQL/InnoDB/device будет одинаковым. И тот и другой сообщат об ошибке, но это будет отказ в обоих случаях.
                                            нет, отказ как раз будет разным. и тот и другой сообщат об ошибке, но у FS могут быть файлы, которые вроде как записались, но на самом деле нет.
                                              0
                                              Да, в этом случае, MySQL «надёжнее» FS на которую она опирается. Однако это не-ГОСТовый смысл.

                                              Вам, видимо, достаточно сообщения об ошибке. Я считаю, что ошибка, даже с сообщением (и тем более без) — это уже отказ. ГОСТ, видимо, про сообщениях об ошибках ничего не знает.

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

                                              В общем, я согласен, что MySQL иногда говорит об ошибках лучше, чем FS. Однако не считаю, что это делает его надёжнее (однако позволяет сделать более очевидным отказ приложения опирающегося на MySQL, по сравнению с приложением на FS).
                                    0
                                    Кстати. А стены надёжнее фундамента?
                                      0
                                      надёжнее ли стены одного здания чем фундамент другого здания?
                                        0
                                        Понятно. Всё-таки передёргивать вы хорошо умеете, да.
                                          0
                                          да и вы мастер задавать бессмысленные вопросы, надо признать
                                0
                                Потому, что MySQL опирается на FS. Если FS порушится и удалится конфиг-файл MySQL то он и не запустится.

                                Если FS откажет, то MySQL встанет боком и свистнет раком. Если MySQL откажет, то FS этого и не заметит.

                                Разве это не очевидный результат из теории вероятности? Более сложный компонент опирается на простой -> вероятность отказа сложного не меньше, чем простого.
                                  0
                                  помимо полных отказов, существуют также риски потери данных.
                                  1. например, вы создаёте и редактируете кучу мелких файлов в несколько потоков одновременно. и в середине этого процесса вырубаете электричество.
                                  2. например, вы делаете insert'ы и update'ы в innodb/mysql в несколько потоков одновременно. и в середине этого процесса вырубаете электричество.

                                  в первом случае у вас пропадёт несколько последних секунд, плюс какие-то файлы получатся битые — часть файла содержат старые данные, часть — новые данные; могут даже повредиться директории.
                                  во втором случае вы получите, что в таблице есть все данные, которые успели туда записаться до выключения. всё!

                                  обычно под надёжностью понимается именно это. разве не так?
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      0
                                      > могут даже повредиться директории.
                                      Не читайте советских газет во время обеда. © Профессор Преображенский.

                                      А если писать сплошным потоком прямо на диск постоянно, то ничего не повредится. И если взять хорошую FS — то ничего не повредится даже в этом случае. Как я уже сказал: A не может быть надёжнее B в случае если B использует один экземпляр A. Это же аксиома надёжности электрических цепей.

                                      > во втором случае вы получите, что в таблице есть все данные, которые успели туда записаться до выключения. всё!

                                      Здорово! Только данные там будут не все, и это уже отказ (потеря надёжности).

                                      Ещё раз: у нас под надёжностью понимается вероятность неотказа на некотором промежутке времени. Вы используете своё, особое, определение надёжности, определяемое на журналиуремость и выделение блоков.
                                        0
                                        > А если писать сплошным потоком прямо на диск постоянно, то ничего не повредится. И если взять хорошую FS

                                        прекрасно. то есть теперь вы говорите не то, что «FS надёжней MySQL», а то, что «хорошая FS надёжней MySQL». это в каком-то смысле прогресс.

                                        под надёжностью я и все разумные люди всё-таки подразумеваем «свойство объекта сохранять во времени в установленных пределах значения всех параметров, характеризующих способность выполнять требуемые функции в заданных режимах и условиях применения, технического обслуживания, хранения и транспортирования (ГОСТ 27.002—89).»
                                        если бы вы читали, что я вам пишу, вы бы смогли его увидеть. уверяю вас, я не использую своего определения. вообще, где вы там определение увидели-то?
                                          0
                                          > то есть теперь вы говорите не то

                                          Нет, теперь вы выдернув из контекста мои фразы пытаетесь заставить меня такое сказать.

                                          MySQL опирающаяся на FS не может быть надёжнее последней. В случае отказа FS, которую использует MySQL, MySQL откажет так же.

                                          > под надёжностью я и все разумные люди всё-таки подразумеваем
                                          Это уже ad hominem.

                                          Хорошо. Когда у вас есть фундамент, а потом вы строите над ним дом, то фундамент является отдельным объектом, а дом без фундамента объектом не является (поскольку фундамент в доме неустраним без разрушения дома).

                                          Тогда способность дома выполнять требуемые функции в заданных режимах и условиях применения зависит от способности фундамента, как составной части, делать это. То есть надёжность фундамента входит в надёжность дома (в том числе и при расчёте).
                                            0
                                            я с вами согласен, но нужно определиться, что мы меряем.
                                            потому что я считаю, что нужно сравнивать надёжность дома vs надёжность фундамента соседского сарая. а вы хотите сравнить надёжность дома vs надёжность фундамента того же дома. естественно, что фундамент надёжнее, но достаточно установить ECC-фундамент, и его надёжность будет пренебрежимо мало отличаться от 1.
                                              0
                                              А надёжность современных компьютерных программ пренебрежимо мало отличается от 1. Настолько мало, что меряются уже -log(1-надёжность).

                                              Вы хотите сказать, что надёжность MySQL не зависит от надёжности FS? Да, в специальном случае когда вы пишите в raw-device. Но даже в этом случае какая-то FS может порушить стэк VFS и это приведёт к краху MySQL.

                                              Что бы исправить ошибку связанную с конкретной FS достаточно иногда записать в другое место, но это уже другой экземпляр FS, и вероятности отказа будут считаться иначе.
                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                  0
                                                  «Some one is wrong in the Internet.»
                    • НЛО прилетело и опубликовало эту надпись здесь
                        +1
                        $fp = fopen("/корень/var/flock",«w+»);
                        if (flock($fp, LOCK_EX + LOCK_NB)) {
                        //код задачи
                        } else {
                        echo «Already running»;
                        exit;
                        }

                        Так более надёжнее лок задачи с помощью файла. В вашем случаи если скрипт повиснет, то ждать обработки придется 10800 секунд.
                          +1
                          Точнее не при повисании, а при смерти скрипта.
                            0
                            Ага. Первая вещь которую стоит поправить.
                            • НЛО прилетело и опубликовало эту надпись здесь
                            0
                            Не ново… Не хватает:
                            1) возможность указания кол-ва одновременных паралелльных процессов(например, ровно 10)
                            2) возможность хранить в базе с кучей собственных параметров и выполнять по eval'у
                            3) функционал управления алертами и логгированием о выполненных задачах
                            4) отслеживание выполнения джобов в базе
                            • НЛО прилетело и опубликовало эту надпись здесь
                                +1
                                Я поясню почему говорю об этом. У нас, например, часто генерируются большие и долгие отчеты, кроме того ежедневно, еженедельно и ежемесячно проводятся кучи всяких работ в том числе и автогенерация отчетов и прочее. Поэтому время запуска отложенные задания настроены как на выполнение в определенное время, так и просто — например, щелкнули — выдать отчет такой-то. Отчет выполняться может до 10 минут. Если ставить все это делать по-одному, то кто-то может вместо 10 минут, ждать полчаса, т.к. вместе с ним еще несколько отделов дали задания сделать свои отчеты.
                                  +1
                                  Лучше лочить тогда каждый файл задачи отдельно. Это уже подробности реализации cron-сервера.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      0
                                      Можете, например, форки из pcntl заюзать, раньше они были нестабильные, поэтому эта часть у нас на перле была всегда.
                                        0
                                        На хостингах они открыты?

                                        Я так помню, на большинстве хоситнгов можно вызов некоторого URL'а в cron поставить.
                                          0
                                          Речь же о больших проектах шла, а на небольших на простых хостингах, наверное, из-за ограничений нагрузки и не дадут исполнять по 20-30 тяжелых джобов.
                                            0
                                            Просто изначально топик мною был неверно назван: речь скорее о отложенных заданиях, а не о ресурсоёмких.

                                            Ресурсоёмкость же можно определить как «имеет смысл переложить это задание в очередь: его результат на код не влияет, а выполняется он значительно дольше чем постановка в очередь».
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                  +3
                                  Вместо очередного велосипеда: gearman.org
                                    0
                                    А на хостингах как быть?
                                      +2
                                      Если вы будете выполнять «ресурсоёмкие задачи», как написано в заголовке — вас просто выпрут с шареда. А VDS по-моему сейчас не такой уж и дорогой.
                                        +1
                                        Топик назван не корректно, надо переименовать, наверное. Задачи-же могут быть не только ресурсоёмкими но и просто медленными: связь с удалённым хостом, отсылка данных, ручная проверка.

                                        Тут этот класс является достаточно неплохим минимальным решением.
                                          0
                                          Ну, и, конечно, ресурсоёмкость разная бывает: если задача чуть сложнее добавления task'а в очередь и её возвращаемое значение не интересно прямо сейчас, то можно отложить и на потом. Правда, смысла в таком мало.
                                        +1
                                        Вместо очередного gearman.org велосипеда: Globus Toolkit
                                          0
                                          А грид-вычисления здесь причём? С таким же успехом можно и mapreduce/hadoop сюда приплести.
                                            0
                                            Википедия про gearman как про mapreduce и думает: WIKI

                                            А при том, что фактически эту работу может делать и globus toolkit. И создан он раньше. И уровень защищённости у него больше. И используется больше. Ну, то есть, по сравнению с ним — gearman совсем новый велосипед.

                                            Хотя, конечно, задачи совершенно у них разные и в первую очередь разный «вес». Как и у приведённого кода класса и gearman, отношение приблизительно такое.
                                              +1
                                              В википедии написано что gearman концептуально похож на mapreduce. Mapreduce можно реализовать на gearman, но это не из этого не следует, что это единственная задача которую gearman может решить. Основное назначение gearman — отложенные вычисления, т.е. именно то, о чём и написано в посте.
                                              Ваше дилетантское сравнение с globus toolkit порадовало. Вы не понимаете чем грид-вычисления отличаются от отложенных вычислений. Да, при желании с помощью gearman можно реализовать и грид-вычисления, но опять-таки это не основное его назначание. Также хотелось бы знать в чём вы меряете «уровень защищенности» и откуда у вас данные о частоте использования globus toolkit в сравнении с gearman (хотя как вообще можно их сравнивать, если они решают разные задачи?).
                                                0
                                                То есть, получается, «приплести mapreduce» тут можно?

                                                Gearman, прежде всего, для передачи вычислений на другую машину создан. Отложить в нём задачу а потом спросить «как она там» в нём не вижу как. Подскажите, если можно.

                                                При помощи globus toolkit можно и отложенные вычисления реализовывать, он для этого сгодится. (Я никогда не говорил, что это одно и то же, только лишь что globus toolkit умеет делать работу gearman давно). Но опять-же, это по воробьям из пушки. И при помощи gearman можно (и довольно хорошо) делать простые grid-системы. Это как слону дробинка.

                                                Но и gearman для отложенных вычислений на хостинге — это слишком тяжеловесное решение.

                                                Про частоту использования: давайте сравнивать количество машинного времени (в flops'ах), которую обработал globus toolkit и gearman. Разницу будет видно, думаю, сразу.

                                                Про защищённость: не смог найти в документации по gearman как на нём авторизовываться и как данные предотвращаются от перехвата (шифрование). Может, документация старая. Сейчас гляну исходники.
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                    0
                                                    Спасибо, это нашёл уже. Но вывод получить всё равно нельзя, не понимаю, кому нужна задача без вывода?

                                                    А можно создать задание, отдетачится, а потом получить данные? Тоже, так сразу не нашёл.
                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                        0
                                                        Тогда нужно два gearman'а и или регистрировать клиента как worker'а — вся идея идёт на смарку (никто не гарантирует что во втором случае задача не попадёт на ту же машину).

                                                        А как вы результаты забираете?
                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                              0
                                              Кстати, а detach'иться от помещённых заданий в нём можно? Так, что бы потом можно было проверять статус задачи на лету и получать часть данных которая уже готова? Что-то не могу найти в коде perl-клиента.

                                              А то предстоит мне одну вебморду для научных вычислений делать, как раз такая штука нужна.
                                                0
                                                gearman.org/index.php?id=protocol
                                                Можно детачиться и получать статус выполнения. Получать данные частями — либо уже можно, либо будет возможно в будущем, точно не помню. У воркера есть сообщение WORK_DATA, наверное это то, что вам нужно.
                                                Eric Day говорил об этом в одном из докладов. Если не лень, можете поискать в его презентациях, их хоть и много, но они не сильно отличаются друг от друга.
                                                  0
                                                  Нет, вроде это делает GET_STATUS, умеет отдавать процент от выполненного. Нужно, конечно, всегда смотреть код. А то мало-ли.

                                                  Думаю, удастся ли убедить админа поставить gearman и имеет ли смысл делать такой патч. Не можете разузнать, хотят ли они реализации отдачи данных кусками? Тогда можно будет написать патч.
                                                    0
                                                    Всмысле, WORK_DATA не умеет этого делать для background задач.

                                                    WORK_DATA, WORK_WARNING, WORK_STATUS, WORK_COMPLETE,
                                                    WORK_FAIL, WORK_EXCEPTION

                                                    For non-background jobs, the server forwards these packets from
                                                    the worker to clients. See «Worker Requests» for more information
                                                    and arguments.


                                                    А вот статус получить можно.
                                                      0
                                                      По идее WORK_DATA должен отдавать эти данные серверу на хранение для не-бекграундных воркеров. Как будет на самом деле — не знаю, не смотрел.
                                                      Патчу наверное будут рады, но у них были планы переписать gearman на C++, поэтому не исключено, что патч сейчас могут и не принять. В любом случае общаться по этому поводу нужно не со мной, а скорее всего с Эриком.
                                                        0
                                                        Ответил: отдаёт WORK_DATA, но сервер их игнорирует.

                                                        В версии 0.13 смотрите (cd ./libgearman-server):
                                                        1) Добавление задачи в server.c, стр 272: server_client = NULL;
                                                        2) Обработка WORK_DATA в server.c, 485,
                                                        3) Выполнение _server_queue_work_data, добавлине данных в очередь, проходит по списку server_client. См. server.c стр. 959.
                                                          0
                                                          Вот и получается, что для того что бы сделать это на PHP с этим PHP-классом мне нужно лишь поправить его, а для gearman нужно будет поправить исходник и библиотеку, линковать с PHP и так далее.
                                                        +1
                                                        Не умеет, я посмотрел код. Если вы запускаете задачу в BG, для неё просто не создаётся структура хранящая обмен между клиентом и сервером, в которую данные WORK_DATA записываются.
                                                    +1
                                                    Совет на будущее — возьмите на вооружение конвенции ZF/PEAR coding style, который на сегодняшний день практически является стандартом, и приведите к ним ваш код, напишите нормальные phpdoc-комментарии — это повысит его ценность вдесятеро. После этого можно уже можно будет обсуждать достоинства/недостатки реализации.
                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                      0
                                                      Чем больше параметр priority, тем дальше отложится задача.
                                                      Может стоило сделать наоборот? Ведь логичнее выполнять сперва задачи с более высоким приоритетом.
                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                        0
                                                        не ново
                                                          0
                                                          Не хватает выполнение через определенное количество времени.
                                                          Например я добавляю — обновить информацию через определенно количество времени.
                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                            0
                                                              0
                                                              Ещё один язык для выполнения простой задачи? Что-то не так с этим миром.
                                                                0
                                                                почему язык MessageQueue… из той же серии ZeroMQ и прочие BlaBlaMQ
                                                              0
                                                              А есть чтото подобное на memcached/apc/redis?

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

                                                              Самое читаемое