Hatchet – hàng đợi công việc phân tán mã nguồn mở

Hàng đợi công việc phân tán, chịu lỗi

• Hatchet thay thế các hệ thống hàng đợi hoặc pub/sub hiện có vốn khó quản lý, cho phép thiết kế tải công việc bền bỉ có thể phục hồi sau lỗi và giải quyết các vấn đề như đồng thời, công bằng và giới hạn tốc độ.
• Thay vì tự quản lý hàng đợi công việc hay hệ thống pub/sub, bạn có thể dùng Hatchet để phân phối hàm giữa một nhóm worker với hạ tầng hoặc cấu hình tối thiểu.

Ưu điểm của Hatchet

• Lập lịch độ trễ cực thấp và thông lượng cao
  • Hatchet được xây dựng trên một hàng đợi độ trễ thấp với thời gian khởi động trung bình 25ms, mang lại sự cân bằng tối ưu giữa khả năng tương tác thời gian thực và độ tin cậy cần thiết cho các tác vụ quan trọng.
• Đồng thời, công bằng, giới hạn tốc độ
  • Hatchet triển khai sẵn các chiến lược như FIFO, LIFO, Round Robin và Priority Queues, giúp vượt qua những bài toán mở rộng phổ biến chỉ với cấu hình tối thiểu.
• Khả năng phục hồi theo thiết kế
  • Với chính sách retry tùy chỉnh và xử lý lỗi tích hợp, Hatchet bảo đảm công việc có thể được khôi phục nhanh chóng sau các lỗi tạm thời.

Khả năng quan sát và kiểm soát tốt hơn

• Observability
  • Mọi lần thực thi đều có thể được tìm kiếm đầy đủ, giúp nhanh chóng xác định vấn đề.
• Thực thi bền bỉ (ở mức thực dụng)
  • Có thể phát lại sự kiện và khởi động lại việc thực thi theo cách thủ công từ một bước cụ thể trong workflow.
• Cron
  • Có thể lập lịch thực thi hàm lặp lại định kỳ.
• Lập lịch một lần
  • Có thể lập lịch thực thi hàm vào một thời điểm và ngày cụ thể.
• Bảo vệ trước đột biến tải
  • Giảm nhẹ các đợt tăng đột biến lưu lượng và chỉ thực thi trong giới hạn hệ thống có thể xử lý.
• Streaming tiến độ
  • Có thể subscribe các cập nhật theo tiến độ của worker nền.

Ví dụ use case

• Công bằng cho Generative AI
  • Có thể dùng Hatchet để phân phối yêu cầu công bằng đến các worker, tránh việc một số người dùng bận rộn làm quá tải hệ thống.
• Xử lý batch để lập chỉ mục tài liệu
  • Hatchet có thể xử lý các batch lớn gồm tài liệu, hình ảnh và dữ liệu khác, đồng thời tiếp tục từ giữa tiến trình nếu xảy ra lỗi.
• Điều phối workflow cho hệ thống đa phương thức
  • Hatchet có thể điều phối đầu vào và đầu ra đa phương thức, đồng thời xử lý toàn bộ việc thực thi theo kiểu DAG.
• Tính chính xác cho xử lý hướng sự kiện
  • Có thể phản ứng với các sự kiện bên ngoài hoặc sự kiện nội bộ của hệ thống và tự động phát lại sự kiện.

Bắt đầu nhanh

• Hatchet hỗ trợ SDK mã nguồn mở cho Python, Typescript và Go.
• Để bắt đầu, bạn có thể tham khảo tài liệu của Hatchet hoặc xem kho quickstart.

Kho SDK

• Hatchet mặc định cung cấp Go SDK.
• Typescript SDK cũng có thể sử dụng.
• Nếu gặp vấn đề liên quan đến SDK, bạn có thể gửi issue trong kho tương ứng.

Có phiên bản cloud được quản lý của Hatchet không?

• Có, trong giai đoạn beta, Hatchet đang cung cấp phiên bản cloud cho một số công ty giúp xây dựng và định hình sản phẩm.

Có phiên bản tự host của Hatchet không?

• Có, bạn có thể tìm thấy hướng dẫn cho container Docker mã nguồn mở dùng để tự host trong tài liệu.

So với các lựa chọn thay thế thì thế nào? (Celery, BullMQ)

• Tại sao lại tạo thêm một hàng đợi được quản lý nữa?
  • Mục tiêu là có được lợi ích của hàng đợi giao dịch đầy đủ, đặc biệt cho các tác vụ phụ thuộc vào thực thi kiểu DAG, và nhóm phát triển tin tưởng mạnh mẽ rằng Postgres có thể thay thế phần lớn các trường hợp dùng hàng đợi.
  • Nhiều hàng đợi dựa trên Redis, và nếu không cẩn thận có thể xảy ra mất dữ liệu do OOM, nhưng khi dùng PG thì có thể tránh được vấn đề này.

Vấn đề

• Bạn có thể gửi các lỗi đã phát hiện thông qua Github issue.
• Vì dự án đang ở giai đoạn đầu, tốt hơn nên liên hệ trước qua Discord trước khi đưa ra các yêu cầu tính năng phức tạp.

Nếu muốn đóng góp

• Hãy tham khảo tài liệu đóng góp và cho biết bạn muốn làm gì trong kênh #contributing trên Discord để dễ định hình hướng đi của dự án và hợp tác thuận lợi hơn.

Ý kiến của GN⁺

