Trao đổi chủ đề và trao đổi trực tiếp trong RabbitMQ

Question

Chúng tôi có một ứng dụng sẽ sử dụng RabbitMQ và có một số hàng đợi khác nhau để truyền các thông điệp giữa các tầng. Ban đầu, tôi đã lên kế hoạch sử dụng nhiều trao đổi trực tiếp, với một giao dịch cho mỗi loại thông báo, nhưng có vẻ như việc trao đổi chủ đề với hàng đợi bằng cách sử dụng các ràng buộc khóa định tuyến khác nhau sẽ đạt được điều tương tự.

Có một trao đổi duy nhất cũng có vẻ như nó sẽ dễ dàng hơn một chút để duy trì, nhưng tôi đã tự hỏi nếu có bất kỳ lợi ích (nếu có) làm nó một cách khác?

Lựa chọn 1, sử dụng nhiều trao đổi trực tiếp:

ExchangeA (type: direct) 
-QueueA 

ExchangeB (type: direct) 
-QueueB 

ExchangeC (type: direct) 
-QueueC 

Lựa chọn 2, sử dụng đơn trao đổi chủ đề:

Exchange (type: topic) 
-QueueA (receives messages from exchange with routing key of "TypeA") 
-QueueB (receives messages from exchange with routing key of "TypeB") 
-QueueC (receives messages from exchange with routing key of "TypeC") 

Answer 1

Giả sử cả hai mô hình đang được xem xét để được thực hiện sử dụng một nhà môi giới chạy, có rất ít sự khác biệt mà tôi có thể thấy.

Tùy chọn 2 có vẻ phổ biến hơn trong thế giới thực để giải quyết vấn đề định tuyến này (ít nhất là trong trải nghiệm giai thoại của tôi) và đó chính là thách thức mà Trao đổi chủ đề tồn tại để giải quyết.

Sự khác biệt duy nhất mà bạn có thể gặp phải sẽ liên quan đến tốc độ định tuyến. Tôi không biết chắc chắn nếu định tuyến Exchange (dựa trên kết hợp chuỗi chính xác) nhanh hơn trong RabbitMQ khi so sánh với kỹ thuật định tuyến được sử dụng trong Trao đổi chủ đề (có thể bao gồm các ký tự đại diện như # và *). Linh cảm của tôi sẽ là sự phân biệt đối xử của Exchange sẽ nhanh hơn, nhưng bạn có thể thử nghiệm cho chính mình để tìm hiểu, hoặc thử liên lạc với nhóm ThỏMQ để hỏi họ.

Cuối cùng, nếu bạn đi với tùy chọn 1 kết thúc bằng nhiều hàng đợi thì bạn sẽ có một sự gia tăng tỷ lệ trao đổi. Điều đó nghe có vẻ như một nhức đầu bảo trì. Nếu bạn chỉ có một số hàng đợi thì nó sẽ không quá nhiều vấn đề.

Answer 2

Đối với một nút nhỏ duy nhất có ít tải, có rất ít sự khác biệt. Hầu hết mọi người đi với tùy chọn hai cho biết lý do trên.

Khi thiết kế hệ thống, bạn nên tự hỏi bản thân có thể mở rộng như thế nào trong tương lai.

Quy mô sẽ như thế nào?
Tôi có cần nó để mở rộng không? Tôi có muốn thêm một nhóm khả dụng cao trong tương lai không? Tuyến đường của tôi sẽ thay đổi ...

Tùy chọn 2 mang lại sự linh hoạt hơn trong hầu hết các trường hợp.

Nó cho phép bạn làm những việc như đính kèm một người tiêu dùng mới vào Exchange với hàng đợi của chính nó và nắm bắt bất kỳ tập hợp con hoặc tất cả luồng thông điệp của bạn một cách dễ dàng. (các hàng đợi này có thể nằm trên các nút khác trong một cụm hoặc được nhân đôi với các nút cung cấp chuyển đổi dự phòng) Một trường hợp sử dụng điển hình sẽ ghi nhật ký tất cả các thư bằng cách sử dụng hàng đợi thứ 4.

Nếu nút cổ chai của bạn ở bên xử lý, Bạn cũng có thể chia nhỏ chủ đề tin nhắn của mình và thực hiện một số ưu tiên với việc phải thay đổi nhà xuất bản của mình. Ví dụ: ToppicA.urgent, được xử lý bởi người tiêu dùng chuyên dụng, TopicA.log cuối cùng đã được xử lý.

Câu trả lời ngắn đi với tùy chọn 2 trừ khi bạn có yêu cầu hiệu suất rất cụ thể, Ví dụ: bạn cần xử lý tốc độ liên tục hơn 50k msg/s bạn có thể muốn suy nghĩ về tùy chọn 1 trên các nút chuyên dụng, nhưng đối với dòng chảy bình thường tùy chọn 2 sẽ dễ dàng hơn để mở rộng quy mô và duy trì.

Answer 3

Cách tiếp cận thực tế 2 tốt hơn vì nó cho phép bạn linh hoạt sử dụng một hàng đợi duy nhất cho nhiều khóa định tuyến.

Trao đổi Topic

QueueA-- binding key = India.Karnataka.* 

Bạn có thể lộ trình một thông điệp tới trao đổi chủ đề với phím định tuyến như India.Karnataka.bangalore, India.Karnataka.Mysore.

Tất cả các thư ở trên đều được gửi đến QueueA.

Trao đổi trực tiếp

Nhưng tôi không hiểu tại sao được bạn tạo ra nhiều trao đổi trực tiếp trong cách tiếp cận 1. Bạn có thể trao đổi trực tiếp duy nhất và có nhiều hàng đợi với mỗi hàng đợi ràng buộc với một khóa duy nhất.

QueueA-- binding key = Key1 
QueueB-- binding Key = Key2 
QueueC-- binding Key = Key3 

Tất cả các tin nhắn key1 đi tới QueueA.Key2 chuyển đến QueueB ... Bạn vẫn có thể duy trì trao đổi trực tiếp.