Ưu điểm và nhược điểm khi sử dụng Celery vs. RQ

Question

Hiện tại tôi đang làm việc trên dự án python yêu cầu thực hiện một số công việc nền (chủ yếu là gửi email và cập nhật cơ sở dữ liệu). Tôi sử dụng Redis cho công ty môi giới nhiệm vụ. Vì vậy, trong thời điểm này tôi có hai ứng cử viên: Celery và RQ. Tôi đã có một số kinh nghiệm với các hàng đợi công việc này, nhưng tôi muốn yêu cầu các bạn chia sẻ kinh nghiệm của bạn về việc sử dụng các công cụ này. Vì thế.

1. Ưu điểm và nhược điểm khi sử dụng Celery so với RQ.
2. Bất kỳ ví dụ về dự án/nhiệm vụ nào phù hợp để sử dụng Celery so với RQ.

Cần tây trông khá phức tạp nhưng đó là giải pháp đầy đủ tính năng. Thực ra tôi không nghĩ rằng tôi cần tất cả các tính năng này. Từ phía bên kia RQ rất đơn giản (ví dụ: cấu hình, tích hợp), nhưng có vẻ như nó thiếu một số tính năng hữu ích (ví dụ: thu hồi nhiệm vụ, tự động nạp lại mã)

Answer 1

Đâ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 trên một số điểm.

Tóm lại, RQ được thiết kế đơn giản hơn. Cần tây được thiết kế để mạnh mẽ hơn. Cả hai đều tuyệt vời.

• Tài liệu. RQ's documentation là toàn diện mà không bị 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 lạc lõng hay bối rối. Celery's documentation cũng là toàn diện, nhưng hy vọng sẽ truy cập lại nó khá nhiều khi bạn thiết lập mọi thứ trước khi có quá nhiều tùy chọn để nội bộ hóa

• Giám sát. Celery's Flower và RQ dashboard đều rất đơn giản để thiết lập và cung cấp cho bạn ít nhất 90% của tất cả thông tin mà bạn sẽ muốn

• Hỗ trợ môi giới. Cần tây là người chiến thắng rõ ràng, RQ chỉ hỗ trợ Redis. Điều này có nghĩa là tài liệu ít 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 người môi giới trong tương lai nếu Redis không còn hoạt động cho bạn nữa. Ví dụ: Instagram considered both Redis and RabbitMQ with Celery. Điều này quan trọng bởi vì các nhà môi giới khác nhau có các bảo lãnh khác nhau, ví dụ: Redis không thể (bằng văn bản) đảm bảo 100% tin nhắn của bạn được gửi.

• Hàng đợi ưu tiên. Mô hình xếp hàng ưu tiên của RQs đơn giản và hiệu quả - workers read from queues in order. Cần tây đòi hỏi nhiều công nhân phải tiêu thụ từ các hàng đợi khác nhau. Cả hai phương pháp đề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ợ fork ví 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.Cần tây là cực kỳ linh hoạt (nhiều kết quả backends, định dạng cấu hình tốt đẹp, hỗ trợ công việc canvas) 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ợ phụ. Cần hỗ trợ các nhiệm vụ phụ (ví dụ: tạo nhiệm vụ mới từ bên trong các tác vụ hiện có). Tôi không biết liệu RQ có

• Cộng đồng và tính ổn định. Cần tây có thể được thành lập hơn, nhưng cả hai đều là những dự án tích cực. Theo văn bản, cần tây có ~ 3500 ngôi sao trên Github khi RQ có ~ 2000 và cả hai dự án cho thấy sự phát triển tích cực

Theo tôi, cần tây là không phức tạp như danh tiếng của nó có thể khiến bạn tin rằng, nhưng bạn sẽ phải RTFM.

Vì vậy, tại sao mọi người sẵn sàng giao dịch cần thiết (được cho là đầy đủ tính năng hơn) cho RQ? Trong tâm trí của tôi, tất cả đi xuống đến sự đơn giản. Bằng cách giới hạn bản thân với Redis + Unix, RQ cung cấp tài liệu đơn giản hơn, codebase đơ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ữ chi tiết về hệ thống xếp hàng nhiệm 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ể nằm trong đầu của chúng tôi cùng một lúc, và bằng cách loại bỏ sự cần thiết phải giữ các chi tiết hàng đợi trong RQ cho phép quay trở lại mã mà bạn quan tâm. Sự đơn giản đó đến với chi phí các tính năng như hàng đợi công việc liên ngôn ngữ, hỗ trợ hệ điều hành rộng, đảm bảo tin nhắn 100% đáng tin cậy và khả năng chuyển đổi người môi giới tin nhắn dễ dàng.

Answer 2

Cần tây không phức tạp. Tại lõi của nó, bạn thực hiện cấu hình từng bước từ tutorials, tạo một cá thể celery, trang trí chức năng của bạn với @celery.task rồi chạy tác vụ với my_task.delay(*args, **kwargs).

Đánh giá từ đánh giá của riêng bạn, có vẻ như bạn phải lựa chọn giữa các tính năng thiếu (chính) hoặc có một số chi phí vượt quá xung quanh. Đó không phải là một lựa chọn quá khó trong cuốn sách của tôi.