Ответ

G_Z 24.01.2017 20:07

Ситуация, которую вы описали - типичная архитектура подсистем и под-сервисов, которые, при разной скорости обслуживания обработки - разруливаются через сервис очередей (MOM - Message-Oriented Middleware), из известных это RabbitMQ или проч.

Это и есть работа с очередью.
Только задачи уже выбраны из очереди и воркеры хотят загрузить внешний документ.

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

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

Это часть краулера, собирающего документы.

Даже наколенная архитектура подсказывает, что держать 10 сек и более (полчаса, час?) процесс, который обслуживает клиентский HTTP-запрос - как-то неправильно (ну только если это не бесконечный push/чат).

Это не клиентский запрос.
Это фоновая очередь, задачи которой исполняют демоны.

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

И при этом не положить сервер десятком одновременных запросов.

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

Процесс понятия не имеет долго там или быстро.
Отчасти, это он и выясняет.

Можно играть или созданными для этого инструментами, или своими, но смысла натягивать "сову на глобус" через flock, когда есть mysql(memory-table)/memcached - не вижу.

MySQL не умеет блокировать несуществующие в таблице записи и для подобной задачи непригоден.
А там где умеет обкладывает всё такой развесистой порослью неявных блокировок, что зачастую проще всё сделать руками.

Memcached вполне подходит как инструмент для очереди или блокировок, но в обсуждаемом случае кроме скорости не имеет никаких преимуществ над file:lock.
А наблюдать за работой через файлы и отлаживать гораздо проще.

---