Гаечка

Это можно решить на уровне nginx c помощью try_files и X-Accel-Redirect, вообще без кеша.
Например, так:

location <локейшен с картинками>{
    try_files $uri @resize;
}
location @resize {
    proxy_pass http://<адрес ресайзера с параметрами>;
}
location /notexist.gif {
    root /path/to/notexist/folder;
}

Тогда энджи сначала попытается найти файл (ресайзер должен его сохранить там перед отдачей), если не найдет - попробовать отресайзить (запустится ресайзер, который, напомню, должен сохранить картинку на диск перед отдачей), а если ресайзер не нашел исходную картинку - ему надо вернуть X-Aссel-Redirect заголовок с uri /notexist.gif

Подробнее про X-Accel можно почитать тут wiki.nginx.org/X-accel

Использовать же для этого кеширование энджи - неправильный путь, ибо вы получите недетерминированный результат.

Gearman раздаёт задачи по кругу всем слушателям. Разделить между воркерами можно только по имени вызываемой задачи: один слушает одну, другой – другую. Такой вариант не подходит?

Наконец-то нашел решение :)
В httpd/error_log нашел интересную запись:

[Tue Apr 09 15:42:42 2013] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0

Выключил SELinux, перезапустил сервак — все заработало.

Gearman как раз то. Он поддерживает паралельный запуск задач и получение ответа по завершению (aka callback) через методы (doNormal, doHigh, doLow).
С форками работать сложнее, но тоже можно. Для каждой итерации вы форкаете новый процесс и записываете куда то результат, вопрос только в том, как потом общий результат прочитать. В общем я бы вам посоветовался поближе разобраться с gearman

На самом деле оба варианта по реализации настолько минимально отличаются, что хорошим советом будет «сделайте сейчас оба варианта, используйте сначала файлы, а когда файлов будет много померяете производительность».

В 99% случаев файлы лучше, т.к. к ним есть прямой и очевидный доступ без всяких баз, а база в любом случае прослойка.

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

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

Файлы при прочих равных однозначно лучше попадают в кэш, с другой стороны засирание кэша базой проще контроллировать.

Самый простой способ — по крону запускаете «надсмотрщика» (supervisor). Надсмотрщик сохраняет свой PID в файл, мемкеш или БД и если видит, что другой надсмотрщик уже запущен — молча умирает.

Надсмотрщик должен быть предельно прост, чтобы не падать. Обнаружить падение надсмотрщика можно по тому признаку, что файл с PID есть, а процесса с таким PID нет — значит предыдущий надсмотрщик внезапно завершился. Это можно зафиксировать в лог.

Если надсмотрщик запустился и других надсмотрщиков нет, он берет задания и запускает одного или несколько скриптов-рабочих (worker), каждому раздает по заданию. Если кто-то из рабов успешно завершился, помечаем задачу как выполненную, если умер — он логгирует это и запускает нового, если с N попыток задача так и не сделана, она помечается как невыполнимая и больше не выполняется.

SELECT * FROM test WHERE MATCH('@title hello @body world')