Вопрос по организации очередей на PHP.

Не сталкивался, ни чего не подскажу.

Но вот это:

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

Ты или плохо описал или я тупой и не понял. Но. Воркер взял задачу, отметил ее, начал выполнять упал... и? Задача так и осталась отмеченной и ее больше никто не возьмет. Как ты детектишь падение воркера?

Как ты детектишь падение воркера?

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

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

А. Тогда ясно. Я бы прикрутил еще апдейт таймстампа воркером если он продолжает ее выполнение, чтобы диспетчер видел когда он последний раз откликнулся и случайно не передал успешно выполняющуюся, но чуть притормозившую задачу.

Я бы прикрутил еще апдейт таймстампа воркером если он продолжает ее выполнение

В принципе можно, но этим уже задача будет заниматься, типа, в глубоком цикле периодически вызывать $this->worker()->ping() (сам воркер в одном потоке с задачей, так что пока она работает «его нет»). Это, кстати, с одной стороны вводит лишнюю сущность, с другой, позволит диспетчеру быстро обнаружить упавшего воркера и усложнить процесс обработки — перезапускать задачу сразу же после первого падения и увеличивать ожидание при следующих.

https://github.com/chrisboulton/php-resque

Супер простой воркфлоу, читаемый код, если нет фич - можно форкнуть и начать отсюда.

Ага, интересно. Логика близка к моей, только что под Redis, а не MySQL. Оценю, если будет годно на практике — попробую перейти.

только что под Redis, а не MySQL

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

Ну так оно ж лучше для этого подходит

В плане производительности и лёгкости масштабирования — да. С точки зрения наличия на каждом левохосте — нет :)

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

В описании твоего диспетчера не увидел требований к обеспечению контроля за количеством одновременно выполняющихся заданий

Оно равно числу воркеров, а число воркеров фиксировано :)

Если не сложно, расскажите про схожие решения на java.

в свое время тоже не нашел готового решения - слепил велосипед

Забавно) Прямо сейчас пилю велосипед аналогичный Вашему, только из-за взаимодействия с API у задач состояний побольше. Обязательно дайте знать, если найдёте годное решение.

Чуть выше отвечал на Вопрос по организации очередей на PHP. (комментарий) — интересное решение, очень похожее на моё. Пока «работает — не трогай» мой вариант, но как дойдёт очередь дорабатывать, буду смотреть на практике, м.б. перейду на php-resque. Логика та же, так что менять почти ничего не придётся, а redis в качестве бэкенда интереснее, чем мой mysql.