Анатомия распределенной системы в PHP

Более простой Решением было бы иметь единую базу данных с несколькими подключенными php-узлами. Если вы используете подходящую СУБД (подойдет MSql + InnoDB), у вас может быть одна таблица, действующая как очередь. Затем каждый рабочий будет извлекать из него задачи для работы и записывать их обратно в базу данных по завершении, используя транзакции и блокировку для синхронизации. Это немного зависит от размера данных ввода / вывода. Если он большой, это может быть не лучшая схема.

Я думаю, вы идете в правильном направлении с главным дистрибьютором и рабочими. Я бы попросил их обмениваться данными через HTTP.

Я бы выбрал C, C ++ или Java в качестве клиентов, поскольку у них есть возможность запускать сценарии (execvp в C, System.Desktop.something в Java). Джобс может быть просто именем сценария и аргументами этого сценария. Вы можете сделать так, чтобы клиенты возвращали статус работы. Если задания не удались, вы можете повторить их. Вы можете сделать так, чтобы клиенты опрашивали задания каждую минуту (или каждые x секунд и заставляли сервер сортировать задания)

PHP будет работать для сервера.

MySQL отлично подойдет для базы данных. Я бы просто сделал две отметки времени: начало и конец. На сервере я бы поискал WHEN SECONDS == 0

Gearman кажется идеальным кандидатом для этого сценария. Возможно, вы даже захотите виртуализировать свои машины Windows для нескольких рабочих узлов на каждой машине, в зависимости от того, сколько вычислительной мощности вам нужно.

Кроме того, система постоянной очереди в gearman предотвращает потерю заданий при выходе из строя рабочего или сервера gearman. После перезапуска службы очередь просто продолжается с того места, где она была остановлена ​​до сбоя / перезагрузки, вам не нужно заботиться обо всем этом в своем приложении, и это большое преимущество и экономия времени / кода

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

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

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

Также это звучит как задание для организации очереди! Если бы вы были в мире Java, я бы порекомендовал вам архитектуру на основе JMS. Существует проект 'dropr', чтобы делать что-то подобное на php, но он все довольно новый, поэтому он может не подходить для вашего проекта.

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

Вместо того, чтобы заново изобретать колесо очередей через SQL, вы могли бы использовать систему обмена сообщениями, такую ​​как RabbitMQ или ActiveMQ , в качестве ядра вашей системы. Каждая из этих систем поддерживает протокол AMQP и имеет очереди на жестком диске. На сервере у вас есть одно приложение, которое помещает новые задания в «рабочую» очередь в соответствии с вашим расписанием, а другое, которое записывает результаты из очереди «результатов» в базу данных (или действует с ней каким-либо другим способом).

рабочие подключаются к RabbitMQ или ActiveMQ. Они извлекают работу из очереди работ, выполняют ее и помещают ответ в другую очередь. После того, как они это сделали, они ПОДТВЕРЖДАЮТ исходный запрос о работе, чтобы сказать «готово». Если воркер разрывает соединение, задание будет восстановлено в очереди, чтобы его мог выполнить другой исполнитель.

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

Настройка мастера сервер и несколько рабочих выглядят правильно в вашем случае.

На главном сервере я бы установил MySQL (Percona InnoDB версия стабильная и быстрая ) в режиме репликации мастер-мастер, так что у вас не будет единственная точка отказа. На главном сервере будет размещен API, который рабочие будут извлекать каждые N секунд. Мастер проверит, доступно ли задание, если да, он должен отметить, что задание было назначено работнику X, и вернуть соответствующий ввод работнику (все это через HTTP). Кроме того, здесь вы можете хранить все файлы скриптов рабочих.

На рабочих я настоятельно рекомендую вам установить дистрибутив Linux. В Linux проще настраивать задачи по расписанию, и в целом я думаю, что это больше подходит для работы. С Linux вы даже можете создать live cd или iso-образ с идеально настроенным worker-ом и быстро и легко установить его на все нужные вам машины. Затем настройте задание cron, которое будет выполнять RSync с главным сервером для обновления / изменения скриптов. Таким образом вы измените файлы только в одном месте (на главном сервере), и все рабочие будут получать обновления.

В этой конфигурации вам не важны IP-адреса или количество рабочих, потому что рабочие подключаются к мастеру, а не наоборот.

Работа исполнителя довольно проста: запросить задание у API, выполнить его, отправить обратно результат через API. Промыть и повторить: -)