Open-Source-Java-Lösung zum Verteilen von Jobs und Starten mehrerer JVM-Worker

Tor

Ich suche nach einer Open-Source-Java-Lösung, die in einem kleinen (2-4) Cluster von Linux-Rechnern verwendet werden kann. Sie können sich das wie eine Farm von Worker-Servern vorstellen, die nur eine Nachricht von einem JMS-Endpunkt abhören, um mit der Verarbeitung zu beginnen.

Anforderungen

Diese Bibliothek/Lösung/was auch immer muss in der Lage sein, etwa 10 bis 20 Prozesse auf jeder Maschine aus dem Cluster auszulösen (jede ist eine JVM). Jeder Prozess verarbeitet eine Nachricht von einer zentralisierten JMS-Instanz und speichert die Jobergebnisse in einer zentralisierten DBMS-Instanz. Jeder Prozess dauert mehrere Minuten (5 bis 50 Minuten) und hat wenig Platzbedarf in Bezug auf Netzwerk, Festplatten-E/A, CPU und Speichernutzung. Jeder Arbeitsplatz ist unabhängig. Die Bibliothek muss lediglich dabei helfen, diese Zuweisung/Aufhebung der Zuweisung von JVM-Prozessen zu verwalten und einige minimale Statistiken und Kontrolle bereitzustellen. Es ist nicht erforderlich, Jobs anzuhalten/fortzusetzen/abzubrechen. Ich muss nur wissen, wann sie ausgeführt werden oder nicht und ob sie erfolgreich abgeschlossen wurden oder nicht. Es ist kein Problem, Worker-Server im Leerlauf zu halten.

Wichtig : Ich suche weder PaaS noch eine Cloud-basierte Lösung.

Was weiß ich

Anfangs habe ich überlegt, einfach ein paar Tomcat-Instanzen zu starten, aber es scheint übertrieben zu sein, und ich müsste jedem von ihnen unterschiedliche Ports zur Verfügung stellen. Es ist kein Teile-und-Herrsche-Problem, also suche ich nicht nach Kartenreduzierungslösungen. Es ist auch nicht etwas, das mit Hadoop gelöst werden kann (glaube ich). Aber ich gestehe, ich weiß wenig über diese Art von Lösungen. Ich habe ein wenig über JavaSpaces und RMI gelesen, aber es scheint, dass dies Bausteine ​​​​für verteilte Lösungen sind. Ich habe auch von Microservices gehört, aber sie sehen einfach nach etwas Nützlicherem für die Orchestrierung verschiedener Teile eines ganzen Prozesses aus. Ich habe auch Memcache, Hazelcast, Terracota überprüft, aber sie sollen eine andere Klasse von Problemen lösen.

Mein Gefühl

ist, dass dies ein bekanntes Problem mit mehreren interessanten Lösungen ist, aber ich weiß einfach nicht genau, wie es heißt (und dann kann ich es nicht richtig googeln).

Versuchen Apache YARN, Mesos etc. nicht genau dies (und ein bisschen mehr: Ressourcenzuweisung zu verwalten)?
@Anony-Mousse wird sich das ansehen, danke für den Hinweis!

Antworten (2)

Ich kenne keine fertige Lösung für dieses Problem (und keinen ausgefallenen Namen), würde es aber lieber selbst einrichten (in Java). Auch meine JMS-Kenntnisse sind "in Entwicklung", daher gibt es möglicherweise bessere Lösungen, die die Teile 1 und 2 kombinieren. Und ich bin mir nicht ganz sicher, ob ich dein Problem richtig verstanden habe.

Ich gehe davon aus, dass die Mitarbeiter ihre Datenbankverbindungen selbst handhaben, daher werde ich dies nicht berücksichtigen.

Erster Teil: Der Verteiler - Eine nachrichtengesteuerte Bean, die Ihre JMS-Nachrichten verarbeitet und verarbeitet. Da Sie nicht auf allen Rechnern einen Anwendungsserver haben möchten, benötigen Sie jetzt nur noch einen.

Zweiter Teil: Der Frontworker - Ein Java-Programm, das auf jeder Maschine läuft und einen Port für die Kommunikation vom Verteiler offen hält. Sie brauchen ein Austauschformat, RMI ist meiner Erfahrung nach die direkteste Lösung dafür.

Dritter Teil: Der Arbeiter - Beginnt durch den Frontarbeiter. Sie sind auf der gleichen Maschine, also, meh. Alle Informationen, die der Worker benötigt, werden vom Frontworker auf irgendeine Weise bereitgestellt (Datenbank, Konsole, Datei, was auch immer). Die Worker fügen sie in die Datenbank ein, wenn sie gestartet, gestoppt und fehlgeschlagen sind.

Letzter Teil: Der Monitor - liest die Datenbank. Die Daten werden mit einer einfachen Tabelle angezeigt. Ausgefallene Berichte vielleicht über JasperReports.

Der Datenfluss würde so aussehen: Der JMS-Datenanbieter sendet seine Nachrichten, die vom Verteiler konsumiert werden. Der Verteiler prüft optional, auf welchem ​​Server derzeit die wenigsten Worker laufen, oder führt nur einen Round-Robin durch. Es öffnet dann die RMI-Verbindung zum Frontworker auf diesem speziellen Server und übergibt die JMS-Informationen. Der Frontworker startet einen Arbeitsprozess mit den Informationen. Jeder Werker gibt unabhängig voneinander seine Daten in die Datenbank ein.

Der Monitor würde unabhängig davon verwendet werden und nur die Datenbank der Arbeit der Arbeiter lesen.

Hallo Angelo, es macht sehr viel Sinn. Nach einigen Recherchen denke ich, dass ich eine solche Strategie anwenden werde, aber den Verteiler und den Frontworker zusammenführen, weil der Frontworker direkt aus dem JMS lesen kann. Der Teil, der mich besonders an Ihrer Idee interessiert, ist, wie der Frontworker den Worker beginnen würde. ProcessBuilder? Danke für Ihre Hilfe.

Ich würde dafür den Quartz-Scheduler verwenden .

Ich habe es in der Vergangenheit erfolgreich verwendet, und anscheinend hat es einen Cluster-Modus (den ich nicht ausprobiert habe). Es führt Lastenausgleich durch und kann jede JDBC-Datenbank für die Koordination verwenden.

Es ist Open Source und in Java geschrieben.