Стала задача распараллелить задачу на несколько потоков и по окончанию работы всеx потоков, собрать результаты выполнение воедино. Каким образом это лучше всего сделать?

Это сообщение отредактировал(а) DimaSiK - 10.6.2012, 23:05

Посмотри в сторону очередей RabbitMQ, Apache ActiveMQ
Возможно подойдет Gearman

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

Хотел спросить, правильно ли я понял работу Gearman. Есть Client часть которая создает очередь задач. Worker же в свою очередь - скрипт, который к примеру зпускается каждую минуту CRON и фетчит из текущей очереди задачи. То есть правильно ли я понимаю, что если я создал Cliento-ом 10 обычных задач, затем Worker запустился первый раз - зафетчил первую задачу, потому опять запустился - зафетчила вторую задачу и так далее до 10. Все задачи запущены и Client ожидает теперь выполнения всех 10 задача?

http://php.net/manual/en/book.shmop.php

Или те же самые очереди через pub/sub



Ждать не обязательно.
Можно проверить результат через некоторое время.


Их может быть много.
Они могут не запускаться по крону, а висеть демонами.

А можно повесить один в виде демона, который будет дергать столько инстансов скрипта сколько надо

Или те же самые очереди через pub/sub
 - ага, то есть к примеру я могу использовать Redis для хранения/изменений состояния каждого из worker и таким образом будет осуществляться обмен данными между тредами?
Ждать не обязательно.
Можно проверить результат через некоторое время.
 - А вот меня интересует такой вопрос, насоклько моя схема будет эффективно работать и может можно предложить что-то другое, более лучшее.

Схема:
1. Существует Клиент, который посредставм Gearman создает пускай 10 бекграунных задач.
2. Клиент создал задачи и ушел в цикл ожидания результатов от всех задач.
3. Каждая из задач работает в фоном режиме и обменивается данным посредствам Redis. Таким образом каждая из задча
    в любой момент времени знает состояние остальных.
4. Задачи отработали, Клиент проверяет результаты и выполянет post бработку данных.

В данной схеме меня смущает лишь одно, если какая-то задача отвалилась или зависла не неопределенный период времени, то Клиент
не сделает в таком случае post обработку и будет все так же висеть в цикле и кушать потихоньку память.

Что скажешь?

Как один из вариантов - да.


Контролируй это.
Ставь таймауты на время отклика.
Предусматривай в самих задачах периодическую публикацию своего статуса куда-нибудь.
Если статус не пришел во время, то убиваешь задачу и пускаешь по новой.


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

Спасибо за информацию.

А можно повесить один в виде демона, который будет дергать столько инстансов скрипта сколько надо 
- можешь немного натолкнуть по этому направлению?

У нас делали при помощи кода из этого
http://efiquest.org/2011-10-22/55/ 

Т.е. висит скрипт в виде демона и по fastcgi дергает php-fpm.

Не изобретайте велосипед, Erlang в помощь для таких задач.

Таких это каких?

Столкнулся с проблеммой доступа к БД. То есть master процесс может выбирать данные, но они уже будут неактуальны, так как уже
были изменены дочерними процессами. Есть какая-нибудь ифнормация по этомй проблемме?

Блокировки. Но это просадит общую производительность.

Какого рода данные?
Любые данные обычно имеют свой период устаревания.
Если для ЦУП это секунды и меньше, то для каких-нибудь там счетчиков посещаемости это минуты.

Добавлено через 3 минуты и 21 секунду
Да, еще уровни изоляции транзакций можешь почитать

В чем суть: есть 'менеджер' который запускает столько потоков, сколько считает нужным но не больше определенного количества, чтобы не убить совсем систему. После создания 'менеджер' уходит
в бесконечный цикл ожидания и добавления новых потоков в случае, когда поток/потоки уже отработали. Таким образом 'менеджер' следить за тем, чтобы в единицу времени было запущенно всегда
максимум потоков. 'менеджер' в принятии своего решения запускать новый поток/потоки всегда опирается на таблицу текущего статуса запущенных рпроцессов. Каждый процесс меняет себе статус сам и есть признак окончания, что процесс уже отработал. И возникает иногда проблема, что 'менеджер' выбирает данные, которые не являются уже актуальными, то есть они были уже изменены но он еще об этом не знает, а узнает уже в следующей итерации. Я решил не привязываться к German, хотя до этого его очень хорошо понял. Все построено на базе ZF2, Doctrine и Sys Daemon. Поток 'менеджера' - один и работает как демон вечно, дочерних потоков может быть и 200 и 300 в общем любое количество не угрожающее падению сервера. Каждый поток так же работает как демон, который заканчиваеи свою работу. Связь всех потоков осуществляется через едную таблицу MySQL, доступ через Doctrine.

Добавлено через 1 минуту и 48 секунд
Совсем забыл про твои вопросы:
Какого рода данные?
- тянем новости из различных API. Делаем агрегатор новостей на вырост
Любые данные обычно имеют свой период устаревания.
- обсалютно не существенно