Распределение потоков Java по нескольким серверам?

Подводя итог: вы уже масштабировали, теперь хотите масштабировать. Из головы:

• terracotta: вы можете создать Java Queue, который будет автоматически распределяется по всему кластеру. В основном вы запускаете одно и то же приложение с несколькими потоками, читающими данные из очереди. Terracotta волшебным образом распределяет эту очередь, так что она ощущается как локальный объект.

• hazelcast — аналогичный подход к Terracotta, распределенные структуры данных и исполнители

• jms - отправить сообщение с заданием на очередь JMS (опять же очередь) и иметь несколько слушателей. Каждый слушатель является более или менее отдельным потоком. Слушатели могут быть установлены на разных машинах.

• hadoop – сопоставление/уменьшение фреймворка Java для упрощения масштабирования большие объемы данных. Обычно используется для обработки данных и агрегирования результатов.

Вы можете использовать JMS или Hazelcast (например, распределенный ExecutorService) для распределения работы между машинами.

Что бы я сделал в первую очередь, это посмотреть на улучшение ваших алгоритмов. Возможно, вы обнаружите, что можете работать в 2-4 раза быстрее, используя 4 машины, но вы можете повысить производительность в 10-1000 раз за счет профилирования производительности, рефакторинга и настройки, часто с меньшей сложностью.

В общем, использование очереди (например, RabbitMQ) для загрузки «заданий», а затем получение рабочих заданий из очереди для обработки — это наиболее масштабируемый шаблон, который не требует слишком много усилий для запуска и запуска.

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

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

Например, если задания привязаны к процессору, нет смысла запускать на одном устройстве больше потоков, чем у вас есть ядер для их запуска (-1 ядро, используемое для управления потоками).

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

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

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

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

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

Соедините компьютеры розетками. Каждый рабочий процесс может охватывать n+1 потоков, где n — это количество ядер ЦП на этой машине.