Прежде всего, я знаю об этом вопросе:
Что я хочу знать, так ли это с Джирмэном? Я планирую отправить партию URL-адресов изображений из веб-приложения PHP к рабочему персоналу (также написанному на PHP, назовем его «Главный рабочий») для обработки асинхронно. Затем этот работник отправит отдельную задачу для каждого изображения для работников нижнего уровня (через addTask ()), вызовет runTasks () и дождитесь завершения задач, прослушивания исключений, накопления сообщений об ошибках и обновления общего состояния задания.
Хотя я отлично справляюсь с получением общего статуса от Главного Рабочего, используя вызовы jobStatus (), тогда просто скажу, что все изображения обработаны, когда возвращены [false, false, 0, 0], я определенно должен быть способен информировать пользователей о том, что некоторые из изображений не могут быть получены из их соответствующих URL-адресов или сохранены на сервере.
Я полагаю, что всегда мог бы хранить пользовательские данные в memcache, а затем извлекать их из веб-приложения, но мне кажется, что это «грязнее» …
Я не пытаюсь получить какой-либо результат, потому что из того, что я видел в руководстве по php.net, даже обработка исключений может быть выполнена только тогда, когда задача отправляется синхронно, не говоря уже о пользовательском извлечении данных. Я просто надеялся, что может быть что-то, что мне не хватает. Я правильно помню, мы используем Ubuntu Server 12.04 с libgearman6 (v 0.27) и PHP 5.3.10. Версия удлинителя передач 1.0.2. Я думаю, что база данных здесь неактуальна, так как я не буду использовать ее ни в одном из рабочих. И я думаю, что мы не используем постоянные очереди прямо сейчас.
Поскольку механизм не будет хранить информацию о задаче в памяти после завершения задачи (просто сообщите об этом для синхронной задачи), вы не сможете получить ее в своем веб-приложении, не сохраняя ее в стороннем месте. Обычно мы используем для этого простой веб-сервис в приложении, позволяя рабочему вернуться к приложению, когда задача завершилась или произошла ошибка. Это позволяет нам поддерживать бизнес-логику в отношении того, что мы хотели бы сделать, когда такая ошибка возникает в приложении, где она принадлежит, и позволить нашим сотрудникам быть более общим (нам может потребоваться изменение размера изображения во многих приложениях, но некоторые приложения могут захотеть для запуска нескольких подпрограмм, которые в первую очередь зависят от изменения размера изображения).
Когда вы пишете, вы также можете позволить работнику напрямую писать в базу данных с состоянием задачи или memcached, но я обнаружил, что позволить самому приложению обрабатывать логику, а не изменять, и особый случай, когда работники работают лучше , Он также хорошо подходит для рабочей среды, позволяя вам поддерживать один и тот же стандартизованный способ обработки обратного вызова через фактический рабочий код.