Elixirs Job-Verarbeitungs-Framework Oban wird nach Python portiert

 (dimamik.com)
3 Punkte von GN⁺ 2026-01-30 | 1 Kommentare | Auf WhatsApp teilen
  • Oban.py ist eine auf PostgreSQL basierende Portierung von Elixirs Job-Verarbeitungs-Framework Oban nach Python, mit der Jobs allein über die Datenbank eingefügt und verarbeitet werden können
  • Jobs werden innerhalb von Datenbanktransaktionen erstellt und zurückgerollt; unterstützt werden unter anderem Queue-Management, Ergebnisspeicherung und Cron-Scheduling
  • Die Open-Source-Version hat Einschränkungen wie Single-Thread-asyncio-Ausführung und individuelles Einfügen und Bestätigen, während die Pro-Version Parallelverarbeitung, Workflows und Smart Concurrency bietet
  • Der interne Ablauf besteht aus fünf Schritten: Insert → Notify → Fetch → Execute → Ack; dabei wird PostgreSQLs FOR UPDATE SKIP LOCKED genutzt, um Konflikte bei der Parallelität zu vermeiden
  • Leader Election, Wiederherstellung verwaister Jobs und Backoff-Retries werden ebenfalls datenbankbasiert ausgeführt und ermöglichen so eine stabile verteilte Verarbeitung ohne externen Broker

Überblick über Oban.py

  • Oban.py ist eine nach Python portierte, datenbankbasierte Job-Verarbeitungs-Framework-Variante von Elixirs Oban
    • Jobs werden innerhalb von Datenbanktransaktionen eingefügt und verarbeitet; bei Fehlern wird die gesamte Transaktion zurückgerollt
    • Enthält verschiedene Steuerungsfunktionen wie Queue-Limits, Speicherung abgeschlossener Jobs, Ergebnisaufbewahrung und Cron-Scheduling
  • Es gibt zwei Versionen
    • Open Source (OSS): Single-Thread-asyncio-Ausführung, individuelles Einfügen und Bestätigen, einfache Wiederherstellung
    • Pro-Version: Parallelverarbeitung auf Basis eines Prozesspools, Unterstützung für Workflows, Relays, Unique Jobs und Smart Concurrency
  • OSS eignet sich für persönliche Projekte oder Evaluierungen, für große Umgebungen wird die Pro-Version empfohlen

Pfad der Job-Verarbeitung

  • Nach dem Einfügen werden Jobs in der Tabelle oban_jobs mit state='available' gespeichert, und per PostgreSQL-NOTIFY wird eine Benachrichtigung an jeden Knoten gesendet
  • Der Stager jedes Knotens erkennt die betreffende Queue und weckt den Producer auf, der die Jobs abholt und ausführt
  • Bei der Job-Auswahl wird SQLs FOR UPDATE SKIP LOCKED verwendet, um parallele Verarbeitung ohne doppelte Ausführung zu ermöglichen
    • Bereits gesperrte Zeilen werden übersprungen, sodass andere Producer sofort andere Jobs holen können
  • Jobs werden als Async-Tasks dispatcht; nach Abschluss erfolgt die Acknowledgement-Verarbeitung per Callback
  • Die Pro-Version verwendet statt asyncio einen Prozesspool-Dispatcher und unterstützt so parallele Ausführung über mehrere CPU-Kerne

Hintergrundprozesse

  • Leader Election
    • Der Leader wird über PostgreSQLs INSERT ... ON CONFLICT und ein lease-basiertes TTL-Verfahren bestimmt
    • Ohne separates Konsensprotokoll übernimmt ein einzelner Leader das Aufräumen und Wiederherstellen von Jobs
  • Lifeline (Wiederherstellung verwaister Jobs)
    • Läuft ein Job länger als eine bestimmte Zeit (rescue_after, standardmäßig 5 Minuten), wird er in den Status available zurückversetzt
    • Die Pro-Version prüft, ob der Producer noch lebt, OSS entscheidet nur zeitbasiert
  • Pruner (Job-Bereinigung)
    • Löscht abgeschlossene, abgebrochene oder verworfene Jobs, deren max_age (standardmäßig 1 Tag) überschritten ist
    • Begrenzt den Löschumfang mit LIMIT, um Datenbanklast zu vermeiden

