理解B/S结构中服务端同步与异步机制的区别，通过使用ASP.Net异步处理节约队列时间成本，解决大并发量问题

 

理解B/S结构中服务端同步与异步机制的区别，通过使用ASP.Net异步处理节约队列时间成本，解决大并发量问题

 

 

为了方便描述问题，这里我们假设当前的请求队列中存在10个请求，而服务器上总共（最大只能）运行4个线程（IIS应用程序池中的最大工作进程数与最大连接数，又称为web园）。因此，队列中的10个请求分别被拆分为：[0,1,2,3]、[4,5,6,7]、[8,9] 共三波请求处理。

 

在传统请求模式中，我们可以把一次请求处理中的CPU、I/O、Databases 三者（为方便描述，这里仅列举这三个常见的运算）合并抽象为一个整体，这个整体便称之为“线程”。

 

每个线程负责完成处理一个http请求，细看中我们会发现，线程中Databases、I/O、CPU的处理时间是不一致的。但是一个线程何时可以结束，取决于Databases、I/O、CPU三者中最长的时间。

 

我们拿第一波请求中的线程0来说事：它的总共需要等待时间是2.9秒，在这当中，CPU计算占据了大部分时间，此时可以把该线程中的CPU计算（耗时最长的）称之为“耗时操作”，因为I/O和Databases都只需要0.3+1秒便完成，问题是在经过1.3秒之后，I/O和Databases便处于挂起状态（空置），剩下的另外1秒钟，整个主线程都是在等待CPU，如此，便严重浪费了时间资源，例如此时数据库连接池处于空挂，也许等待到下一次处理线程时，数据库连接池的某一个连接已经断开，便需再次建立连接。由此也影响了整个队列请求的所需时间与性能。其余各个线程中也存在相同的I/O和Databases空耗问题

有没有什么办法可以解决问题呢？答案是：有，异步。

 

不同于本地程序，服务器端的异步机制所服务的对象是面向整个请求队列，而非具体的某一浏览者（Client Browser），在B/S 结构中，服务端和客户端永远都是同步运行，一个客户端在向同步机制服务器请求一个服务如果所需等待一秒，那么在该服务器改变为异步机制后，请求一个服务还是所需约一秒（不会有可感知的变化），异步机制的受益者仅是服务器本身。

 

异步机制通过解决子线程空耗问题，扩大了在相同线程数量的情况下，可以同时服务的客户端数量。

 

上图是理想状态下的异步模型，实际中，可能因为程序中不可改变的函数加载顺序，三个子线程的执行顺序会有微弱差别，但是不存在总体差异以及异步带来的综合优势依旧存在。

 

在异步机制中，我们可以把各种不同类型的工作拆分为子线程，在这个例子中，主线程被拆分为CPU、I/O、Databases三个子线程。

如图，从第二波请求开始（4、5、6、7），子线程的开始工作时间不再由所属工作主线程的兄弟子线程决定，而是延续自第一波请求（0、1、2、3）的各相同子线程结束时间。由此带来了优势：

 

1.        队列中的各请求可以得到更快的响应。

2.        更加有效地利用了服务器的计算资源。

 

于ASP.NET MVC 4.0中的解决方案：

 

    publicclassAsyncTestData

    {

        publicint Index { get; set; }

 

        publicstring Message { get; set; }

    }

 

    publicclassHomeController : AsyncController//注意继承点

    {

        publicasyncTask<ActionResult> Index()  //异步处理的重点在于async 和 await 结合，以及Task<T>

        {

            var obj = newAsyncTestData

            {

                Message = "Message"

            };

            await waitingFunction();

            return View(obj);

        }

        privateasyncTask waitingFunction()

        {

           //...... 耗时操作

        }

    }