在阅读完 MassTransit 中的 pub/sub 项目示例后，我摸不着头脑。
在示例中，客户端应用程序向订阅者应用程序发布请求以更新虚拟用户的密码。此示例代码运行良好，并且很容易跟随这个项目的弹跳球。
但是——
在现实环境中，发布/订阅的目的（在我的理解中）是让少数发布者与大量订阅者进行交互。在订阅者执行任何类型的 CRUD 操作的情况下，通信模式不应该阻止多个订阅者处理消息吗？例如，让 20 个订阅者尝试更新相同的数据库记录是不太可取的。
这只是一个被误导的示例项目吗？
如果发布/订阅可用于 CRUD 操作，您如何配置框架以仅允许一个订阅者执行操作？
我只是完全错过了一些关于发布/订阅目的的基本信息吗？
感谢您提供的任何澄清...
大卫
【问题讨论】：
标签： c# esb masstransit
您所指的场景通常被称为“竞争消费者”，并且是非常典型的 pub/sub。
如果每个消费者都有自己的唯一队列名称，那么每个消费者都会收到自己的消息副本。
或者，为了获得竞争的消费者行为，如果消费者共享相同的队列名称，那么消费者之间将竞争每条消息（因此每条消息只会被接收一次）
【讨论】：
您可以在任何发布/订阅系统中为订阅者提供 n 对 n、多对少或少对多的发布者。这实际上是您希望有多少参与者响应给定消息的问题。
示例项目可能不是最好的，但我们认为它显示了正在发生的事情。但在现实世界的情况下，它可以用于 CRUD 类型的行为；然而，它更像是许多前端向中间件（缓存）发送“加载数据”类型的消息，请求响应相同的数据。如果该数据以某种方式在前端更新，它必须发布一些消息，指示多个中间件需要更新（缓存、后端存储等）。 [见CQRS]
一般来说，消息传递更多的是与断开连接的系统一起工作。您的特定世界更多地是关于消费者和出版商的结构。我已经看到了 MassTransit 的实现，其中大多数路线都是静态的，它根本不是真正的 pub/sub，而是沿着已知的系统拓扑结构发送的很多。真正理解概念，我知道的最好的书是Enterprise Service Bus: Theory in Practice。
我希望这会有所帮助！
编辑：另见我们的documentation，其中涉及一些概念。
【讨论】：