Retries und Backoff

  • Wenn ein Job eine Ausnahme auslöst, entscheidet der Executor, ob ein Retry erfolgt
    • Liegt die Zahl unter der maximalen Anzahl an Versuchen (max_attempts), wird erneut versucht, andernfalls wird der Job verworfen
  • Der Standard-Backoff ist ein exponentieller Anstieg mit Jitter
    • Verhindert bei vielen Fehlschlägen gleichzeitige Retries und mildert so Lastspitzen durch den Thundering Herd
    • Beispiel: ca. 17 Sekunden beim 1. Versuch, ca. 47 Sekunden beim 5. Versuch, ca. 17 Minuten beim 10. Versuch
  • Worker-Klassen können über die Methode backoff() eine benutzerdefinierte Backoff-Logik implementieren

Wichtige Merkmale und Bewertung

  • PostgreSQL übernimmt die Schlüsselrolle
    • Über FOR UPDATE SKIP LOCKED, LISTEN/NOTIFY und ON CONFLICT werden Parallelitätskontrolle, Signalisierung und Leader Election vollständig umgesetzt
    • Statt Redis oder eines externen Brokers wird eine einzelne Datenbank als Koordinationsschicht genutzt
  • Nicht parallel, aber nebenläufig
    • Auf asyncio basierend und damit gut für I/O-bound Workloads geeignet; für CPU-bound Aufgaben wird die Pro-Version empfohlen
  • Klare Code-Struktur
    • Konsistente Benennung und sauber getrennte Verantwortlichkeiten sorgen für eine gut lesbare Codebasis
  • Klare Rollentrennung zwischen OSS und Pro
    • OSS für Experimente und kleinere Einsätze, Pro für große Umgebungen und hohe Performance
  • Fazit: Eine saubere und strukturiert umgesetzte Python-Portierung, die allein mit PostgreSQL eine vollständige Job-Queue implementiert, und geeignet ist für Elixir-Nutzer oder Entwickler, die ein Job-System ohne externe Infrastruktur suchen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-30
