MSMQ 按相关 ID 接收
我们有一个核心系统，通过 MSMQ 与其客户端和其他内部系统进行异步通信。这是一个很好的选择，因为客户端是发送短信的移动电话，而其他系统具有 MQ 适配器。默认情况下，这些通信过程也是异步的。
现在我们需要支持其他需要默认同步通信方式的系统。一个典型的例子是手持设备，它支持通过 HTTP 进行 RPC 样式的请求/响应通信。
有一个解决方案建议通过添加一个 HTTP“代理”/端点来支持这一点，该端点将从这些客户端接收到的消息推送到具有相关性的入站队列，然后在出站队列中查找具有相同相关性的消息。希望消息处理完成并且具有预期相关性 ID 的消息将出现在出站队列中。这将发生在将消息推送到核心系统以模拟请求响应的同一线程上。
然而我们发现通过correlationId（MessageQueue.ReceiveByCorrelationId）接收消息是一个性能杀手。不需要很多客户端线程就可以真正减慢系统速度。
我想问题是这里的问题是使用通过correlationid 接收方法来模仿同步请求响应的提议设计。在当前的体系结构中，出站队列驻留在远程主机上，请阅读此内容以查看是否存在问题。
有没有人有其他方法来解决这个问题？我猜逻辑是将消息从出站队列填充到数据库或单个接收进程中的某些内容，然后搜索具有相应correlationId的消息
We have a core system which communicates with its clients and other internal systems async through MSMQ. This is a good fit since clients are mobile phones sending sms’es and other systems has MQ adapters. Also these communication processes are asynchronous by default.
Now we have a requirement to support other systems which require a synchronous communication style be default. A typical example of this would be a handheld device, which supports rpc style request/response communication over HTTP.
There has been an solutions proposal to support this by adding a HTTP “proxy”/endpoint that pushes messages received from these clients on to inbound queue with a correlationId and then looks in outbound queue for a message with the same correlationId. Hopefully the processing of the message is done and the message with the expected correlationId will be present in the outbound queue. This would happen on the same thread as pushed the message in to the core system to mimic request response.
However we see that receiving messages by correlationId (MessageQueue.ReceiveByCorrelationId) is a performance killer. It does not take many client threads to really slow the system down.
I guess the problem is the proposed design with mimicking sync request-response using receive by correlationid approach is the issue here. In current architecture the outbound queue resides on a remote host, been reading up on this to see if that is the issue or not.
Does anyone have any other approaches for solving this? I guess the logical ting would be to stuff messages from outbound queue to a database or something from a single receiving process and then search that for messages that has the corresponding correlationId
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用 RPC 执行远程接收，速度不是特别快，但应该还可以。
当您添加游标的使用（在本例中是在队列中搜索具有所需correlationID的消息）时，性能肯定不会很好地扩展，正如您所发现的那样 - 更多的客户端通常意味着更多的消息并导致速度减慢因为光标必须进一步移动。
您肯定想在本地队列上进行这种搜索。
让后端多播出站队列中的消息怎么样？
然后，通常会远程接收出站队列消息的所有服务器都可以发送一份副本，该副本将进入本地队列以进行 ID 匹配。
干杯
约翰·布瑞克威尔
Performing a remote receive uses RPC and is not particularly quick but should be OK.
When you add the use of cursors (in this case to search through the queue for the message with the desired correlationID) then performance will definitely not scale too well, as you are finding - more clients usually means more messages and a resulting slow-down as the cursor has to move further.
You definitely want to do this sort of searching on a local queue.
How about getting the getting the back-end to Multicast the messages in the outbound queue?
Then all servers that would normally remotely receive the Outbound queue messages can instead be sent a copy which would go into a local queue for ID-matching.
Cheers
John Breakwell