【架构】傻瓜都能看懂的高并发量服务器架构

先普及一下基础知识：

一、硬件条件。确认服务器硬件是否足够支持当前的流量，一台普通的P4服务器一般最多能支持每天10万独立IP，如果访问量比这个还要大，那么必须首先配置一台更高性能的专用服务器才能解决问题，另外就是增加服务器数量，否则怎么优化都不可能彻底解决性能问题。

二、数据库。优化数据库访问前台实现完全的静态化当然最好，可以完全不用访问数据库，不过对于频繁更新的网站，静态化往往不能满足某些功能。缓存技术就是另一个解决方案，就是将动态数据存储到缓存文件中，动态网页直接调用这些文件，而不必再访问数据库，WordPress和Z-Blog都大量使用这种缓存技术。如果确实无法避免对数据库的访问，那么可以尝试优化数据库的查询SQL，避免使用 Select * from这样的语句，每次查询只返回自己需要的结果，避免短时间内的大,尽量做到"所查即所得" ,遵循以小表为主,附表为辅,查询条件先索引,先小后大的原则,提高查询效率.量SQL查询。

三、禁止盗链。外部网站的图片或者文件盗链往往会带来大量的负载压力，因此应该严格限制外部对于自身的图片或者文件盗链，好在目前可以简单地通过refer来控制盗链，Apache自己就可以通过配置来禁止盗链，IIS也有一些第三方的ISAPI可以实现同样的功能。当然，伪造refer也可以通过代码来实现盗链，不过目前蓄意伪造refer盗链的还不多，可以先不去考虑，或者使用非技术手段来解决，比如在图片上增加水印。

四、控制大文件的下载。大文件的下载会占用很大的流量，并且对于非SCSI硬盘来说，大量文件下载会消耗 CPU，使得网站响应能力下降。因此，尽量不要提供超过2M的大文件下载，如果需要提供，建议将大文件放在另外一台服务器上。

五、镜像分流。将文件放在不同的主机上，提供不同的镜像供用户下载。比如如果觉得RSS文件占用流量大，那么使用FeedBurner或者FeedSky等服务将RSS输出放在其他主机上，这样别人访问的流量压力就大多集中在FeedBurner的主机上，RSS就不占用太多资源了。

六、做好流量监控。在网站上安装一个流量分析统计软件，可以即时知道哪些地方耗费了大量流量，哪些页面需要再进行优化，因此，解决流量问题还需要进行精确的统计分析才可以。推荐使用的流量分析统计软件是Google Analytics（Google分析）。

接下来我们来说说服务器架构，前段时间我们请到了国内服务器顶级攻城狮，他把服务器那点事讲得非常通透简单。对于一个刚起步的创业公司，不需要考虑太多复杂的服务器架构，能把业务跑起来就行了。但是在早期业务逻辑设计时，懂一些稍微复杂的服务器架构的逻辑，后面可以少走很多弯路。

下面这个图估计大家都明白，这就是最基础的服务器架构。傻瓜式的方法是把应用服务器、文件服务器、数据库服务器全部混合在一起，呵呵呵！但这并不是最科学的。

当业务量持续增加到一定量以后，执行应用程序、读写文件、访问数据库应该有所区分，保证各自的需求都能得到满足，这时候你需要考虑把应用服务器、文件服务器、数据库服务器分离，这个时候的服务器架构应该是下面这样的，它是由三个独立的服务器组成，各司其职。

随着业务量持续增加，应用程序访问缓存数据会成为瓶颈，这个时候需要增加本地缓存，有的也需要分布式缓存。分布式缓存是指缓存部署在多个服务器组成的服务器集群中，以集群的方式提供缓存服务，其架构方式主要有两种，一种是以JBoss Cache为代表的需要同步更新的分布式缓存，一种是以Memchached为代表的互不通信的分布式缓存。如下图：

接下来，需要更多台应用服务器以应对复杂的业务逻辑，同时需要负载均衡调度服务器来调度和分配应用服务器的工作任务。

再往后，需要考虑数据库服务器的承压能力，通常可以采用主从式数据库服务器架构，把读、写两部分分开，既可以提高数据访问的安全性，也能提高数据读写的效率。

随着业务量暴增，单一区域的服务器带宽将不能承载全国的业务需求，这时候需要增加反向代理和CDN服务器。CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。