• Hatchet có vẻ là một giải pháp giúp giảm độ phức tạp trong quản lý hàng đợi công việc ở các hệ thống phân tán, đồng thời cung cấp tính sẵn sàng cao và khả năng chịu lỗi, đặc biệt hữu ích cho xử lý dữ liệu quy mô lớn và dịch vụ thời gian thực.
• So với các hệ thống hàng đợi khác đang được dùng trên thị trường, độ ổn định và khả năng mở rộng có được nhờ sử dụng Postgres là một ưu điểm đáng chú ý của công nghệ này.
• Những điểm cần cân nhắc khi triển khai Hatchet gồm khả năng tương thích với hạ tầng hiện có, di chuyển dữ liệu và năng lực kỹ thuật của đội ngũ.
• Các tính năng quan sát và kiểm soát nâng cao mà Hatchet cung cấp có thể giúp việc giám sát hiệu năng hệ thống và xử lý sự cố trở nên dễ dàng hơn, từ đó giảm gánh nặng công việc cho đội phát triển và vận hành.
• Vì Hatchet vẫn đang ở giai đoạn beta, cần kiểm chứng đầy đủ về độ ổn định và tính năng, đồng thời nên thử nghiệm kỹ trước khi áp dụng vào hệ thống quy mô lớn.

[GN⁺]

Ý kiến trên Hacker News

• Một người dùng cho biết họ đã tìm kiếm suốt 3 năm một sản phẩm có hàng đợi tác vụ dựa trên Postgres, các worker hoạt động với nhiều ngôn ngữ khác nhau, cùng khả năng quan sát tích hợp phù hợp. Người này nói rằng cứ 6 tháng lại kiểm tra thị trường và đánh giá các lựa chọn thay thế nhưng lần nào cũng thất vọng. Tuy nhiên, họ muốn tránh các phụ thuộc bổ sung như RabbitMQ nên ưu tiên hàng đợi dựa trên Postgres. Hiện tại họ đang dùng graphile-worker, nhưng vẫn còn những yêu cầu chưa được đáp ứng.
• Một người dùng khác chỉ ra rằng sản phẩm này đang được Y Combinator hậu thuẫn và tự hỏi liệu công ty này sẽ theo mô hình "open core" hay sẽ tìm cách kiếm tiền theo phương thức khác.
• Một người dùng khác nữa nói rằng họ thích tính năng push subscription của hệ thống pub/sub; ví dụ, trong GCP pub/sub, có thể có subscriber đẩy sự kiện tới một HTTP endpoint thay vì kéo từ hàng đợi. Cách này có ưu điểm là có thể dùng các runtime như Cloud Run hoặc Lambda để scale theo các yêu cầu HTTP và scale về 0. Việc cấu hình autoscaling cho worker có thể phức tạp hơn; dù cũng có thể thiết lập KEDA autoscaling trong RabbitMQ dựa trên metric độ sâu hàng đợi, điều đó lại làm tăng độ phức tạp. Người dùng hỏi liệu có kế hoạch hỗ trợ mô hình trong đó một daemon giữ kết nối HTTP có thể đẩy tác vụ hay không.
• Một người dùng yêu cầu giải thích vì sao mọi hàm đều nhận context làm tham số. Họ cảm thấy điều này khiến phải viết khá nhiều mã boilerplate khi viết hàm.
• Một người dùng khác nói rằng giá như họ biết ý tưởng này khi triển khai một hệ thống xử lý DAG phân tán, và họ muốn thử nó.
• Một người dùng hỏi liệu dịch vụ đám mây do bên này cung cấp có công khai giá hay không, và có kế hoạch làm Kubernetes operator cho tùy chọn tự host hay không. Họ cũng bày tỏ lo ngại rằng việc dùng giấy phép MIT có thể khiến Amazon trong tương lai tạo ra dịch vụ Amazon Hatchet.
• Một người dùng khác cho biết họ đang viết một hàng đợi tác vụ cho trình chạy tác vụ dựa trên DAG, và muốn các đồ thị tác vụ có thể chạy bằng PostgreSQL, SQLite, bộ nhớ trong, v.v. mà không cần phải tính đến retry, timeout, tài nguyên tuần tự hóa, v.v. Người này quan tâm tới cách tiếp cận đó.
• Một người dùng nói rằng họ cần một hàng đợi tác vụ cho phép client (trình duyệt web) lắng nghe tiến trình của tác vụ cho tới khi hoàn tất. Họ thích sự đơn giản và dễ tiếp cận của Deno Queue, nhưng phải tự triển khai cách để client subscribe trạng thái tác vụ. Họ tự hỏi liệu có thể làm điều này trên nền Postgres không, và đã xác nhận qua liên kết tài liệu rằng điều đó là khả thi.
• Một người dùng khác nhắc tới việc ở công ty cũ họ từng gặp bài toán phải lên lịch số lượng tác vụ không giới hạn. Ví dụ, nếu bệnh nhân đặt lịch hẹn sau 6 tháng, thì cần lên lịch một chuỗi thông báo nhắc nhở trong suốt khoảng thời gian đó. Ban đầu họ chèn bản ghi vào hàng đợi trong cơ sở dữ liệu và polling vài giây một lần, nhưng chi phí IO do polling không lý tưởng nên họ muốn giải quyết mà không dùng hệ thống phân tán. Sau đó họ chuyển sang Redis nhưng gặp các vấn đề như độ phức tạp khi xử lý nhiều dispatcher, lỗi OOM, và phải chạy một tác vụ phụ để chuyển công việc sang hàng đợi thực thi ngay. Họ từng cân nhắc chuyển sang PG và dùng SKIP LOCKED, v.v., nhưng rồi đổi việc. Họ tự hỏi liệu Hatchet có phù hợp với use case này không.
• Cuối cùng, một người dùng hỏi Hatchet so với Temporal/Cadence/Conductor như thế nào, và liệu Hatchet cũng có hỗ trợ durable execution hay không.