Phân biệt cần tây, kombu, PyAMQP và RabbitMQ/ironMQ

Question

Tôi muốn tải hình ảnh lên máy chủ S3, nhưng trước khi tải lên, tôi muốn tạo hình thu nhỏ có 3 kích thước khác nhau và tôi muốn nó được thực hiện trong chu kỳ yêu cầu/phản hồi. đang sử dụng cần tây. Tôi đã đọc tài liệu, đây là những gì tôi đã hiểu. Hãy sửa tôi nếu tôi sai.

1. Cần tây giúp bạn quản lý hàng đợi công việc của mình bên ngoài chu kỳ phản hồi yêu cầu.
2. Sau đó, có một cái gì đó gọi là cà rốt/kombu - một middleware django của nó mà gói các nhiệm vụ được tạo ra thông qua cần tây.
3. Sau đó, lớp thứ ba PyAMQP tạo điều kiện giao tiếp của cà rốt cho một nhà môi giới. ví dụ. RabbitMQ, AmazonSQS, ironMQ, v.v.
4. Nhà môi giới ngồi trên một máy chủ khác và thực hiện công cụ cho bạn.

Giờ đây, sự hiểu biết của tôi là - nếu nhiều người dùng tải lên hình ảnh cùng lúc, cần tây sẽ xếp lại kích thước và thay đổi kích thước thực sự sẽ xảy ra ở máy chủ ironMQ, vì nó cung cấp addon tuyệt vời trên heroku.

Bây giờ những nghi ngờ:

1. Nhưng những gì sau khi hình ảnh thay đổi kích cỡ, sẽ ironMQ đẩy nó đến máy chủ S3, hoặc nó sẽ thông báo khi quá trình này hoàn tất .. tôi không rõ ràng về nó.

2. Sự khác biệt giữa cần tây và kombu/cà rốt là gì, bạn có thể giải thích một cách sống động.

Answer 1

IronMQ không xử lý công việc của bạn cho bạn; nó chỉ đơn giản là phục vụ như là phụ trợ cho Celery để theo dõi những công việc cần phải được thực hiện.

Vì vậy, đây là những gì sẽ xảy ra. Giả sử bạn có hai máy chủ, máy chủ web và máy chủ Celery của bạn. Máy chủ web của bạn chịu trách nhiệm xử lý các yêu cầu, máy chủ Celery của bạn tạo các hình thu nhỏ và tải chúng lên S3. Dưới đây là yêu cầu điển hình của bạn:

1. Người dùng của bạn tải hình ảnh lên máy chủ web của bạn.
2. Bạn lưu hình ảnh đó ở đâu đó - Tôi khuyên bạn nên đặt nó trên S3 ngay sau đó, cá nhân, nhưng bạn cũng có thể lưu trữ nó vào, ví dụ IronCache, được mã hóa base64. Vấn đề là đặt nó ở đâu đó máy chủ Celery của bạn có thể truy cập nó.
3. Bạn sắp xếp công việc trên Celery, chuyển vị trí của hình ảnh đến máy chủ Celery của bạn.
4. Máy chủ Celery của bạn tải xuống hình ảnh, tạo hình thu nhỏ của bạn và tải chúng lên S3. Sau đó nó lưu trữ các URL S3 trong kết quả công việc.
5. Máy chủ web của bạn đợi cho đến khi hoàn thành công việc, sau đó có quyền truy cập vào kết quả. Ngoài ra, bạn có thể có máy chủ Celery của bạn lưu trữ các kết quả trong cơ sở dữ liệu chính nó. Vấn đề là máy chủ Celery thực hiện việc nâng hạng nặng (tạo ra các hình thu nhỏ) và không giữ vòng lặp yêu cầu trong khi nó thực hiện.

Tôi đã viết một ví dụ về cách sử dụng IronMQ trên Heroku. Bạn có thể xem tại đây: http://iron-celery-demo.herokuapp.com. Bạn có thể xem nguồn cho ví dụ on Github và read the tutorial, giải thích khá kỹ lưỡng và từng bước cách triển khai Celery trên Heroku.

Để làm sáng tỏ những thứ AMQP:

• IronMQ là một hàng đợi dịch vụ tin nhắn dựa trên đám mây phát triển bởi Iron.io.
• AMQP là thông số nhắn tin mở
• RabbitMQ là triển khai phổ biến nhất (mà tôi biết) của đặc tả AMQP.
• PyAMQP là một thư viện Python cho phép Python khách hàng giao tiếp với bất kỳ thực hiện AMQP, bao gồm RabbitMQ

Một trong những khác biệt lớn nhất giữa IronMQ và RabbitMQ/AMQP được rằng IronMQ được lưu trữ và quản lý, vì vậy bạn don' t phải tự chủ máy chủ và lo lắng về thời gian hoạt động. Spec cung cấp một bó nhiều hơn về sự khác biệt, và có sự khác biệt cơ bản, nhưng Celery tóm tắt hầu hết những người đi. Bởi vì bạn đang sử dụng Celery, sự khác biệt duy nhất bạn phải chịu là IronMQ được lưu trữ, vì vậy bạn không phải đứng lên và quản lý máy chủ của riêng bạn.

Tiết lộ đầy đủ: Tôi đang làm việc cho Iron.io, công ty đứng sau IronMQ.

Answer 2

"Một trong những khác biệt lớn nhất giữa IronMQ và RabbitMQ/AMQP là IronMQ được lưu trữ và quản lý, vì vậy bạn không phải tự chủ máy chủ và lo lắng về thời gian hoạt động."

Hiện tại có ít nhất hai tùy chọn RabbitMQ được lưu trữ trên máy chủ được quản lý: Bigwig và CloudAMQP. Cần tây phải làm việc tốt với cả hai.