Show HN：Hatchet – 开源分布式任务队列

原文 ↗ Hacker News 讨论 ↗

架构与持久性模型

  • 任务由预定义的工作流支撑，其步骤和输入/输出会持久化到 Postgres 中。
  • 引擎组件轮询 Postgres，通过长连接的 gRPC 连接分配工作，并在数据库中跟踪超时和重试。
  • 持久化执行采用“至少一次”：可以使用存储的输入回放步骤；建议任务设计为幂等。
  • 不需要基于 Redis 的锁；Postgres 是核心的持久性与协调层。

Worker 行为与故障语义

  • Worker 每隔几秒发送心跳；如果约 60 秒不活跃，任务会被重新分配（前提是仍有重试次数）。
  • 取消信号会被发送，但不能保证一定送达；如果 worker 忽略取消，或在重新分配后又恢复，可能会出现重复执行。
  • 这被认为是一个需要告警和更好监控的边缘情况。

工作流、DAG 与限制

  • 工作流会提前声明为 DAG；这相比过程式代码，更便于可视化、版本管理和多步骤调试。
  • 取舍：单个任务内目前没有 try/catch，也还没有简单的“await futures 并稍后收集”的模型。过程式工作流已列入路线图。
  • 可以在步骤中触发子工作流；基于数组返回值进行 fan-out 的能力正在考虑中。
  • 目前没有描述支持运行时动态修改 DAG。

与其他工具的比较

  • 它被定位为 Celery/Redis/RabbitMQ 的替代方案，提供更强的可观测性和 UI，也在概念上类似 Temporal/Cadence，但运维更简单。
  • 与 pg-boss/River/Graphile Worker 的区别在于：它是独立服务 + UI，而不是纯库，并且增加了工作流语义和 worker 池。
  • 与 Windmill/Inngest 相比：同样是基于 Postgres 的工作流引擎；Hatchet 的范围更窄（任务队列 + 工作流），并采用 MIT 许可证。

依赖与基础设施选择

  • 目前使用 Postgres 加 RabbitMQ 做部分发布/订阅；维护者希望迁移到 Postgres LISTEN/NOTIFY 或类似方案，但也指出连接池器和回放会带来复杂性。
  • 线程中一些人认为 RabbitMQ 便宜且可靠；另一些人则更倾向于尽量减少围绕 Postgres 的移动组件。

自托管、云服务、定价与许可证

  • 已有自托管指南；关键在于高可用的 ingestion 服务以及支持 PITR 的托管 Postgres。
  • 云服务仍处于早期访问阶段；尚未公布定价。
  • 项目完全采用 MIT；收入预计来自托管的 Hatchet Cloud，外加可能的企业支持。
  • 团队也意识到超大规模云厂商“搬运即服务”的风险；尽管如此，他们仍选择 MIT。

调度、延迟任务与用例

  • 通过 Go cron 库实现基于 cron 的调度；一次性/延迟调度已有基础形式，正在重构为由数据库驱动并可扩展。
  • 一些长周期提醒/通知场景（例如医疗随访）目前支持还不够好，但这是目标之一。
  • Hatchet 不是专为 AI 设计，但被定位为适用于 GenAI 管道以及其他多步骤、资源受限的工作流。

性能与可观测性

  • 报告的平均启动延迟：首个步骤约 50 ms，后续步骤在压测中约 25 ms；他们也承认这比原始消息队列慢，但对于 DAG/任务语义来说是可接受的。
  • 与 Celery/Temporal 相比，可观测性和 UX 是主要卖点：可以通过 UI 查看工作流、worker 健康状况和 DAG 执行；不过参数可见性以及类型/序列化内省仍在改进中。

整体反馈

  • 很多评论者都很兴奋，说他们一直在等待一个基于 Postgres、支持多语言、并且具备良好可观测性的队列。
  • 怀疑者则质疑，相比更简单的 PG 队列、RabbitMQ 或现有工作流引擎，这是否增加了不必要的复杂度，并担心边缘情况（取消、exactly-once 语义、长期调度和依赖膨胀）。