Hatchet v1 釋出：基於 Postgres 的任務編排平臺，可擴充套件至每秒 25K 查詢

BigGo Editorial Team

基於 PostgreSQL 構建的後臺任務編排平臺 Hatchet 正式釋出了其 v1 版本。該平臺旨在解決開發人員在大規模管理後臺任務時面臨的常見挑戰，為傳統任務佇列系統（如 Celery 或 BullMQ）以及工作流編排器（如 Temporal 和 Airflow）提供了替代方案。

後臺任務對現代應用程式至關重要，它們有助於從網路伺服器解除安裝工作，並確保關鍵操作即使在流量高峰期也能完成。雖然許多開發人員最初使用基於 Redis 或 RabbitMQ 的簡單佇列，但隨著應用程式複雜性的增加，這些解決方案通常變得難以除錯和監控。

Hatchet 團隊在其 v1 版本中進行了重大的架構調整，摒棄了 PostgreSQL 佇列中常用的 FOR UPDATE SKIP LOCKED 模式。據開發人員稱，當處理大量工作器和大型任務積壓時，這種方法的擴充套件性不超過每秒 25,000 個查詢。

「我們最初將一些工作流表與監控表合併在一起......這個表使用 UUID 作為主鍵，因為我們希望在 API 上使用 UUID 而不是自增 ID。當嘗試刪除批次資料和防止索引膨脹時，UUID 導致了一些麻煩。」

團隊實施了幾項最佳化，包括將監控表與隊列表分離以防止表膨脹等問題，緩衝讀寫以減少資料庫負載，以及將高容量表從 UUID 切換為身份列。這些變更顯著提高了在高負載下的效能和穩定性。

Hatchet 支援多種任務執行模式，以滿足不同開發人員的需求。該平臺既提供傳統任務佇列用於簡單的後臺作業，也提供透過有向無環圖（DAG）和持久執行模式實現更復雜的工作流編排。

對於來自 Celery 或 SQS 等系統的開發人員，Hatchet 提供了熟悉的佇列功能並改進了監控。對於需要更復雜工作流的開發人員，該平臺支援子任務生成和類似於 Temporal 工作流和活動的持久執行模式。

一位使用者強調，v1 SDK 中對 Pydantic 的一流支援是從 Celery 轉換的開發人員的主要優勢，指出型別安全顯著改善了開發人員體驗。Python 和 TypeScript SDK 的結合也允許更大的實現靈活性，同時還提供 Go 語言支援。

Hatchet 主要特點

部署方法

比較要點

Hatchet 非常重視可觀察性和開發者體驗。與許多在大規模下監控變得具有挑戰性的任務佇列系統不同，Hatchet 將其監控基礎設施與隊列表分離，允許開發人員查詢活動佇列和歷史任務資料，而不會降低效能。

該平臺包括一個即時 Web 儀表板，與 Celery 的 Flower 等工具相比，提供了更好的可見性。這種對監控的關注解決了使用者提出的一個常見痛點——瞭解任務失敗時發生了什麼以及如何有效地除錯問題。

一些使用者注意到儀表板和文件中存在一些粗糙的邊緣，不過團隊似乎對反饋很積極。監控與隊列表的分離還使得在必要時可以在完全獨立的資料庫上執行監控，為高規模部署提供了額外的靈活性。

Hatchet 既可作為雲服務使用，也可作為自託管解決方案使用。對於自託管，團隊提供了一個 hatchet-lite 選項，捆綁了所有內部服務，以及透過 Docker Compose 和適用於 Kubernetes 的 Helm 圖表的更復雜部署選項。

該平臺還支援 webhook 工作器，允許任務觸發 HTTP 端點，而不需要專用的長時間執行的工作器。這種方法提供了類似於 Google Cloud Tasks 等服務的靈活性，儘管一些使用者注意到這一功能在文件中的突出程度不如其他功能。

雖然 Hatchet 的主要焦點是 Python、TypeScript 和 Go 開發人員，但團隊正在跟蹤對其他語言 SDK 的請求。該平臺使用 gRPC 進行工作器通訊的架構可能會在不使用官方 SDK 的情況下為直接 API 整合帶來挑戰。

隨著後臺任務管理繼續成為現代應用程式架構的關鍵元件，Hatchet 將 PostgreSQL 的可靠性與高階編排功能相結合的方法，使其成為尋求擴充套件後臺處理能力的開發團隊的一個有吸引力的選擇。