RabbitMQ: Điều gì Celery cung cấp Pika đó không?

Question

Tôi đã làm việc để nhận một số tác vụ được phân phối hoạt động qua RabbitMQ.

Tôi đã dành thời gian cố gắng để Celery làm những gì tôi muốn và không thể làm cho nó hoạt động.

Sau đó, tôi đã thử sử dụng Pika và mọi thứ chỉ hoạt động, hoàn hảo và chỉ trong vài phút.

Có bất kỳ điều gì tôi đang bỏ lỡ bằng cách sử dụng Pika thay vì Celery không?

Answer 1

Điều pika cung cấp chỉ là một phần nhỏ trong những gì Celery đang làm. Pika là thư viện Python để tương tác với RabbitMQ. RabbitMQ là một nhà môi giới tin nhắn; ở cốt lõi của nó, nó chỉ gửi tin nhắn đến/nhận tin nhắn từ hàng đợi. Nó có thể được sử dụng như một hàng đợi nhiệm vụ, nhưng nó cũng có thể được sử dụng để truyền các thông điệp giữa các tiến trình mà không thực sự phân phối "công việc".

Cần tây thực hiện hàng đợi tác vụ được phân phối, tùy chọn sử dụng RabbitMQ làm nhà môi giới cho IPC. Thay vì chỉ cung cấp cách gửi thông điệp giữa các quá trình, nó cung cấp một hệ thống phân phối các nhiệm vụ/công việc thực tế giữa các quy trình. Đây là cách trang web của Celery mô tả nó:

Hàng đợi công việc được sử dụng làm cơ chế phân phối công việc trên các chủ đề hoặc máy.

Đầu vào của hàng đợi nhiệm vụ là một đơn vị công việc, được gọi là nhiệm vụ, dành riêng cho các quy trình công nhân sau đó liên tục theo dõi hàng đợi công việc mới để thực hiện .

Cần tây giao tiếp qua tin nhắn, thường sử dụng người môi giới để dàn xếp giữa khách hàng và người lao động. Để khởi tạo tác vụ, khách hàng đặt thông báo vào hàng đợi, người môi giới sau đó gửi tin nhắn đến một nhân viên .

Hệ thống cần tây có thể bao gồm nhiều công nhân và công ty môi giới, cung cấp cách cách tính khả dụng cao và chia tỷ lệ ngang.

Cần tây có toàn bộ chức năng tích hợp bên ngoài phạm vi của pika. Bạn có thể có một cái nhìn tại Celery docs để có được một ý tưởng về các loại điều nó có thể làm, nhưng đây là một ví dụ:

>>> from proj.tasks import add 

>>> res = add.chunks(zip(range(100), range(100)), 10)() 
>>> res.get() 
[[0, 2, 4, 6, 8, 10, 12, 14, 16, 18], 
[20, 22, 24, 26, 28, 30, 32, 34, 36, 38], 
[40, 42, 44, 46, 48, 50, 52, 54, 56, 58], 
[60, 62, 64, 66, 68, 70, 72, 74, 76, 78], 
[80, 82, 84, 86, 88, 90, 92, 94, 96, 98], 
[100, 102, 104, 106, 108, 110, 112, 114, 116, 118], 
[120, 122, 124, 126, 128, 130, 132, 134, 136, 138], 
[140, 142, 144, 146, 148, 150, 152, 154, 156, 158], 
[160, 162, 164, 166, 168, 170, 172, 174, 176, 178], 
[180, 182, 184, 186, 188, 190, 192, 194, 196, 198]] 

