Ưu và nhược điểm khi sử dụng Cần tây so với RQ [đóng cửa]

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 nặng). Tôi sử dụng Redis cho môi giới nhiệm vụ. Vì vậy, ở điểm này tôi có hai ứng cử viên: Cần tây 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 nhờ các bạn chia sẻ kinh nghiệm sử dụng công cụ này. Vì thế.

1. Ưu và nhược điểm gì khi sử dụng Cần tây so với RQ.
2. Bất kỳ ví dụ nào về các dự án / nhiệm vụ 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. Trên thực tế, tôi không nghĩ rằng tôi cần tất cả các tính năng này. Nhìn từ khía cạnh khác, 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 tác vụ, tự động tải lại mã)

Đâ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 toàn diện, 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 mà 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ó những đảm bảo khác nhau, ví dụ như 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ụ như hệ thống Unix

• Hỗ trợ ngôn ngữ. RQ chỉ hỗ trợ Python, trong khi Celery cho phép bạn gửi 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ụ con. Cần tây hỗ trợ các nhiệm vụ con (ví dụ: tạo các nhiệm vụ mới từ bên trong các nhiệm vụ hiện có). Tôi không biết nếu RQ có

• 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ã bạn quan tâm. Sự đơn giản đó đi kèm với các tính năng như hàng đợi tác 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.

Cần tây không phức tạp như vậy. Về cốt lõi, bạn thực hiện cấu hình từng bước từ tutorials, tạo một celeryphiên bản, trang trí chức năng của bạn, @celery.tasksau đó chạy tác vụ vớimy_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ố tính năng dư thừa xung quanh. Đó không phải là lựa chọn quá khó trong cuốn sách của tôi.