Я использовал Beanstalkd для одного проекта и планировал снова. Я обнаружил, что это отличный способ запуска асинхронных процессов.
Несколько вещей, которые я сделал с этим:
- Изменение размера изображения - и со слегка загруженной очередью, передаваемой PHP-скрипту на основе CLI, изменение размера больших (2 МБ +) изображений работало просто отлично, но попытка изменить размер тех же изображений в экземпляре mod_php регулярно выполнялась в пространстве памяти проблемы (я ограничил процесс PHP до 32 МБ, а изменение размера заняло больше)
- проверки на ближайшее будущее - в beanstalkd есть задержки (сделать это задание доступным для запуска только через X секунд) - так что я могу отменить 5 или 10 проверок для события, чуть позже
Я написал систему на основе Zend-Framework для декодирования «симпатичного» URL-адреса, например, для изменения размера изображения, которое он назвал бы QueueTask('/image/resize/filename/example.jpg')
. Сначала URL был декодирован в массив (модуль, контроллер, действие, параметры), а затем преобразован в JSON для внедрения в саму очередь.
Затем долго выполняемый сценарий cli выбирает задание из очереди, запускает его (через Zend_Router_Simple) и, если необходимо, помещает информацию в memcached для того, чтобы PHP веб-сайта мог подобрать ее по мере необходимости.
Одна морщина, которую я также добавил, заключалась в том, что cli-скрипт выполнял только 50 циклов перед перезапуском, но если он действительно хотел перезапустить, как запланировано, он сделал бы это немедленно (будучи запущенным через bash-скрипт). Если возникла проблема, и я выполнил exit(0)
(значение по умолчанию для exit;
или die();
), он сначала приостановился бы на пару секунд.