问题
曾几何时，我编写了一个内部应用程序来从内部数据库中读取数据，然后获取该数据并将其发布到Web服务。使用单个线程和同步HTTP请求，应用程序非常简单。
此应用程序的范围现已发生变化，并且正在尝试推送比预期更多的数据。如果它从我们的内部数据库中读取1,000条记录，它会将它们全部包装到单个HTTP POST中，从而给承载接收数据的Web服务的服务器带来沉重的CPU负担。当Web服务在处理POST中的一个记录时遇到错误时，也会出现问题。 XML响应未指定哪个特定记录失败，因此我对请求成功的可见性有限。
我想如何修复
我将重新设计我的应用程序，以便更加可靠，更体贴托管Web服务的服务器。具体来说，我希望有一个工作人员每15分钟从内部数据库收集一次记录并将其转换为工作。这些作业将被序列化并存储在队列中（可能是数据库表）。然后我想让我的应用程序使用几个工作线程处理队列（这是个好主意吗？）。线程会将作业从队列中弹出，并通过向Web服务上游进行异步HTTP POST来处理它。根据请求的状态，作业将导致成功，失败，超时或中止。作业将在数据库中更新，将记录该进程，然后工作线程将继续执行下一个作业，如果作业队列为空，则变为空闲。
我不是建筑师，所以我不知道实现这样的事情的最佳方法。以下是我对设计的一些具体问题。
我知道这是一个广泛的问题，但我希望我已清楚地概述了我的目标。提前谢谢。
答案 0 :(得分：3)
您是否考虑过MSMQ？您可以推送队列中的消息，每N分钟读取一个消息，并在发生任何电源故障时内置冗余等。如果您处于负载平衡环境，则可以发布到共享队列。
回答问题：
我已经阅读了一些关于.NET MVC环境中多线程的负面信息。我应该避免使用多个线程，因为我没有做任何真正占用CPU的事情吗？
建议您不要在ASP.NET中使用ThreadPools，因此同样适用于MVC。它可以限制你的应用程序。
Quartz.NET看起来可以做很多很酷的事情。我应该考虑使用Quartz.NET吗？
这可以替代调度而不是队列，类似于cronjobs。
我的设计合理吗？如果没有，怎么可以改进？
序列化部分听起来很棒，SUCCESS，FAILURE，TIMEOUT或ABORTED部分听起来不错。如上所述，MSMQ将为您节省编写冗余和消息队列系统的麻烦。
您如何设计系统以满足新应用程序的目标？
一种服务，它经常从消息队列中读取并执行您希望它执行的操作。您还可以查看SQL Server Message Broker作为MSMQ的替代方案。 MSMQ没有很好的内置工具来管理它，所以你需要在它之上构建。但是，它在内置框架中有一个完整的.NET程序集用于使用它。
当您使用.NET 4时，您也可以从并行任务中受益，而不是系统的HTTP发送部分的手动线程管理。