MSMQ 能否解决多线程服务的性能瓶颈？答案

【问题标题】：Could MSMQ resolve performance bottleneck of out multithreaded services?MSMQ 能否解决多线程服务的性能瓶颈？
【发布时间】：2014-01-02 01:42:42
【问题描述】：

我们编写了使用 ~200 个线程的服务。

200 线程必须做：

1- 从网上下载

2- 解析原始数据（html,xml,json...）

3- 将新创建的数据存入db

对于约 10 个线程，第二次操作（解析）所用时间为 50 毫秒（每个线程）

对于约 50 个线程，第二次操作（解析）所用时间为 80-18000 毫秒（每个线程）

所以我们有一个想法！

我们可以将文档下载为多线程，但使用 MSMQ 我们可以将原始数据发送到另一个进程（消费者）。另一个进程将第二部分（解析）实现为单线程。

您可以说为什么不在同一进程中使用 c# Queue 类。我们无法阻止线程上下文切换中的“宝贵解析线程”。如果同一个进程中有 200 个线程，那么珍贵的将是上下文切换的牺牲品。

这个需求使用MSMQ正常吗？

【问题讨论】：

这并不能解决任何问题，这样的进程也会竞争处理器。事实上，它使线程上下文切换变得更加昂贵。您必须将数据发送到完全不同的机器。 MSMQ 对此很有用。尽管网络延迟现在很可能会杀死您。解析是一个整数问题，永远不要创建比处理器内核更多的线程。创造更多，你只会放慢速度。
首次测试表明，当我们将步骤分配到不同的流程时，会有一定的改进。我们将发送详细信息。谢谢。

【解决方案1】：

是的，这很正常。还有一些框架/库可以帮助您构建此类解决方案，为您提供的不仅仅是传输。

NServiceBus 或 MassTransit 是示例（两者都可以位于 MSMQ 之上）

【讨论】：

【解决方案2】：

是的，这是一个很好的例子，说明 MSMQ 很有意义。您可以将困难的工作转移到不同的流程来处理，而不会影响当前流程的性能，而这显然不关心结果。不仅如此，如果您的新工作进程宕机，队列将保留状态，并且消息（可能在宕机时正在处理的消息除外）不会丢失。

根据您的需求和目标，我会考虑将下载任务也转移到其他进程 - 例如，将要处理的 URL 传递到队列。然后，扩展您的系统就像拨打队列接收器一样简单，因为正确实施时，队列消息会以线程安全的方式接收。

【讨论】：