ElasticJob 3.0.5: Verteilte Planung mit ZooKeeper und Sharding
Verteilter geplanter Job. ElasticJob wurde am 28. Mai 2020 ein Apache ShardingSphere-Unterprojekt.
Auf einen Blick
- Was ist das?
- ElasticJob verteilt geplante Aufgaben über mehrere Knoten und teilt sie in Stücke auf. Wir prüfen die Funktionsliste der README, die Pflicht zu ZooKeeper 3.6.0 und die offene Baustelle Job Dependency.
- Für wen ist es gedacht?
- ElasticJob passt zu Java-Teams, die geplante Aufgaben über mehrere Knoten verteilen und in Stücke zerlegen wollen und bereits ZooKeeper betreiben. Weniger geeignet ist es für Vorhaben ohne ZooKeeper oder mit Bedarf an Abhängigkeiten zwischen Aufgaben, denn dieser Teil ist in der README als noch nicht umgesetzt gekennzeichnet.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 5 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Java, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
ElasticJob 3.0.5 als Unterprojekt von Apache ShardingSphere
Die README von apache/shardingsphere-elasticjob stellt das Projekt als verteilte Aufgabenplanung vor. Seit dem 28. Mai 2020 gehört ElasticJob als Unterprojekt zu Apache ShardingSphere. Der Anspruch ist in einem Satz zusammengefasst: Mit einer einzigen Aufgaben-Schnittstelle schreiben Entwickler ihren Code einmal und können ihn dann beliebig verteilen.
Die Metadaten ordnen das Vorhaben ein. Hauptsprache Java, Lizenz Apache-2.0, Standardzweig master, zuletzt gepusht am 7. Februar 2026. GitHub weist 8.210 Sterne, 3.246 Forks und 116 offene Issues aus.
Bei den Releases fällt eine Lücke auf. Auf 3.0.3 vom März 2023 folgte 3.0.4 im Oktober 2023, und das nächste Release 3.0.5 erschien erst am 7. Februar 2026. Zwischen zwei Veröffentlichungen liegen damit mehr als zwei Jahre. Für Sicherheitsfragen heißt das, dass man den Quellstand im Blick behalten muss, statt auf ein Update im Monatstakt zu hoffen.
Elastic Schedule, Resource Assign und Job Governance
Die Funktionsliste der README beginnt mit Elastic Schedule. Dazu zählen die Aufteilung einer Aufgabe in Stücke über verteilte Systeme, Hochverfügbarkeit und das Erweitern um weitere Knoten für mehr Durchsatz. Die Verarbeitungskapazität soll sich mit der Zuteilung von Ressourcen flexibel anpassen lassen.
Resource Assign beschreibt die Ausführung zum passenden Zeitpunkt auf zugewiesenen Ressourcen, die Zusammenfassung gleicher Aufgaben auf demselben Ausführungsknoten und das dynamische Hinzufügen von Ressourcen für neu zugewiesene Aufgaben.
Job Governance deckt Failover, die Behandlung versäumter Ausführungen sowie Selbstdiagnose und Erholung ab, wenn die verteilte Umgebung instabil wird. Diese drei Gruppen sind der Kern dessen, was man von einer verteilten Planung erwartet; wie zuverlässig Failover im Einzelfall greift, belegt die README nicht.
ZooKeeper 3.6.0 als Pflicht und das Maven-Artefakt elasticjob
Im Abschnitt Environment Required wird das Projekt ungewöhnlich konkret. Verlangt werden Java 8 oder höher, Maven 3.5.0 oder höher und ZooKeeper 3.6.0 oder höher, mit Verweis auf die Projektseite von ZooKeeper.
Diese drei Angaben sind die harten Abhängigkeiten und zugleich die erste Hürde. Ein Koordinationsdienst wie ZooKeeper will betrieben, überwacht und gesichert werden. Wer ihn nicht schon hat, führt mit ElasticJob einen weiteren Staatsdienst ein, nicht nur eine Bibliothek.
Als Maven-Artefakt führt das Repository die Koordinate org.apache.shardingsphere.elasticjob für das Modul elasticjob, die sich aus dem Verweis auf Maven Central ergibt. Konkrete Einstellungen für Sharding-Zahlen oder Cron-Ausdrücke nennt die README im verfügbaren Abschnitt nicht; sie liegen auf shardingsphere.apache.org/elasticjob.
Das Job-Ökosystem mit dataflow, script, HTTP und file
Unter Job Open Ecosystem listet die README eine einheitliche Aufgaben-Schnittstelle für Erweiterungen und eine Bibliothek mit Aufgabentypen. Genannt werden dataflow, script, HTTP, file und big data. Zudem ist von einem Geschäfts-SDK die Rede, das mit Spring IOC zusammenarbeitet.
Diese Aufzählung bestimmt, wie viel eigener Code nötig ist. Ein script-Aufgabentyp erlaubt es, vorhandene Skripte ohne Java-Kenntnisse einzubinden, während dataflow auf strömende Datenverarbeitung zielt. Wer eine andere Form braucht, erweitert die Schnittstelle.
Wie umfangreich die mitgelieferten Typen sind und welche Konfigurationsschlüssel sie erwarten, steht im Material nicht. Für eine erste Prüfung ist deshalb entscheidend, ob der eigene Anwendungsfall einem der fünf genannten Typen entspricht.
Die Admin-Konsole im Repository shardingsphere-elasticjob-ui
Für die Verwaltung verweist die README auf ein eigenes Repository namens apache/shardingsphere-elasticjob-ui. Genannt werden drei Aufgaben dieser Konsole: Verwaltung von Aufgaben, Abfrage der Aufgabenereignisse und Verwaltung des Registry Centers.
Die Trennung in ein eigenes Repository hat Folgen. Die Oberfläche folgt einem anderen Release-Takt als die Bibliothek und muss separat installiert werden. Wer Version 3.0.5 der Bibliothek einsetzt, muss prüfen, welcher Stand der Konsole dazu passt.
Für den Betrieb ist die Ereignisabfrage der nützlichste Teil, weil sich daraus nachvollziehen lässt, wann eine Aufgabe gelaufen ist und wo sie hängen blieb. Ob die Konsole eine deutschsprachige Oberfläche bietet, ist im Material nicht angegeben.
Job Dependency bleibt offen, Quartz als Alternative
Der aufschlussreichste Eintrag der Funktionsliste steht unter Job Dependency. Die README kennzeichnet diesen Bereich als noch nicht umgesetzt und beschreibt als Ziel Abhängigkeiten zwischen Aufgaben sowie zwischen Aufgabenstücken auf Basis eines gerichteten azyklischen Graphen. Wer also Aufgabenketten plant, findet diese Fähigkeit im heutigen Stand nicht.
Als Alternative für einfache Zeitplanung bietet sich Quartz an. Die Bibliothek läuft in einer Java-Anwendung, speichert ihren Zustand wahlweise in einer relationalen Datenbank und benötigt keine Koordinationsschicht. Dafür teilt sie eine Aufgabe nicht selbsttätig in Stücke über Knoten hinweg auf; diese Verteilung müsste man selbst bauen.
Wer Aufgabenketten braucht, ist bei Apache DolphinScheduler besser aufgehoben, das Abläufe als Graphen abbildet. ElasticJob lohnt sich vor allem dort, wo eine einzelne Aufgabe in viele gleichartige Stücke zerfällt, etwa bei der Abarbeitung einer großen Tabelle. Rechtlich gilt Apache License 2.0, Kontakt läuft über dev@shardingsphere.apache.org.
Redaktionelles Fazit
ElasticJob passt zu Java-Teams, die geplante Aufgaben über mehrere Knoten verteilen und in Stücke zerlegen wollen und bereits ZooKeeper betreiben. Weniger geeignet ist es für Vorhaben ohne ZooKeeper oder mit Bedarf an Abhängigkeiten zwischen Aufgaben, denn dieser Teil ist in der README als noch nicht umgesetzt gekennzeichnet. Vor einer Entscheidung sollte geprüft werden, ob ein ZooKeeper-Ensemble ab 3.6.0 bereitsteht und ob die Aufgabentypen der mitgelieferten Bibliothek den eigenen Fall abdecken, etwa dataflow, script oder HTTP.
Community-Notizen