Khi nào cần khai báo/ràng buộc Hàng đợi và Trao đổi với RabbitMQ

Question

Chúng tôi có một thư viện bao quanh RabbitMQ tại nơi làm việc của tôi, được tạo bởi một người không còn làm việc ở đây nữa. Tôi đang thiết kế một hệ thống mới bằng cách sử dụng Rabbit và đang tìm ra cách tiếp cận tốt nhất để khai báo hàng đợi, trao đổi và ràng buộc. Kiến trúc thỏ của chúng tôi có một vài khu liên hợp toàn cầu, và mỗi vùng có nhiều nút Rabbit.

Mã trình bao bọc để xuất bản thư và đăng ký hàng đợi tuyên bố lại các trao đổi, hàng đợi và liên kết có liên quan mỗi lần. Mối quan tâm của tôi là điều này có thể giới thiệu độ trễ đáng kể vào mỗi thông báo xuất bản, đặc biệt nếu nó cần phải chờ xác nhận hàng đợi/trao đổi tồn tại trong các vùng toàn cầu từ xa. Tôi hy vọng điểm chuẩn của hàng triệu tin nhắn một giây không tái tuyên bố trao đổi cho mỗi lần xuất bản.

Tóm lại, cách tiếp cận này có vẻ hơi lãng phí và hoang tưởng với tôi, nhưng có lẽ tôi đang thiếu điều gì đó.

Vì vậy, tôi có một vài câu hỏi:

• là tái tuyên bố hàng đợi và trao đổi một hiệu suất đáng kể hit, được đưa ra liên đoàn toàn cầu?
• Khai báo lại từng cách sử dụng một cách tiếp cận tốt bởi vì nó xử lý hàng đợi/trao đổi biến mất do khởi động lại môi giới hoặc xóa rõ ràng?
• Chúng ta có nên khai báo hàng đợi và trao đổi một lần cho mỗi quá trình và mong đợi họ kéo dài suốt cả đời?
• Các trao đổi và hàng đợi bền có được khai báo trong cấu hình Thỏ và không được ứng dụng khai báo không?
• Cách thay đổi cấu hình cho hàng đợi/trao đổi sẽ được xử lý nếu các ứng dụng có thể tiếp tục khai báo chúng bằng cấu hình cũ? Các ứng dụng có nên xử lý lỗi khai báo và tiếp tục xuất bản/tiêu thụ không?

Answer 1

là tái tuyên bố hàng đợi và trao đổi một hiệu suất đáng kể đạt

nó có thể cho một khối lượng rất lớn các tin nhắn

là lại tuyên bố trên mỗi sử dụng một cách tiếp cận tốt bởi vì nó xử lý hàng đợi/trao đổi biến mất do khởi động lại môi giới hoặc xóa rõ ràng?

"cách tiếp cận tốt" - không.

"hiệu quả" trong việc ngăn ngừa biến mất trao đổi/hàng đợi/bindings từ gây ra vấn đề, vâng ... nhưng nó không phải là một điều tốt để làm, trong hầu hết các trường hợp

(có thể ok nếu bạn chỉ gửi một thông điệp rất thường xuyên , có một nguyên nhân thực sự gây lo ngại về cấu trúc liên kết bị xóa sạch)

Chúng ta có nên khai báo hàng đợi và trao đổi một lần cho mỗi quá trình và mong đợi họ tồn tại suốt đời không?

đây là cách tiếp cận chung của tôi.

nó mở ra khả năng cấu trúc liên kết bị phá hủy và bạn không biết điều đó. nó đi xuống để có hay không bạn nghĩ rằng điều này sẽ thực sự xảy ra.

Trao đổi và xếp hàng bền có được khai báo trong cấu hình Thỏ và không được khai báo bởi ứng dụng không?

không có gì sai với cấu trúc liên kết được xác định trước, nhưng nó bỏ qua rất nhiều sức mạnh và tính linh hoạt của giao diện người dùng và giao thức amqp.

nhiều hệ thống nhắn tin yêu cầu các cấu trúc liên kết được xác định trước và các công cụ chuyên biệt để quản lý cấu trúc liên kết. amqp là khá khác nhau ở chỗ nó cho phép bạn xác định cấu trúc liên kết khi cần thiết.

nếu bạn đối phó với một topo tĩnh, thì đây có thể là một lựa chọn tốt cho bạn

Làm thế nào nên cấu hình thay đổi cho hàng đợi/trao đổi được xử lý nếu các ứng dụng có thể tiếp tục khai báo với cấu hình cũ? Các ứng dụng có nên xử lý lỗi khai báo và tiếp tục xuất bản/tiêu thụ không?

tôi sẽ báo cáo ứng dụng và báo cáo thông qua bất kỳ cơ chế báo cáo lỗi nào bạn đang sử dụng.

thay đổi cấu trúc liên kết thường là điều quan trọng và được thực hiện vì một lý do. nếu tờ khai trao đổi hoặc xếp hàng cần phải thay đổi, có thể có lý do chính đáng cho việc đó và mã không nên tiếp tục với khai báo cũ.