來自Elixir的任務處理框架Oban現已支援Python

背景

Elixir 生態系中極具盛名的任務處理框架 Oban 近期正式跨足 Python 領域，引起了開發者社群的廣泛關注。Oban 以 PostgreSQL 為核心，利用資料庫的事務特性來確保任務處理的可靠性，這與 Python 圈長期佔據主導地位、通常依賴 Redis 或 RabbitMQ 的 Celery 形成了鮮明對比。

社群觀點

在 Hacker News 的討論中，Sidekiq 的創作者 Mike Perham 首先對 Oban 團隊表示祝賀，並分享了他在擴展跨語言產品時的經驗。他提到自己當年選擇開發 Faktory 這種語言無關的中央伺服器架構，而非為每種語言編寫特定客戶端，這引發了關於「特定社群深耕」與「通用架構」孰優孰劣的討論。Oban 的創作者 Parker 則回應，他們更傾向於針對特定語言社群提供符合慣例的體驗，並坦言 Sidekiq 的商業模式確實是 Oban 早期發展的重要啟發。

針對技術細節，許多開發者對 Oban 採用的「事務性發件箱模式」（Transactional Outbox Pattern）表示高度贊同。這種模式允許開發者將業務邏輯（如創建使用者）與任務排程（如發送歡迎信）放在同一個資料庫事務中，確保兩者要麼同時成功，要麼同時回滾，解決了分散式系統中常見的雙寫一致性問題。雖然有意見認為傳統資料庫不適合高吞吐量的任務系統，但 Oban 團隊與支持者指出，透過 PostgreSQL 的 LISTEN/NOTIFY 機制與 SKIP LOCKED 語法，Oban 已能支撐每分鐘百萬級別的任務處理，打破了「資料庫排隊效能低下」的刻板印象。

然而，討論中也出現了對 Oban 商業模式的質疑。部分 Python 開發者對於核心功能（如多進程並行處理、速率限制、工作流管理）被鎖在 Pro 付費版之後感到不安。批評者認為，Python 的 asyncio 在處理 CPU 密集型任務時有其局限性，若不付費就無法使用多進程池，會讓開源版本顯得像是一個受限的演示版。對此，Oban 團隊解釋，將某些功能設為付費是為了維持開源專案的永續經營，且未來不排除將部分 Pro 功能下放到開源版。此外，也有開發者將 Oban 與 Celery、Temporal 或 Prefect 等現有工具進行比較，認為 Oban 的優勢在於其輕量化與對資料庫 ACID 特性的極致利用，適合那些不希望維護額外基礎設施（如 Redis）的中小型團隊。

延伸閱讀

• Faktory: 由 Sidekiq 作者開發的語言無關任務伺服器。
• Chancy: 討論中提到的另一個 Python 原生、基於 PostgreSQL 的開源任務框架。
• The Transactional Outbox Pattern: 關於如何利用資料庫事務確保訊息可靠發送的技術文章。
• Django Tasks: Django 6.0 引入的新 API，旨在提供統一的後端任務處理介面。
• pgmq: 基於 Rust 開發的 PostgreSQL 插件，提供類似訊息隊列的功能。