线程没有太深的理解，请问等待请求结果的时候接口请求的线程会释放不参与调度么，然后等到接口调用回来再唤醒执行下去？如果是这样我的理解其实高并发请求的影响就很小了，如果忽略除接口外的其他执行时间，iis的队列很快被处理，本身iis队列长度也可以到60000，有必要使用数据库存储请求，然后开window服务来处理，最后提供一个查询接口然用户异步获取结果的么？

@周念中: 最后是用户调用接口时直接返回生成一个异步任务.

用户再循环查询任务结果.

不然会因为连接时间太长.导致连接不稳定,

@吴瑞祥: 恩 好的 理解了 这里是用异步任务来做的和把请求存在数据库服务来跑是一个道理，还有请问一下，因为iis有最大的工作线程数，这个异步任务会不会占用iis的工作线程，如果会的话会让后面排队的请求就会长时间等待，后续的请求还会被直接拒绝掉，我最想了解的是这个。还望解答一下，非常谢谢！

@吴瑞祥: 可能我说的不太清楚，举个例子，如果第三方的接口调用需要耗费5s并且iis最大工作线程数为10个，如果我们采用异步接口调用，然后直接返回给用户说请求处理中，那么请求的主线程很快结束释放，这样会不会后面服务器中的十个全是等待第三方接口返回的线程，新的线程无法处理。还是说第三方接口调用的线程不会一直占用iis的工作线程，会被放入线程池回调回来之后才会被唤醒，等待期间不占用iis工作线程资源？麻烦解答下多谢啦

@周念中: 所以我以前是会有一个消息处理平台的.在接口里发出一个消息.在消息处理平台处理的.

@吴瑞祥: 多谢啦 我也考虑用消息队列或者直接落地数据库然后通过job轮询方式执行，不过看http://www.cnblogs.com/xishuai/p/asp-net-async-await-and-exception-handling.html里面说的异步等待的时候是没有线程产生的，我就觉得也许单从性能上来说没必要用消息队列和job轮询方式，我先试试吧。

@周念中: 他说的是等待的时候没有新线程.但新的TASK一定是个新线程.

而且这个也不是性能问题,这么点性能开销完全可以无视.重要的是系统结构问题.

@吴瑞祥: 嗯嗯 好的 谢谢啦