Elixir का job processing framework Oban अब Python में पोर्ट किया गया

 (dimamik.com)
3 पॉइंट द्वारा GN⁺ 2026-01-30 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • Oban.py Elixir के job processing framework Oban का PostgreSQL-आधारित Python पोर्ट है, जिसमें केवल database के ज़रिए jobs insert और process किए जा सकते हैं
  • jobs database transaction के भीतर बनते और rollback होते हैं, और queue management, result storage, cron scheduling जैसी कई सुविधाओं को support करते हैं
  • open source version में single-threaded asyncio execution और individual insert/ack handling जैसी सीमाएँ हैं, जबकि Pro version parallel processing, workflows, smart concurrency प्रदान करता है
  • इसकी आंतरिक कार्यप्रणाली Insert → Notify → Fetch → Execute → Ack के पाँच चरणों में बनी है, और PostgreSQL के FOR UPDATE SKIP LOCKED का उपयोग करके concurrency conflicts से बचा जाता है
  • leader election, orphaned job recovery, backoff retries जैसी प्रक्रियाएँ भी database-आधारित हैं, जिससे external broker के बिना स्थिर distributed processing संभव होती है

Oban.py का अवलोकन

  • Oban.py Elixir के Oban का Python में पोर्ट किया गया database-आधारित job processing framework है
    • jobs को database transaction के भीतर insert और process किया जाता है, और failure होने पर पूरा transaction rollback हो जाता है
    • इसमें queue limits, completed job storage, result retention, cron scheduling जैसी कई control capabilities शामिल हैं
  • दो versions उपलब्ध हैं
    • open source (OSS): single-threaded asyncio execution, individual insert/ack, simple recovery
    • Pro version: process pool-आधारित parallel processing, workflows, relays, unique jobs, smart concurrency support
  • OSS personal projects या evaluation के लिए उपयुक्त है, जबकि बड़े scale के environments के लिए Pro version की सिफारिश की जाती है

job processing path

  • job insert होने के बाद उसे oban_jobs table में state='available' के साथ store किया जाता है, और PostgreSQL के NOTIFY के ज़रिए हर node को सूचना भेजी जाती है
  • हर node का Stager संबंधित queue को detect करके Producer को जगाता है, और Producer jobs को fetch करके execute करता है
  • job select करते समय SQL के FOR UPDATE SKIP LOCKED का उपयोग किया जाता है, जिससे duplicate execution के बिना parallel processing संभव होती है
    • पहले से locked rows को छोड़ दिया जाता है ताकि दूसरा producer तुरंत दूसरे jobs उठा सके
  • jobs को async task के रूप में dispatch किया जाता है, और पूरा होने पर callback से acknowledgement संभाला जाता है
  • Pro version asyncio की जगह process pool dispatcher का उपयोग करके multi-core parallel execution support करता है

background processes

  • leader election
    • PostgreSQL के INSERT ... ON CONFLICT और TTL-आधारित lease के ज़रिए leader तय किया जाता है
    • बिना किसी अलग consensus protocol के एक single leader job cleanup और recovery संभालता है
  • Lifeline (orphaned job recovery)
    • अगर चल रहा job एक निश्चित समय (rescue_after, default 5 minutes) से ज़्यादा टिके, तो उसे available state में restore किया जाता है
    • Pro version producer की liveness भी check करता है, जबकि OSS केवल समय-आधारित निर्णय लेता है
  • Pruner (job cleanup)
    • completed, cancelled, और discarded jobs में से max_age (default 1 day) से पुराने entries delete किए जाते हैं
    • database load से बचने के लिए LIMIT के साथ deletion range सीमित की जाती है

retries और backoff

  • अगर कोई job exception raise करता है, तो Executor तय करता है कि retry करना है या नहीं
    • अगर job अधिकतम attempts (max_attempts) से कम है तो retry, वरना discard
  • default backoff jitter के साथ exponential increase पर आधारित है
    • बड़े पैमाने पर failures के समय एक साथ retry होने से बचाकर load spike (Thundering Herd) को कम करता है
    • उदाहरण: पहली बार लगभग 17 seconds, पाँचवीं बार लगभग 47 seconds, दसवीं बार लगभग 17 minutes का इंतज़ार
  • worker class backoff() method के ज़रिए custom backoff logic लागू कर सकती है

मुख्य विशेषताएँ और मूल्यांकन

  • PostgreSQL की केंद्रीय भूमिका
    • FOR UPDATE SKIP LOCKED, LISTEN/NOTIFY, ON CONFLICT के ज़रिए concurrency control, signal delivery, leader election सब कुछ संभाला जाता है
    • Redis या external broker के बिना single database से coordination layer बनाई जाती है
  • parallel न होकर भी concurrency support
    • asyncio-आधारित होने के कारण I/O-bound कामों के लिए उपयुक्त, जबकि CPU-bound कामों के लिए Pro version बेहतर है
  • code structure की स्पष्टता
    • consistent naming और अलग-अलग responsibility structure के कारण codebase पढ़ना आसान है
  • OSS और Pro की भूमिकाएँ स्पष्ट रूप से विभाजित
    • OSS प्रयोग और छोटे scale के लिए, Pro बड़े scale और high-performance environments के लिए
  • निष्कर्ष: केवल PostgreSQL से एक पूर्ण job queue लागू करने वाला यह साफ-सुथरा और संरचित Python पोर्ट है, जो Elixir users या external infrastructure के बिना job system चाहने वाले developers के लिए उपयुक्त है

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.