Mã này muốn thêm mỗi x + y trong đó x là trong range(0, 100) và y là trong range(0,100). Nó thực hiện điều này bằng cách thực hiện một nhiệm vụ gọi là add, thêm hai số và phân phối công việc thêm 1+1, 2+2, 3+3, v.v ... vào các đoạn 10 và phân phối từng đoạn cho nhiều công nhân Celery. Mỗi nhân viên sẽ chạy add trên đoạn 10 mục của nó, cho đến khi tất cả công việc hoàn tất. Sau đó, kết quả được thu thập bằng cuộc gọi res.get(). Tôi chắc rằng bạn có thể tưởng tượng một cách để làm điều này bằng cách sử dụng pika, nhưng tôi chắc chắn bạn cũng có thể tưởng tượng bao nhiêu công việc sẽ được yêu cầu. Bạn đang nhận được chức năng đó từ hộp với Celery.

Bạn chắc chắn có thể sử dụng pika để triển khai hàng đợi tác vụ được phân phối nếu bạn muốn, đặc biệt nếu bạn có trường hợp sử dụng khá đơn giản. Celery chỉ cung cấp giải pháp "pin đi kèm" để lên lịch công việc, quản lý, v.v. bạn sẽ phải tự thực hiện nếu bạn quyết định bạn muốn chúng với giải pháp pika của bạn.

Answer 2

Tôi sẽ thêm câu trả lời ở đây vì đây là lần thứ hai người nào đó đã đề xuất cần tây khi không cần dựa trên câu trả lời này mà tôi nghi ngờ. Vì vậy, sự khác biệt giữa một hàng đợi nhiệm vụ phân tán và một nhà môi giới là một nhà môi giới chỉ cần gửi tin nhắn. Không hơn không kém. Celery khuyến cáo sử dụng RabbitMQ làm môi giới mặc định cho IPC và đặt trên các adapter đó để quản lý các nhiệm vụ/hàng đợi với các quy trình daemon. Trong khi điều này là hữu ích đặc biệt là cho các nhiệm vụ phân phối, nơi bạn cần một cái gì đó chung chung rất nhanh chóng. Nó chỉ là xây dựng cho quá trình nhà xuất bản/người tiêu dùng. Các tác vụ thực tế mà bạn đã xác định quy trình làm việc mà bạn cần phải trải qua và đảm bảo độ bền tin nhắn dựa trên nhu cầu cụ thể của bạn, bạn nên viết nhà xuất bản/người tiêu dùng của mình tốt hơn là dựa vào cần tây. Rõ ràng bạn vẫn phải thực hiện tất cả việc kiểm tra độ bền, v.v. Với hầu hết các dịch vụ liên quan đến web, một dịch vụ không kiểm soát các đơn vị “công việc” thực tế mà thay vào đó, chuyển chúng sang một dịch vụ. Do đó, nó có ý nghĩa rất ít đối với hàng đợi nhiệm vụ phân tán trừ khi bạn đang đạt đến giới hạn cuộc gọi API tùy ý dựa trên địa chỉ ip/khu vực địa lý hoặc số tài khoản ... Hoặc điều gì đó dọc theo các dòng đó. Vì vậy, việc sử dụng cần tây không ngăn bạn phải viết hoặc xử lý mã trạng thái hoặc quản lý quy trình làm việc v.v. và nó cho thấy AMQP theo cách giúp bạn dễ dàng tránh viết các cấu trúc của mã nhà xuất bản/người tiêu dùng. Vì vậy, trong ngắn hạn nếu bạn cần một hàng đợi công việc đơn giản để nhai qua công việc và bạn không thực sự quan tâm đến sắc thái hiệu suất, sự phức tạp của độ bền thông qua quy trình làm việc của bạn hoặc quá trình xuất bản/tiêu thụ thực tế. Cần tây hoạt động. Nếu bạn chỉ gửi tin nhắn đến api hoặc dịch vụ mà bạn không thực sự kiểm soát, chắc chắn, bạn có thể sử dụng Celery nhưng bạn có thể dễ dàng bắt tay với nhà xuất bản/người tiêu dùng của riêng bạn với Pika trong vài phút nữa. Nếu bạn cần một cái gì đó mạnh mẽ hoặc tuân thủ các kịch bản độ bền của riêng bạn, hãy viết mã xuất bản/người tiêu dùng của riêng bạn như mọi người khác.