高并发和大数据时代ASP.NET程序员何去何从？

IT刀客

写这篇文章的初衷在于最近和一些公司的技术负责人的一些交流，发现很多人对高并发和大数据只是一个粗浅的认识，因此很想对此发表些看法。
现在各种关于高并发和大数据的应用被媒体和技术圈的人炒得热火朝天，但是国内真正接触过高并发和大数据的技术从业人员远没有现在雨后春笋一样搞大数据和高并发的公司多。在国内有大数据环境和经验的公司我们屈指可数，包括阿里、百度、360奇虎、各种社区论坛、门户网站、大型网络游戏、联想等这类实业公司、移动、联通等这些国企。剩下的公司，又有多少公司有机会接触真实环境的高并发？诚然，我是不否认有很多人是基于自己对知识的渴求，从多种渠道获取一些高并发和大数据的知识，但真正的真实应用环境，就不是那么多人能有幸体验了。

微软最近几年来层出不穷的跟随JAVA搞敏捷开发，目的在于提高企业开发的交付能力。但是凡事总是有两面性的，提高了交付能力却与如今的高并发和大数据相去甚远了，甚至毫不客气的说是南辕北辙，事与愿违。我们不妨先从理论层面讨论一下并发机制，有了对并发的基本认识，再回头来看看MVC、ORM之类的东西是否真的是含金量那么高。

首先，我们先给出一个结论：并发数取决于两个基本因素------1、APP执行周期；2、分布式处理能力。接下来我们分别讨论这两个因素。
程序执行周期或者叫做请求处理的执行周期，因为并发是指单位时间内能够处理的请求数。那么问题来了，我们假设1秒内某服务器处理请求的数量为100，也意味着这台服务器处理并发的能力为100，那么在并发指数中的周期向量的作用就体现出来了。也就是说每个请求需要执行10ms，这10ms可能要分配到网络传输、内存调度、CPU执行周期、硬盘寻道时间、I/O等环节。我们经常会发现在我们执行SQL的时候，有些SQL需要执行长达1分钟甚至更多的时间，这就严重影响了并发能力，所以技术主管会要求你优化SQL查询。那么，如果我们一个请求优化之后，只需要1ms就能执行完，理论上，我们以上面的环境不变情况下服务器的并发数可以达到1000了。在操作系统中处理任务是单线程的（姑且这么说），也就是操作系统会在并发的任务中不断的切来切去。OS中有一个基本算法，叫做“哲学家进餐算法”，这个算法假定一帮哲学家围坐在一张圆桌周围，但每个哲学家只有一根筷子，要想就餐必须使用自己左边或者右边哲学家的一根筷子。有了这个基本的认识，你就知道提高程序执行周期，也就是提高程序性能在并发中是多么重要了。尽管现在CPU是多核的，但再多核，对于单核心的处理能力，也只能是串行执行的。多核心我们可以看作是分布式，下面将会讨论分布式。
上面的分析，我们可以得出结论：在ASP.NET中大家热衷的EF之类的ORM在性能上与直接ADO.NET相比，其并发能力不言而喻了。所以，在如今要求高并发的技术环境下，请不要再讨论所谓的性能无所谓论调了。

其次，我们接着说说分布式对并发的影响。还以刚才的例子作为参照，如果你一台机器的并发数是100，在你没有对你的程序做优化的前提下，那么理论上你两台机器的并发数可以达到200。如果考虑到并发指数的第一个向量----执行周期的话，如果你单台服务器的并发可以达到1000，那么在1W台甚至更多服务器的时候，这个优化新增的并发能力是可观的，惊人的。

在分布式上，web应用程序做分布式，数据库也做分布式，那这个并发能力会更高。在windows服务器上，微软已有自带的负载均衡工具NLB，可以在管理工具中添加。也可以使用俄罗斯人编写的Nginx，这是一款非常不错的轻量级高性能的负载均衡工具。分布式的具体实现不是本文要介绍的重点，大家可以自行搜索和研究，在这里就不展开了。

我们知道，计算机中读写基本是靠内存来做中转的，在提高并发能力方面，如果我们能够直接读取内存而不是通过内存提交请求然后让CPU去处理从物理硬盘获取数据再载入内存，最后提交到网络最后到客户端的话，将会大大减少请求执行周期，相应的增加了并发数，提高了并发能力，这就是缓存的作用。我们知道IIS有一个缓存机制，ASP.NET的进程能够缓存页面。但是这个缓存能力太小了，于是我们求助于分布式缓存，例如memcashed,redius等，将数据库数据中的热数据放在分布式缓存中，这大大缩短了服务器的响应周期，提高了并发能力。

综上，任何技术都必然有它的理论基础，在了解理论基础的情况下，我们自然有了解决问题的方向，才能朝着这个方向前进。
本篇文章就简单的介绍到这里，意在抛砖引玉，让对高并发和大数据感兴趣但却无从下手的朋友有一个基本的努力方向。