MassTransit 中的 PubSub 示例
读完 MassTransit 中的 pub/sub 项目示例后，我感到摸不着头脑。
在示例中，客户端应用程序向订阅者应用程序发布请求以更新虚构用户的密码。这个示例代码运行良好，并且很容易跟随这个项目的弹跳球。
然而
，在现实环境中，发布/订阅的目的（以我的理解）是让少数发布者与大量订阅者进行交互。在订阅者执行任何类型的 CRUD 操作的情况下，通信模式是否应该阻止多个订阅者处理消息？例如，让二十个订阅者尝试更新相同的数据库记录是不太理想的。
这只是一个被误导的示例项目吗？
如果pub/sub可以用于CRUD操作，那么如何配置框架只允许一个订阅者执行一项操作？
我是否完全错过了有关发布/订阅目的的一些基本信息？
感谢您提供的任何澄清...
大卫
After reading through the pub/sub project sample in MassTransit, it left me scratching my head.
In the sample, the client application publishes a request for the subscriber application to update the password of a fictitious user. This sample code works fine, and it's easy to follow the bouncing ball of this project.
HOWEVER--
In a real-world environment, the purpose of pub/sub (in my understanding) is to have a small number of publishers interacting with a large number of subscribers. In the case of a subscriber performing any sort of CRUD operation, shouldn't the communication pattern prevent more than one subscriber from handling the message? It would be less than desirable to have twenty subscribers attempt to update the same database record, for instance.
Is this just a case of a misguided sample project?
If pub/sub can be used for CRUD operations, how do you configure the framework to only allow one subscriber to perform an operation?
Am I just completely missing some basic info on the purpose of pub/sub?
Thanks for any clarification provided...
David
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您提到的场景通常称为“竞争消费者”，并且是发布/订阅的典型场景。
如果每个消费者都有自己唯一的队列名称，则每个消费者将收到自己的消息副本。
或者，为了获得竞争的消费者行为，如果消费者共享相同的队列名称，则每个消息的消费者之间将会存在竞争（因此每个消息只会被接收一次）
The scenario you refer to is usually referred to as 'competing consumers', and is quite typical of pub/sub.
If each consumer has it's own, unique queue name, each consumer will receive it's own copy of messages.
Alternatively, to get competing consumer behaviour, if consumers share the same queue name, there will be competition between the consumers for each message (so each message will only be received once)
在任何发布/订阅系统中，您都可以有 n 对 n、多对少或少对多的发布者到订阅者。这实际上取决于您希望有多少演员响应给定的消息。
该示例项目可能不是最好的，但我们认为它显示了正在发生的事情。但在现实世界中，它可以用于 CRUD 类型的行为；然而，它更像是许多前端向中间件（缓存）发送“加载数据”类型消息，请求相同数据的响应。如果该数据以某种方式在前端更新，它必须发布一些消息来指示多个中间件需要更新（缓存、后端存储等）。 [请参阅 CQRS]
一般来说，消息传递更多的是与断开连接的系统一起工作。你的特定世界更多地是关于消费者和发布者的结构。我见过 MassTransit 的实现，其中大多数路线都是静态的，根本不是真正的发布/订阅，而是沿着已知的系统拓扑进行大量发送。真正理解这些概念，我所知道的最好的书是 企业服务总线：理论实践< /a>.
我希望这有帮助！
编辑：另请参阅我们的文档，其中涉及一些概念。
You can have n-to-n, many-to-few, or few-to-many publishers to subscribers in any pub/sub system. It's really a matter of how many actors you want responding to a given message.
The sample project might not be the best, but we feel it shows what's going on. In real world cases though, it can be used for CRUD type behaviours; however it's more along the lines of many front ends sending "load data" type messages to middleware (cache) requesting a respond of same data. If that data gets updated on the front end somehow, it must publish some message indicating that and multiple middleware pieces need to update (cache, backend store, etc). [see CQRS]
Messaging in general is more about working with disconnected systems. Your specific world is more about the structure of consumers and publishers. I've seen implementations of MassTransit where most of the routes where static and it wasn't really pub/sub at all but just a lot of sends along a known topography of systems. Really understanding the concepts, the best book I know of is Enterprise Service Bus: Theory in Practice.
I hope this helps!
Edit: Also see our documentation, some of the concepts are touched on there.