RabbitMQ: Trao đổi, xếp hàng và ràng buộc - ai thiết lập cái gì?

Question

Khi sử dụng RabbitMQ để gửi tin nhắn về cơ bản bạn có trao đổi, xếp hàng và liên kết. Tôi đã hiểu ý tưởng của họ và cách họ liên hệ với nhau, nhưng tôi không hoàn toàn chắc chắn ai đã thiết lập cái gì.

Về cơ bản, tôi có ba trường hợp trong đơn đăng ký của mình.

Kịch bản 1: Một nhà xuất bản, một số công nhân xử lý

Những gì tôi muốn đạt được là một trong những thành phần đó gửi tin nhắn tới một hàng đợi, và có được một số quy trình công nhân có thể xử lý các mặt hàng trong hàng đợi đó. Điều này có vẻ khá dễ dàng với tôi. Quá trình cài đặt như sau:

• Trao đổi: 1 trao đổi với kiểu 'trực tiếp'
• Queue: 1 hàng đợi
• Binding: Hàng đợi là ràng buộc để việc trao đổi

Bất cứ khi nào một thông điệp là gửi đến trao đổi, nó được gửi đến hàng đợi, và các quy trình công nhân nhận nhiệm vụ của họ.

Mọi thứ đều bền.

Vậy ai thiết lập cái gì? Theo ý kiến ​​của tôi:

• Nhà sản xuất tạo ra trao đổi
• Nhà sản xuất tạo ra hàng đợi (như hiện nay có thể không có quy trình lao động chạy, và thông điệp sẽ bị mất nếu không nếu không có hàng đợi)
• Nhà sản xuất hiện các ràng buộc của hàng đợi để trao đổi
• Người tiêu dùng chỉ cần nghe hàng đợi

Phải không?

Tình huống 2: Một nhà xuất bản, nhiều người đăng ký, thông điệp dễ bay hơi

Kịch bản thứ hai hoàn toàn khác. Về cơ bản, đó là một kịch bản pub/sub, nơi mỗi tin nhắn được gửi đến tất cả các khách hàng đang nghe. Nếu khách hàng chuyển sang ngoại tuyến, ứng dụng sẽ không nhận được tin nhắn nữa và chúng không được lưu trữ ở bất cứ đâu cho anh ta. Điều này có nghĩa các thiết lập sau:

• Trao đổi: 1 trao đổi với kiểu 'fanout'
• Queue: n hàng đợi, một cho mỗi người tiêu dùng
• Binding: Mỗi hàng đợi cần phải được ràng buộc để việc trao đổi

Vậy ai sẽ thiết lập cái gì?Theo ý kiến ​​của tôi:

• Nhà sản xuất tạo ra trao đổi
• tiêu dùng tạo ra hàng đợi (vì nó là hàng đợi riêng của mình, và nhà sản xuất không thể biết bất cứ ai quan tâm đến những thông điệp)
• tiêu dùng tạo ra ràng buộc cho hàng đợi của nó để trao đổi
• Người tiêu dùng lắng nghe hàng đợi của mình

Phải không?

Kịch bản 3: Một nhà xuất bản, một số thuê bao, các thông điệp bền

Về cơ bản giống như kịch bản 2, nhưng các tin nhắn không nên bị mất nếu một người tiêu dùng đi offline. Theo tôi, điều này không nên thay đổi gì cả - đúng không?

Answer 1

Tôi nghĩ rằng những gì bạn nói là đúng, ngoại trừ trên Kịch bản 3.

Nếu thông điệp không nên bị mất nếu một người tiêu dùng đi offline thì bạn cần hàng đợi bền và hàng đợi không thể auto_delete'd.

Mọi thứ khác có vẻ phù hợp với tôi.

Trong trường hợp của kịch bản 2, bạn cũng có thể để cho RabbitMQ tự động tạo tên hàng đợi cho bạn và sau đó để cho những hàng đợi đó được tự động xóa khi người tiêu dùng ngắt kết nối.