C# MSMQ能否解决out多线程服务的性能瓶颈？

我们使用大约200个线程编写了服务

200个线程必须执行以下操作：

1-从互联网下载

2-解析原始数据（html、xml、json…）

3-将新创建的数据存储到数据库

对于约10个线程，第二次操作（解析）的运行时间为50ms（每个线程）

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

所以我们有了一个想法

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

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

---

使用MSMQ满足此要求是正常的？

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

---

根据您的需求和目标，我会考虑将下载卸载到另一个进程，以及将URL传递到队列中。然后，扩展您的系统就像拨打队列接收器一样简单，因为队列消息在正确实现时以线程安全的方式接收。

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

---

NServiceBus或MassTransit就是这样的例子（两者都可以位于MSMQ之上）

这并不能解决任何问题，这样的流程也只能争夺处理器。事实上，这使得线程上下文切换的成本更高。您必须将数据发送到完全不同的机器。MSMQ在这方面很好。尽管网络延迟现在很可能要了你的命。解析是一个整数问题，不要创建超过处理器核心的线程。创建更多，你只会放慢速度。我们的第一次测试表明，当我们将步骤分配到不同的流程时，有一定的改进。我们将发送详细信息。谢谢