У меня проблема, которая немного затрудняет попытку понять идеальное решение, и, чтобы лучше объяснить это, я расскажу о своем сценарии здесь.
У меня есть сервер, который получит заказы от нескольких клиентов. Каждый клиент будет представить набор повторяющихся задач, которые должны выполняться в определенных интервалы, например: клиент A выполняет задачу AA, который должен выполняться каждый минута между 2009-12-31 и 2010-12-31; так что если моя математика правильная что около 525 600 операций в год, учитывая больше клиентов и задач было бы невозможно разрешить серверу выполнять все эти задачи, поэтому я придумал идею рабочего машины. Сервер будет разработан на PHP.
Рабочие машины просто обычны дешево Компьютеры на базе Windows, которые я буду принимающей в моем доме или на моем рабочем месте, у каждого работника будет Подключение к Интернету (с динамическими IP-адресами) и ИБП, чтобы избежать перебоев в подаче электроэнергии. каждый работник также будет запрашивать сервер каждый 30 секунд или около того через вызовы веб-службы, выберите следующее незавершенное задание и обработайте его. Как только работа будет завершена, работник будет отправлять выходные данные на сервер и запрашивать новая работа и т.д. до бесконечности. Если необходимо масштабировать систему я должен просто создать нового работника и целая вещь должна работать бесперебойно. Рабочий клиент будет разработан в PHP или Python.
В любой момент времени мои клиенты должны быть возможность входа на сервер и проверки статус заданий, которые они заказывали.
Теперь вот где сложная часть пинает:
- Я должен быть в состоянии восстановить уже обработанные задачи, если для некоторых причина, по которой сервер не работает.
- Рабочие не зависят от клиента, один рабочий должен обрабатывать рабочие места для любое заданное количество клиентов.
У меня есть некоторые сомнения относительно общей структуры базы данных и какие технологии использовать.
Первоначально я подумал об использовании нескольких SQLite баз данных и , объединивших их всех на сервере, но я не могу понять, как я буду группировать клиенты для создания отчетов о работе.
Я никогда не работал ни с одной из следующих технологий: memcached, CouchDB, Hadoop и все подобное, но я бы как знать, подходит ли какая-либо из них для моей проблемы, и если да, которую вы рекомендуете для новичков, это "распределенные вычисления" (или эта параллель?), как я. Пожалуйста, имейте в виду, что у рабочих есть динамические IP-адреса.
Как я уже говорил, у меня также возникают проблемы с общим дизайном базы данных, отчасти потому, что я до сих пор не выбрал какую-либо конкретную СУБД R (D), но один из вопросов, который у меня есть, и я думаю, что он не агностик для СУБД я select относится к системе очередности. Если я предваряю все абсолютные метки времени для определенного задания и имею большой набор временных меток, выполните и отметьте их как завершенные в по возрастанию или мне нужно иметь более умную систему типа , когда модуль временной метки 60 == 0 → выполнить ". Проблема с этой" умной" системой заключается в том, что некоторые задания не будут выполняться по порядку, потому что некоторые рабочие могут ждать ничего, пока другие перегружены. Что вы предлагаете?
PS: Я не уверен, что заголовок и теги этого вопроса правильно отражают мою проблему и то, что я пытаюсь сделать; если нет, отредактируйте соответствующим образом.
Спасибо за ваш вклад!
@timdev:
- Вход будет очень маленькой строкой, кодированной JSON, вывод также будет строкой JSON, но немного больше (в порядке 1-5 КБ).
- Результат будет вычислен с использованием нескольких доступных ресурсов из Интернета, поэтому основным узким местом, вероятно, будет пропускная способность. Запись базы данных также может быть одной - в зависимости от СУБД R (D).
