Übersicht geeigneter Job-Scheduler-Frameworks
| Framework | Sprache | Kubernetes-Kompatibilität | Unterstützte Features (Exklusivität, Parallelität, Abhängigkeiten, Priorität, Retry, Ausfallsicherheit) | Reifegrad / Community / Doku |
|---|---|---|---|---|
| Quartz Scheduler | Java | Ja (Cluster-Betrieb mit JDBC-Jobstore ermöglicht auf K8s) | Exklusivität: Kann parallel laufende Instanzen desselben Jobs verhindern (z.B. via DisallowConcurrentExecution). Keine eingebaute globale Mutex für unterschiedliche Jobs. Parallelität: Thread-Pool steuert gleichzeitige Jobs; Cluster-Modus für Lastverteilung und Failover. Abhängigkeiten: Über Trigger-Ketten oder Listener realisierbar (keine native DAG-Unterstützung, aber Jobs können nach Reihenfolge getriggert werden). Priorität: Trigger-Prioritäten beeinflussen die Ausführungsreihenfolge von Jobs. Retry: Kein automatisches Retry – Fehlerbehandlung muss manuell erfolgen (Jobs können erneut eingeplant werden). Ausfallsicherheit: Persistenter JDBC-Jobstore stellt sicher, dass Jobs bei Neustart/Failover nicht verloren gehen. | Sehr ausgereift (seit ~2001); große Community und breite Nutzung in Produktionsumgebungen; umfangreiche Dokumentation und Tutorials verfügbar. |
| JobRunr (Open Source + Pro) | Java | Ja (für verteilte Umgebungen entworfen, läuft z.B. auf mehreren K8s-Pods) | Exklusivität: Unterstützt Mutexe, um Jobs wechselseitig zu sperren (nur 1 Job pro Mutex gleichzeitig) (Pro). Parallelität: Verteilte Worker und Thread-Pools – Jobs laufen auf beliebigem freien Knoten/Worker. Abhängigkeiten: Job-Chaining ermöglicht sequentielle Ausführung abhängiger Tasks (Workflows) (Pro). Priorität: Mehrere Prioritäts-Queues vorhanden – high-priority Jobs werden vor anderen ausgeführt (Pro). Retry: Automatische Wiederholungen bei Fehlschlägen sind eingebaut (konfigurierbar, z.B. Default-Retries). Ausfallsicherheit: Jobs werden in einer Datenbank persistiert; bei Absturz gehen keine Jobs verloren, Failover über mehrere Knoten möglich. | Relativ jung (seit ca. 2020), aber aktiv weiterentwickelt. Wachsende Community und klare Dokumentation; Produktiv bei diversen Unternehmen im Einsatz. Pro-Version bietet zusätzlichen Support und erweiterte Features. |
| Netflix Conductor | Java (Server) | Ja (läuft als Microservice-Engine in Containern auf K8s) | Exklusivität: Keine direkte Mutex-Funktion, aber einzelne Tasks können durch Workflow-Logik exklusiv geplant werden (z.B. serialisierte Ausführung in Workflows). Parallelität: Horizontale Skalierung mit mehreren Worker-Instanzen; mehrere Tasks eines Workflows können parallel ausgeführt werden, sofern definiert. Abhängigkeiten: Volle Workflow-Orchestrierung (DAG-/Flow-Definition); Tasks werden mit Abhängigkeiten in JSON/YAML Workflows definiert. Priorität: Standardmäßig FIFO-Queues. (Task-Prioritäten sind nicht offiziell unterstützt – es gibt jedoch Ansätze mit separaten Warteschlangen). Retry: Eingebaute Fehlertoleranz mit konfigurierbaren Retry-Mechanismen pro Task (z.B. automatische Wiederholungen, Fehler-Workflows). Ausfallsicherheit: Hochverfügbar und fehlertolerant – erkennt Fehlschläge und übernimmt Recovery automatisch. Persistente Speicherung der Workflows (z.B. in Redis/DB) verhindert Datenverlust. | Open Source seit 2017 (Netflix); in Produktion erprobt bei Netflix & anderen. Aktive Weiterentwicklung durch Community/Orkes. Gute Dokumentation und Web-UI für Monitoring vorhanden. |
| Temporal (früher Uber Cadence) | Java SDK (Temporal-Server in Go) | Ja (Temporal-Server clusterfähig auf K8s; Workers in beliebigen Umgebungen) | Exklusivität: Wird durch Workflow-Code kontrolliert (Workflows können z.B. Mutex-Logik implementieren, falls nötig – keine einfache globale Mutex-Einstellung out-of-the-box). Parallelität: Hohe Skalierbarkeit – viele Worker-Prozesse und Threads möglich; Workflow-Engine unterstützt massive Parallelität. Abhängigkeiten: Workflows werden in Code als sequenzielle oder parallele Aufrufe definiert – dadurch flexible Ablaufsteuerung (DAG) in Programmierlogik. Priorität: Keine native Prioritätssteuerung; allerdings können getrennte Task Queues mit unterschiedlicher Wichtigkeit genutzt werden als Workaround. Retry: Automatische Retries für Aktivitäten sind standardmäßig vorgesehen und konfigurierbar (Fehler werden idempotent gehandhabt). Ausfallsicherheit: Durable Execution – Workflow-State wird dauerhaft gespeichert, sodass selbst bei Ausfällen die Ausführung konsistent fortgesetzt wird. Temporal behandelt Persistenz und Fehlerfälle transparent (kein manueller Eingriff nötig). Workflows sind langlebig und verlieren keine Daten (starke Konsistenzgarantien). | Sehr ausgereift – basierend auf Uber’s Cadence, seit ~2013 in Produktion (über 8 Jahre bei Uber, Coinbase, etc. erprobt). Große Community, unterstützt von Temporal.io (MIT Open Source); ausführliche Dokumentation und SDKs (Java, Go, etc.) vorhanden. |
| SOS JobScheduler (JS7) | Java | Ja (plattformunabhängige Agents; Docker-Images verfügbar) | Exklusivität: Unterstützt Auftrags-Zugriffssperren durch zentrale Orchestrierung – Agents führen Jobs sequenziell oder parallel gemäß definierten Workflow-Regeln aus (z.B. Synchronisations-Punkte). Parallelität: Verteilte Ausführung über mehrere Agents mit Lastverteilung („job load sharing“); Parallelzweige in Workflows (Fork/Join) möglich. Abhängigkeiten: Unterstützt komplexe Workflows mit sequenzieller und paralleler Task-Abarbeitung, inkl. Verzweigungen und Synchronisation. Aufträge können als Workflows mit Bedingungen definiert werden. Priorität: Prioritäten sind nicht explizit dokumentiert – jedoch lassen sich unterschiedlich priorisierte Job-Queues bzw. unterschiedliche Scheduler-Instanzen nutzen. Fokus liegt auf zeit- und ablauforientierter Planung. Retry: Konfigurierbare Fehlerschritte und Wiederholungsversuche durch Workflow-Definition möglich (z.B. Error-Handling als Teil des Workflows). Ausfallsicherheit: Hohe Verfügbarkeit durch redundante Controller und persistente Datenhaltung (Datenbankunterstützung für Job-States); integriertes Fail-over, sodass bei Ausfall eines Controllers die Ausführung nicht verloren geht. | Enterprise-Workflow-Scheduler (Open Source) mit langer Entwicklung (SOS seit ~2005). Sehr umfangreich und stabil, mit Web-UI (JOC Cockpit) und REST-API. Aktive Nutzergemeinde, detaillierte Knowledge-Base und Dokumentation verfügbar. |
| evQueue | C++ (Engine) | Ja (Linux-basiert; Docker-Container für Deployment vorhanden) | Exklusivität: Zentrale Steuerung der Jobs – evQueue kann Ressourcen via Queues zuweisen, sodass z.B. bestimmte Tasks seriell auf einer Queue laufen (Mutex-ähnliche Steuerung pro Queue). Parallelität: Parallele Ausführung wird durch Queues Management ermöglicht – mehrere Warteschlangen erlauben gleichzeitige Tasks und Kontrolle der Ressourcen pro Queue. Abhängigkeiten: Unterstützt komplexes Task-Chaining/Workflows: Abhängigkeiten mit bedingten Verzweigungen, Schleifen und Verkettung von Ausgaben/Eingaben zwischen Tasks sind definierbar. Priorität: Tasks können durch Zuordnung zu unterschiedlichen Queues priorisiert werden; explizite Prioritätslevel sind im Tool selbst nicht hervorgehoben, aber verschiedene Warteschlangen lassen sich unterschiedlich behandeln (z.B. separate high-priority Queue). Retry: Möglichkeit zur Fehlerbehandlung via Workflow-Logik (z.B. bedingte Wiederholungsschleifen) – keine spezifische Angabe in der Doku zu automatischen Retries, aber Workflows können entsprechend konfiguriert werden. Ausfallsicherheit: Clustering & HA: Mehrere evQueue-Knoten können synchron laufen, inkl. Leader-Election für geplante Tasks (Cron). Dadurch keine Einzelpunkt-Ausfälle; state wird extern (z.B. in Git für Workflows) synchronisiert. | Moderat ausgereift (Open Source seit ~2017, letzte Updates ~2020). Kleineres Projekt mit Nischen-Community. Bietet Web-basiertes UI (React) für Monitoring und Workflow-Editor, Dokumentation (API, Tutorials) ist verfügbar. |