MassTransit 中单个队列的多个消费者
是否可以让多个消费者侦听单个 MSMQ 实例并使用选择性消费者接口让每个消费者处理不同的消息子集？我似乎无法使用 pub/sub 使此场景正常工作 - 队列上的单个消费者工作正常，但是当使用 > 1 个消费者（同一可执行文件的多个实例）时，任何地方都不会出现消息。据我了解，这不是“竞争消费者”的情况，因为只有一个消费者会处理一条消息。
任何帮助或指示表示赞赏。
Is it possible to have several consumers listening on a single MSMQ instance and use the Selective Consumer interface for having each one deal with a distinct subset of the messages? I can't seem to get this scenario to work correctly using pub/sub - a single consumer on the queue works fine, but when using >1 consumers (several instances of the same executable) no messages appear anywhere. As I understand it, this is not the case of 'competing consumers', since only a single consumer will process a single message.
Any help or pointers are appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您使用 MassTransit 从 MSMQ 队列调度消息，建议该队列位于设备本地。
话虽这么说，如果您有多个进程从同一队列中读取数据以分配消息负载，则可以使用选择性接收来仅使用每个实例中与该进程相关的消息。
例如，如果您有多个向服务发送消息的应用程序实例，并且该服务以相关消息进行响应，则您可以通过标识符订阅相关消息，并且只会传递那些订阅的消息。未选择的消息将保留在队列中，直到由任何感兴趣的进程处理。
由于这种模式，强烈建议对消息设置过期时间，以便被忽略的响应不会随着时间的推移而堵塞队列。
通过消息传递复制请求/响应模式时，这种情况非常常见。
If you are using MassTransit to dispatch messages from an MSMQ queue, it is recommended that the queue is local to the box.
That being said, if you have multiple processes that are reading from the same queue for the purposes of distributing the message load, you can use the selective receive to only consume messages in each instance that are relevant to that process.
For example, if you have multiple instances of an application that send messages to a service and that service responds with a correlated message, you can subscribe to the correlated message by identifier and only those subscribed messages will be delivered. The messages that are not selected will remain in the queue until processed by any of the processes that are interested.
Because of this pattern, it is highly recommended that an expiration be set on the message so ignored responses do not clog up the queue over time.
This scenario is pretty common when replicating a request/response pattern via messaging.