Hacker-News-Kommentare

  • Ich bin der Entwickler von Sidekiq und gratuliere Shannon und Parker zu ihrem Release.
    Früher stand ich vor derselben Frage — mich auf Ruby konzentrieren oder Sidekiq auf andere Sprachen ausweiten. Ich habe erkannt, dass ich unmöglich Experte für jede Sprache sein kann, und stattdessen Faktory gebaut. Dabei verwaltet ein zentraler Server den Lebenszyklus der Queue, während die Clients pro Sprache einfach bleiben. Es gibt zum Beispiel Clients wie faktory-rs. Der Nachteil ist, dass man sich nicht auf eine bestimmte Sprach-Community konzentriert und deshalb schwerer sprachspezifische Beispiele liefern kann.
    Ein fokussierter Ansatz auf eine einzelne Community könnte am Ende bessere Ergebnisse liefern. Die Zeit wird es zeigen

    • Danke, Mike! Du bist wirklich eine Quelle der Inspiration. Parker und ich haben unterschiedliche Stärken, und wir glauben an die Synergie, die aus der Interoperabilität zwischen Python und Elixir entsteht
    • Faktory war eine große Inspiration für mein sprachunabhängiges Job-Queue-System Ocypod. Danke, dass du es als Open Source veröffentlicht hast
    • Ist es nicht eigentlich treffender zu sagen, dass beide auf Resque basieren?
    • Auch wenn es vielleicht nicht so gemeint war, wirkt dein Kommentar ein bisschen wie Werbung für dein Projekt. Das kommt hier nicht besonders gut an
    • Die Formulierung „based on“ wirkt etwas übertrieben. Sidekiq ist viel einfacher im Vergleich zu den Workflows, Cron, Partitionierung, abhängigen Jobs und der Fehlerbehandlung, die Oban unterstützt

  • Der Kern von Oban ist, dass Jobs nur mit der Datenbank eingefügt und verarbeitet werden können. Man kann innerhalb einer Transaktion zur Benutzererstellung auch gleich einen E-Mail-Versand-Job einfügen, und wenn etwas fehlschlägt, wird alles zusammen zurückgerollt.
    Viele sagen, man solle keine relationale DB als Job-Queue verwenden, übersehen dabei aber die Bedeutung von Transaktionen. Brandur Leachs Artikel Job Drain erklärt dieses Konzept ebenfalls sehr gut

    • Dem stimme ich sehr zu. Ich habe jahrelang gesehen, wie wegen des Dual Write Problem Events verloren gingen. Als wir am Ende wieder zu einem SQL-basierten Ansatz zurückgekehrt sind, war das Problem innerhalb eines Tages gelöst.
      Inzwischen erinnert sich aber niemand mehr an diesen Schmerz. Das „transactional outbox pattern“ ist unverzichtbar, und ich bevorzuge einen Ansatz mit denselben ACID-Garantien wie meine Daten.
      Selbst ohne tiefes DB-Interna-Wissen spart eine Woche, die man in Isolation Levels und Commit-Reihenfolge investiert, einem ein Jahr Debugging in verteilten Systemen
    • Genau das nennt man das transactional outbox pattern
    • Ich finde diese Funktion auch wirklich großartig. Ich verwende stattdessen pg_timetable
    • Wir bauen einen KI-basierten App-Builder und nutzen Elixir, Phoenix und natürlich OBAN.
      In einer Zeit mit vielen langen KI-Prozessen ist solche Durability unverzichtbar. In anderen Sprachökosystemen zahlt man für so etwas, bei Oban ist es standardmäßig dabei
    • So habe ich noch nie über Transaktionen nachgedacht, wirklich beeindruckend

  • Das Oban-Team ist im Elixir-Ökosystem für ausgereifte Engineering-Arbeit bekannt. Es ist aber verwirrend, dass sie im Pro-Modell den Prozess-Pool eingeschränkt haben.
    Der Tarif für 135 $/Monat enthält zum Beispiel Multi-Process-Ausführung, Workflows, globale Limits, Unique Jobs, Bulk-Jobs, verschlüsselte Quellen und dedizierten Support.
    Mein Projekt Chancy ist komplett kostenlos, und man kann asyncio, Prozesse, Threads und Sub-Interpreter frei kombinieren.
    Ich frage mich, ob es nicht besser wäre, solche Funktionen ins OSS zu übernehmen und das kostenpflichtige Angebot stärker auf Enterprise-Support auszurichten. Im Python-Ökosystem gibt es deutlich mehr Konkurrenz

    • Je nach Interesse und Nutzung könnten einige Funktionen ins OSS wandern. In Elixir haben wir das schon einmal so gemacht.
      Ein Modell, das nur Support verkauft, hat bei uns nicht besonders gut funktioniert, aber in Python könnte das anders sein.
      Im Python-Ökosystem gibt es wirklich alles in Hülle und Fülle
    • Zur Einordnung: In Django 6.0 wurde die Django Tasks API hinzugefügt, mit austauschbarem Backend, aber es gibt noch kein wirklich produktionsreifes Backend.
      Wenn du Support für Django Tasks in Chancy ergänzen oder ein Paket django-chancy bauen würdest, könnte das schnell Akzeptanz finden
    • Danke fürs Teilen von Chancy. Sieht interessant aus. Abgesehen von API-Änderungen: Lässt es sich schon jetzt stabil in Produktion einsetzen?

  • OSS Oban unterstützt nur single-threaded asyncio execution, daher blockieren CPU-bound Jobs den Event Loop.
    Deshalb hatte ich das Gefühl, dass es einen Versuch nicht wert ist. Das Celery-Interface gefällt mir zwar nicht besonders, aber es ist vertraut und lässt sich vertikal wie horizontal praktisch unbegrenzt skalieren.
    Allerdings hat sich meine Meinung etwas geändert, seit ich weiß, dass man mehrere Worker-Nodes starten kann

  • Die Trennung zwischen OSS- und Pro-Funktionen ist okay, aber „Die Pro-Version verfolgt das Überleben des Producers mit intelligenteren Heartbeats“ ist enttäuschend.
    Wenn zuverlässigkeitsrelevante Funktionen kostenpflichtig sind, wird das die Einführung in OSS-Projekten erschweren

    • Sehe ich genauso. Oban ist großartig, aber es ist schade, wenn die „bessere Version derselben Funktion“ kostenpflichtig ist.
      Die Basisversion sollte die beste sein, und Zusatzfunktionen sollten kostenpflichtig sein. Die Grenze wirkt an einer etwas seltsamen Stelle gezogen
    • Redis- oder RabbitMQ-basierte Queues können nach einem unerwarteten Shutdown ebenfalls Jobs verlieren.
      Der zitierte Satz ist leicht ungenau — das Tracking des Producer-Lebenszyklus ist identisch, der Unterschied liegt nur in der Wiederherstellung verwaister Jobs

  • Ich wünschte, Python-Workflows für BI/ML/DS würden nach Elixir wechseln.
    Ich halte Elixir mit seiner funktionalen, fehlertoleranten und hochgradig nebenläufigen Natur für eine viel natürlichere Grundlage für solche Aufgaben

  • Wir verwenden bei uns ebenfalls Celery, und so toll ist es nicht. Temporal ist zu schwergewichtig, Oban wirkt dagegen leicht und sympathisch.
    Mich würde ein Vergleich von jemandem interessieren, der beides verwendet hat

    • Die beiden Tools haben völlig unterschiedliche Philosophien.
      Temporal passt zu Organisationen, die Workflow-Garantien brauchen und die Komplexität akzeptieren können, etwa Banken.
      Oban ist eine DB-basierte Queue, deren Zuverlässigkeit man selbst weiter absichern muss.
      Ich finde, beide haben ihren Platz, sogar im selben System
    • Wir sind von Celery zu Prefect gewechselt und zufrieden damit. Für Workloads im Tausenderbereich ist es perfekt.
      Wir nutzen eine Kombination aus einfachem ProcessWorker und ECS-Workern
    • Ich bin nach langer Zeit wieder zur Python-Webentwicklung zurückgekehrt und war überrascht, wie viel Unzufriedenheit es mit Celery gibt.
      Ich frage mich, ob Celery in letzter Zeit weniger stabil oder schwieriger zu handhaben geworden ist

  • Interessantes Projekt. Auffällig ist nur, dass einige Kernfunktionen nur in Pro enthalten sind.
    Frühere Projekte, die Postgres-basierte Durable Workflows als OSS umgesetzt haben, sind DBOS und Absurd.
    Es ist erfreulich, mehr datenbankzentrierte Ansätze zu sehen

    • Auch in Elixir gab es ein ähnliches OSS-Projekt, und Obans Implementierung von Durable Workflows war einige Jahre vor DBOS da.
      Ein vollständig Open-Source-basiertes Modell, das sich allein über Support-Verkauf trägt, ist ein Traummodell. Hoffentlich ist es irgendwann möglich

  • Ich frage mich, ob Postgres genug Performance hat, um Hunderte Millionen Jobs zu verarbeiten. Früher habe ich beim Wechsel auf Redis + Sidekiq große Leistungsgewinne gesehen

    • Mich würde interessieren, über welchen Zeitraum wir sprechen. Ich verarbeite mit Rails/Solid Queue + Postgres 20 Millionen Jobs pro Tag auf einer 45-$-VM und habe noch reichlich Luft nach oben

  • Bei der OSS-Version heißt es, lange laufende Jobs könnten fälschlich wiederhergestellt werden, selbst wenn der Producer noch lebt.
    Bedeutet das, dass man nur kurze Jobs verwenden sollte?

    • Es gibt keine Begrenzung für die Job-Länge. Der Unterschied betrifft nur die Geschwindigkeit der Wiederherstellung nach einem Absturz.
      Das Timing der Wiederherstellung unterscheidet sich nur in Fällen, in denen nicht auf ein normales Herunterfahren gewartet werden konnte