Как создать сервер, который распределяет рабочие блоки для клиентов?

Question

Мне нужно Java-приложение, которое должно управлять базой данных, чтобы распределять рабочие единицы своим клиентам.По сути, это сеточное приложение: база данных заполнена входными параметрами для клиентов, и все ее кортежи должны быть распределены среди клиентов, которые запрашивают.После того, как клиенты отправят свои результаты, и сервер соответствующим образом изменит базу данных (например, отметив вычисленные кортежи).
Теперь давайте предположим, что у меня есть база данных (SQLite или MySQL), заполненная кортежами, и что клиенты выполняют запрос для группывходные кортежи: я хочу, чтобы группа рабочих модулей отправлялась исключительно одному клиенту, поэтому мне нужно пометить их как «уже запрошенные другим клиентом».Если я запрашиваю базу данных для первого (например, 5) запросов, и в то же время другой клиент делает тот же запрос (в многопоточной серверной архитектуре и без какой-либо синхронизации), я думаю, что есть вероятность, что оба клиента получают одинаковые рабочие блоки,

Я представлял, что решения могут быть:
1) создать однопоточную серверную архитектуру (ServerSocket.accept () вызывается снова только после того, как был обработан предыдущий клиентский запрос, чтобы сервер эффективно работал)доступ только к клиенту одновременно)
2) в многопоточной архитектуре синхронизируйте операции запроса и блокировки кортежей, так что я получаю вид атомарности (эффективно сериализуя операции над базой данных)
3) использовать атомарные операции запроса к серверу базы данных (или файлу, в случае SQLite), но в этом случае мне нужна помощь, потому что я не знаю, как все происходит на самом деле ...

Однако я надеюсь, чтоВы поняли мою проблему: она очень похожа на seti @ home, который распределяет свои рабочие модули, но пересечение всех распределенных модулей по множеству клиентов является нулевым (теоретически).Мои нефункциональные потребности: язык Java, а база данных SQLite или MySQL.

Answer 1

Некоторые отзывы для каждого из ваших потенциальных решений ...

1) сделать однопоточный сервер архитектура (ServerSocket.accept () вызывается снова только после предыдущий запрос клиента был служил, так что сервер эффективно доступен только клиенту во время)

ServerSocket.accept() не позволит вам сделать это, вам может потребоваться другой тип синхронизации, чтобы позволить только одному потоку находиться в ситуации getting tuples. Это в основном приводит вас к вашим решениям (2).

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

Возможный, простой в реализации и общий способ решения проблемы. Единственная проблема заключается в том, насколько вы заботитесь о производительности, задержке и пропускной способности, потому что если у вас много таких клиентов и промежуток времени рабочих единиц очень мал, то клиенты могут в конечном итоге запереть 90% времени, чтобы получить «токен».

Возможное решение этой проблемы. Используйте хешированный дистрибутив для рабочих единиц. Допустим, у вас есть 500 рабочих единиц, которые будут распределены между 50 клиентами. Вы присваиваете идентификаторы своим рабочим единицам таким образом, чтобы вы, клиенты которых получали определенные рабочие единицы. В конце концов, вы можете назначить узлы с помощью простой операции модуля:

assigned_node_id = work_unit_id % number_of_working_nodes

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

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

По сути, это то же самое, что (2), но в случае, если вы сможете сделать это, что, я сомневаюсь, вы можете с помощью только SQL, вы в конечном итоге будете привязаны к некоторым специфическим особенностям вашей СУБД. Скорее всего, вам придется использовать некоторые нестандартные процедуры SQL для достижения этого решения. И это не решает проблемы, которые вы найдете в решении 2.

Summary

Решение 2 с большей вероятностью будет работать в 90% случаев, чем дольше задачи, тем лучше для этого решения. Если задачи очень короткие по времени, определенно используйте алгоритм, основанный на pre-allocation.

Решением 3 вы отказываетесь от мобильности и гибкости.

DRY: try some other Open Source systems ...

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

http://www.gridgain.com/

http://www.jppf.org/

Answer 2

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