维护传出队列中消息的顺序 - .Net
在我的场景中，消息按照预定义的顺序发送。一旦消息进入我们的系统，多个接收者就会从传入队列中获取消息并进行处理。处理完成后，已处理的消息应按照其到达的顺序发送出去。在扩大规模的系统中，我们如何确保这一点？
该系统要求较高的处理速度和吞吐量。在 .net 世界中，哪种队列最适合这种情况？
In my scenario, messages are coming in a predefined order. Once it enters our system, multiple receivers picks up the message from the incoming queue and processes it. Once the processing is done, the processed messages should be sent out in the same order as they had arrived. In a scaled up system, how do we ensure this?
The system requires high processing speed and throughput. In .net world, which queue would be ideal for this scenario?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是关于有序交付的一个基本问题 - 在系统中的某个地方，您需要将所有内容限制为单个线程。这是不可避免的。
您选择在何处执行此操作可能会对吞吐量产生很大影响。您可以选择使整个消息处理器成为单线程。这将确保维持秩序，但代价是吞吐量较低。
但是，有一种方法您仍然可以同时处理消息，但随后您需要以某种方式再次以正确的顺序组装它们。有一种名为 Resequencer 的集成设计模式 - http://eaipatterns.com/Resequencer.html。
然而，重排序器模式依赖于您能够在进入系统的每条消息上标记时间戳或序列号（如果消息中没有任何内容来指示排序）。
此外，从队列传入的整个消息集是否需要按顺序传送？例如，可能只有部分消息需要按顺序传送。
或者，您可以将消息分组到相关标识符下的“集合”中 - 每个集合中的顺序需要维护，但您仍然可以在“每个集合”的基础上进行并发处理。
It's a fundamental problem around ordered delivery - somewhere in your system you need to throttle everything down to a single thread. This is unavoidable.
Where you choose to do this can make a large difference to throughput. You could choose to make your entire message processor single-threaded. This would ensure order was maintained but at a cost of low throughput.
However, there is a way you can still process messages concurrently, but then you need to somehow assemble them in the correct order again. There is an integration design pattern called Resequencer - http://eaipatterns.com/Resequencer.html.
However the resequencer pattern this relies on you being able to stamp each message with a time-stamp or sequence number on the way into your system if there is nothing already in your messages to indicate ordering.
Additionally, is ordered delivery a requirement across the entire message set coming in from the queue? For example, it may be that only some of your messages have a need to be delivered in order.
Or it could be that you can group your messages into "sets" under a correlating identifier - within each set order needs to be maintained but you can still have concurrent processing on a "per-set" basis.