在nservicebus中，如何预防多个消息，以同时处理相同的资源？
我们有一个Nservicebus端点，目前倾听产品交换事件的聆听，并将其中许多更改传达给第三方。
由于事件的数量，我们需要处理，我们已将每个节点扩展到具有多个逻辑处理器的多个节点，但是已经开始遇到一个问题，在该问题中，多个涉及同一产品的消息正在同时处理同一产品，并在第三方系统中引起冲突。
到目前为止丢弃或排队以进行后来重试？
阅读那个传奇可能能够做到这一点，但是我对此并不确定100％，无论如何，这种情况可能对这种情况有过大的杀伤性吗？
我们正在使用SQL Transport，NSB V6
只是为了澄清问题：虽然我们能够同时处理任意数量的消息，但我们不得同时处理两个使用相同产品ID的消息。
We have an NServiceBus endpoint that currently listens for ProductChanged events and communicates a number of these changes to a third party.
Due to the volume of events we need to process we have scaled to multiple nodes with multiple logical processors each, but have started running into an issue where multiple messages referring to the same product are being processed simultaneously and causing conflicts in the third party system.
Up until now we've only made use of the basic messaging features of NServiceBus, what features doesn't have that would allow us to "lock" a particular product ID so that any incoming messages for a product that's currently being processed with either be discarded or queued for a later retry?
Reading https://docs.particular.net/nservicebus/sagas/concurrency it seems that Sagas might be able to do this, but I'm not 100% sure on this and in any case it feels like it might be overkill for this scenario?
We're using SQL transport, NSB v6
Just to clarify the problem: while we're able to process an arbitrary number of messages simultaneously, we must not process two messages with the same product ID simultaneously.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当需要按顺序处理消息时，一次将消息发送到一次，假设消息是逻辑分组的，则消息会话是功能服务总线提供的工作来完成工作。接收器仍然可以扩展并同时处理多个会话，但是在任何给定的会话中，一次只能处理一条消息。
不幸的是，nservicebus不支持会议。 Sagas Soul允许您完成工作，但确实会使解决方案混乱，因为您必须将所有传入的消息存储在Saga的数据（状态）中，并依靠超时来执行这些消息。如果您有少量消息，以其自己的方式并不是那么糟糕。但是，如果消息的数量较大或它们的有效载荷很大，则传奇将成为痛苦点，而不是解决方案。
如果您想在服务总线运输中提供消息会议支持，则可以在功能请求在这里。
When messages need to be processed in order they were sent and one at a time, assuming messages are logically grouped, Message Sessions is the feature Service Bus provides to accomplish the job. The receiver can still scale out and handle multiple sessions concurrently but within any given session only one message will be handled at a time.
Unfortunately, NServiceBus does not support sessions. Sagas soul allow you to accomplish the job but would really clutter the solution because you’d have to store all the incoming messages in the saga’s data (state) and rely on timeouts to execute those. Which, in its own way is not that bad if you have a small number of messages. But if the number of messages is large or their payloads are large, saga becomes a pain point rather than a solution.
If you’d like to have message sessions support in the Service Bus transport, you could upvote the feature request here.