我的任务是创建一个Web应用程序.我目前正在使用c#& asp.net(mvc-但我怀疑它与问题有关)-是菜鸟开发人员,并且对.net有点陌生.

构建应用程序中的部分逻辑是通过使用请求命中特定的URL来向外部smsgateway发出请求-作为Web应用程序中用户启动的操作的一部分(可能是发送的几条消息),或者作为每天运行的计划任务的一部分(可以并且将发送几千条消息).

对于日常任务,我恐怕在一个线程中循环(例如-10.000次)(尤其是如果im也根据请求的响应采取措施-如写入db)不是最佳策略,并且我可以从某些并行化中获得一些性能/时间节省.

最终,我更担心同时(非常可能)成千上万的用户将执行触发请求的操作.对于一个天真的实现,它为每个请求生成某种后台线程(无论调用什么),我担心一次有成千上万个请求的情况.

所以,如果我的假设是正确的-我该如何处理？我是否必须手动产生一些适当数量的新Thread()并从类似于生产者/消费者的队列中协调其工作,还是有一些简单的方法？

干杯

解决方法:

如果必须向服务发出10,000个请求,则意味着该服务的API是贫乏的-可能是基于CRUD的,被设计为数据库而不是实际服务的精简包装.

对设计良好的服务的单个“请求”应传达执行单个“工作单元”所需的所有信息-换句话说,这10,000个请求很可能合并为一个请求,或至少一小部分的请求.如果请求将发送到远程服务器或可能需要很长时间才能完成(而2-3秒是计算中的极长时间),则这一点尤其重要.

如果您无法控制服务,如果您无法更改规范或API,那么我想您会发现这非常困难.一台机器根本无法一次处理10,000个传出连接；它将与数百人作斗争.您可以尝试并行化,但是即使吞吐量提高了十倍,也要花半小时才能完成,这可能是您不希望在面向公众的网站上运行的任务(但后来,也许您知道,但我不知道具体情况.

也许您可以更具体地了解环境,体系结构以及您要做什么？

响应您的更新(可能有成千上万的用户同时执行一项操作,要求您每个发送一个或两个SMS消息)：

这听起来完全像是您应该使用Message Queuing的情况.设置solution using WCF实际上并不难.使用消息队列的一些主要原因如下：

>有大量消息要发送；
>发送应用程序无法同步发送它们或等待任何形式的响应；
>消息最终必须传递.

您的要求就像手套一样适合.由于您已经在Microsoft堆栈上,因此绝对建议您使用MSMQ支持的异步WCF服务.