Đây là những gì tôi đã tìm thấy trong khi cố gắng trả lời chính xác câu hỏi này. Nó có thể không toàn diện, và thậm chí có thể không chính xác ở một số điểm.
Nói tóm lại, RQ được thiết kế để đơn giản hơn. Cần tây được thiết kế để cứng cáp hơn. Cả hai đều xuất sắc.
- Tài liệu. Tài liệu của RQ là toàn diện mà không phức tạp và phản ánh sự đơn giản tổng thể của dự án - bạn không bao giờ cảm thấy mất hứng thú hoặc bối rối. Tài liệu hướng dẫn của Celery cũng rất đầy đủ, nhưng mong bạn sẽ được truy cập lại nó khá nhiều khi bạn lần đầu tiên thiết lập mọi thứ vì có quá nhiều tùy chọn để nội dung
-
Giám sát. Celery's Flower và bảng điều khiển RQ đều rất đơn giản để thiết lập và cung cấp cho bạn ít nhất 90% tất cả thông tin bạn muốn
-
Hỗ trợ môi giới. Celery là người chiến thắng rõ ràng, RQ chỉ hỗ trợ Redis. Điều này có nghĩa là ít tài liệu hơn về "nhà môi giới là gì", nhưng cũng có nghĩa là bạn không thể chuyển đổi nhà môi giới trong tương lai nếu Redis không còn làm việc cho bạn. Ví dụ:Instagram đã xem xét cả Redis và RabbitMQ với Celery. Điều này rất quan trọng vì các nhà môi giới khác nhau có các đảm bảo khác nhau, ví dụ:Redis không thể (kể từ khi viết) đảm bảo 100% rằng tin nhắn của bạn được gửi đi.
-
Hàng đợi ưu tiên. Mô hình hàng đợi ưu tiên RQs rất đơn giản và hiệu quả - công nhân đọc từ các hàng đợi theo thứ tự. Cần tây đòi hỏi nhiều công nhân quay vòng để tiêu thụ từ các hàng đợi khác nhau. Cả hai cách tiếp cận đều hoạt động
-
Hỗ trợ hệ điều hành. Cần tây là người chiến thắng rõ ràng ở đây, vì RQ chỉ chạy trên các hệ thống hỗ trợ
forkví dụ. Hệ thống Unix -
Hỗ trợ ngôn ngữ. RQ chỉ hỗ trợ Python, trong khi Celery cho phép bạn gửi các tác vụ từ một ngôn ngữ này sang một ngôn ngữ khác
-
API. Celery cực kỳ linh hoạt (nhiều kết quả phụ trợ, định dạng cấu hình đẹp, hỗ trợ canvas quy trình làm việc) nhưng tự nhiên sức mạnh này có thể gây nhầm lẫn. Ngược lại, api RQ rất đơn giản.
-
Hỗ trợ nhiệm vụ phụ. Celery hỗ trợ các nhiệm vụ phụ (ví dụ:tạo nhiệm vụ mới từ bên trong các nhiệm vụ hiện có). Tôi không biết RQ có
không -
Tính cộng đồng và tính ổn định. Celery có lẽ được thành lập nhiều hơn, nhưng cả hai đều là những dự án đang hoạt động. Khi viết bài, Celery có ~ 3500 sao trên Github trong khi RQ có ~ 2000 và cả hai dự án đều cho thấy sự phát triển tích cực
Theo tôi, Celery không phức tạp như danh tiếng của nó có thể khiến bạn tin tưởng, nhưng bạn sẽ phải RTFM.
Vì vậy, tại sao mọi người lại sẵn sàng đổi Cần tây (được cho là đầy đủ tính năng hơn) để lấy RQ? Trong suy nghĩ của tôi, tất cả đều hướng đến sự đơn giản. Bằng cách tự giới hạn Redis + Unix, RQ cung cấp tài liệu đơn giản hơn, cơ sở mã đơn giản hơn và API đơn giản hơn. Điều này có nghĩa là bạn (và những người đóng góp tiềm năng cho dự án của bạn) có thể tập trung vào mã mà bạn quan tâm, thay vì phải giữ thông tin chi tiết về hệ thống hàng đợi tác vụ trong bộ nhớ làm việc của bạn. Tất cả chúng ta đều có giới hạn về số lượng chi tiết có thể xuất hiện trong đầu chúng ta cùng một lúc và bằng cách loại bỏ nhu cầu giữ chi tiết hàng đợi tác vụ trong đó RQ cho phép quay lại mã mà bạn quan tâm. Sự đơn giản đó đi kèm với các tính năng như hàng đợi nhiệm vụ liên ngôn ngữ, hỗ trợ hệ điều hành rộng, đảm bảo tin nhắn đáng tin cậy 100% và khả năng chuyển đổi môi giới tin nhắn dễ dàng.
