MSMQ能否解决多线程服务不足的性能瓶颈
本文关键字：性能瓶颈 服务 多线程 解决 MSMQ | 更新日期: 2024-09-21 06:52:30
我们编写了使用约200个线程的服务。
200线程必须执行：
1-从互联网下载
2-分析原始数据（html、xml、json…）
3-将新创建的数据存储到数据库
对于约10个线程，第二次操作（解析）的运行时间为50ms（每个线程）
对于约50个线程，第二次操作（解析）的运行时间为80-18000毫秒（每个线程）
所以我们有了一个主意！
我们可以以多线程方式下载文档，但使用MSMQ，我们可以将原始数据发送到另一个进程（使用者）。另一个进程将第二部分（解析）实现为单线程。
你们可以说为什么不在同一个进程中使用c#Queue类。。我们无法阻止我们的"宝贵的解析线程"进行线程上下文切换。若同一进程中有200个线程，那个么宝贵的线程将成为上下文切换的牺牲品。
使用MSMQ满足此要求是正常的吗？
是的，这是MSMQ很有意义的一个很好的例子。您可以将困难的工作转移到另一个流程来处理，而不会影响当前流程的性能，因为当前流程显然不关心结果。不仅如此，如果您的新工作进程宕机，队列将保留状态，消息（可能不是宕机时正在处理的消息）不会丢失。
根据您的需求和目标，我会考虑将下载卸载到其他进程，例如将要处理的URL传递到队列。然后，扩展您的系统就像拨打队列接收器一样简单，因为如果正确实现，队列消息将以线程安全的方式接收。
是的，这是正常的。还有一些框架/库可以帮助您构建此类解决方案，为您提供的不仅仅是传输。
NServiceBus或MassTransit就是示例（两者都可以位于MSMQ之上）