Ví dụ PubSub trong MassTransit

Question

Sau khi đọc qua mẫu dự án pub/sub trong MassTransit, nó khiến tôi gãi đầu.

Trong mẫu, ứng dụng khách xuất bản yêu cầu cho ứng dụng người đăng ký cập nhật mật khẩu của người dùng hư cấu. Mã mẫu này hoạt động tốt và dễ dàng theo dõi quả bóng nảy của dự án này.

HOWEVER--

Trong một môi trường thực tế, mục đích của pub/sub (trong sự hiểu biết của tôi) là phải có một số ít các nhà xuất bản tương tác với một số lượng lớn các thuê bao. Trong trường hợp thuê bao thực hiện bất kỳ loại hoạt động CRUD nào, thì mô hình truyền thông có ngăn được nhiều người đăng ký xử lý tin nhắn không? Nó sẽ ít hơn mong muốn có hai mươi thuê bao cố gắng để cập nhật các bản ghi cơ sở dữ liệu tương tự, ví dụ.

Đây có phải là trường hợp của dự án mẫu không đúng hướng không?

Nếu pub/sub có thể được sử dụng cho các hoạt động CRUD, làm cách nào để bạn định cấu hình khung để chỉ cho phép một người đăng ký thực hiện một hoạt động?

Tôi có hoàn toàn thiếu một số thông tin cơ bản về mục đích của quán rượu/tiểu không?

Thanks cho bất kỳ làm rõ quy ...

David

Answer 1

Kịch bản bạn tham khảo thường được gọi là 'người tiêu dùng cạnh tranh', và khá điển hình của pub/sub.

Nếu mỗi người tiêu dùng có tên hàng đợi riêng, duy nhất, mỗi người tiêu dùng sẽ nhận được bản sao thư của chính nó.

Ngoài ra, để có được cạnh tranh hành vi tiêu dùng, nếu người tiêu dùng chia sẻ tên hàng đợi cùng, sẽ có sự cạnh tranh giữa những người tiêu dùng cho mỗi tin nhắn (vì vậy mỗi tin nhắn sẽ chỉ được nhận một lần)

Answer 2

Bạn có thể có n -to-n, nhiều hoặc ít hoặc nhiều nhà xuất bản cho người đăng ký trong bất kỳ hệ thống pub/sub nào. Nó thực sự là vấn đề bao nhiêu diễn viên bạn muốn trả lời cho một thông điệp nhất định.

Dự án mẫu có thể không phải là tốt nhất, nhưng chúng tôi cảm thấy nó cho thấy những gì đang xảy ra. Tuy nhiên, trong các trường hợp thế giới thực, nó có thể được sử dụng cho các hành vi loại CRUD; tuy nhiên, nhiều dòng dọc theo nhiều dòng giao diện người dùng đang gửi thông báo loại "tải dữ liệu" đến phần mềm trung gian (bộ nhớ đệm) yêu cầu phản hồi cùng một dữ liệu. Nếu dữ liệu đó được cập nhật trên giao diện người dùng bằng cách nào đó, nó phải xuất bản một số thông báo cho biết rằng và nhiều phần trung gian cần phải cập nhật (bộ đệm, cửa hàng phụ trợ, v.v.). [xem CQRS]

Nhắn tin nói chung là nhiều hơn về làm việc với các hệ thống bị ngắt kết nối. Thế giới cụ thể của bạn là nhiều hơn về cấu trúc của người tiêu dùng và nhà xuất bản. Tôi đã nhìn thấy hiện thực của MassTransit, nơi hầu hết các tuyến đường mà tĩnh và nó đã không thực sự pub/sub ở tất cả, nhưng chỉ có rất nhiều gửi cùng một địa hình được biết đến của hệ thống. Thực sự hiểu các khái niệm, cuốn sách hay nhất tôi biết là Enterprise Service Bus: Theory in Practice.

Tôi hy vọng điều này sẽ hữu ích!

Chỉnh sửa: Cũng xem documentation của chúng tôi, một số khái niệm được chạm vào đó.