一口气看完了《高并发Web系统的设计与优化》，感觉受益匪浅，作者从高并发开始讨论问题，并逐步给出了非常有建设性的想法和建议，是值得我们进一步去思考的。我们都知道，高并发必然带来服务器的高压力，高压状态下单个服务器随时可能宕机，减少压力的性价比较高的办法就是分而治之（提升系统硬件就不说了），如何分便是相当困难的课题，这不是简单的一个1变2,2变4的过程，这是整个系统架构顺势变迁的一段艰苦历程，看过myspace系统变迁那篇文章的人就会明白这段历程是痛苦的、是紧张的、是激烈的、是精彩的、是兴奋的。要做好它，必须脚踏实地，不得不承受各种工作压力，还要有丰富的想象力，整个团队成员，他们不仅仅是工程师，还是艺术家，更是一群精力旺盛、百折不挠的海盗。

 

1、关键词：分离。

一台服务器的能力始终有限，即使能够纵向扩展，那也要面对资金和硬件技术的考验，而且往往这种扩展投入大收益小，性价比不高。于是当服务器出现压力时，有人想到了用分离的办法，分离的办法就多了，主要是根据压力级别来确定：

较简单一点就是各个服务的分离，如原来是web和数据库同在一台服务器上，现在可以考虑将web和数据库都分别放在单独的服务器上，也就是只需要两台服务器就可以完成分离工作。

也可以对单一服务的分离，可以根据功能模块（用户注册，结算中心等）来分离web服，数据库方面可以考虑数据组的读写分离，数据本身的分区等。

还可以将公共模块分离，比如电子书店类型网站的在线浏览功能就可以作为一个独立模块划分，必要时数据库也能跟着一起，数据本身也可以分离，比如网站图片和文件下载等，另外还可以考虑在数据层上面建立一个数据中心，用来统一调度各类型的数据资源。

 

 

2、关键词：缓存。

记得在某年的数据库大会上，盖国强老师就在它的PPT写到：缓存为王。虽然是数据库的大会，但这个口号是适合整个系统架构。

在一个内存速度数倍于磁盘速度的大环境下，没人会质疑内存对数据处理的速度，但是它和磁盘不一样的是前者是易失性的（断电即丢失数据），容量相对于磁盘也小很多，因此使用它的时候需要一种机制，人们也在不断完善这种机制，该考虑能缓存些什么了。

最容易想到的是所有静态的东西，如web中的图片、css、js以及数据库中的只读数据，内存容量不大怎么办呢？（也不可能够）加入换出机制，比如FIFO、LRU等。

对于需要更新的非静态数据，比如web中的动态网页和数据库中需要被修改的表，前者需要在设计时就定义好能够缓存的相对静态的片段，比如天气预报部分，至少能保留一天吧。后者则可以通过添加日志或者磁盘副本来保证数据的修改不易丢失。

目前对静态文件的缓存比较好的软件如squid、varnish。数据库方面的缓存如Oracle的Timesten。

 

 

3、关键词：虚拟化

在低使用率下，虚拟化能提供纵向的服务器分离，即一台服务器上跑多个虚拟服务器。在高压力环境下，虚拟化则能提供纵向的服务器扩展，即多个服务器提供某一个服务。在纵向扩展的虚拟化服务器群里分两类。

第一类：每台服务器并没有特定的服务或功能，功能在它们之上，它们只提供资源本身，因此这就要求虚拟化的软件足够彪悍，不仅能高性能的使用好整个资源库，而且还能做好负载均衡、故障转移、数据迁移、避免热点等工作。相关的软件如VFS、memcached、BigTable、数据库群集等。

第二类：部分服务器拥有相同的功能，能提供相同的服务，在它们前端会有一台或多台服务器提供类似反向代理的服务，请求由前端接收，只经过简单处理后就将请求抛给后端的服务器，而对请求的大部分处理是在后端完成，前端的主要工作是负载均衡、故障转移等。目前web反向代理比较好的软件有nginx。

 

 

4、关键词：细节

俗话说得好，细节决定成败。架构设计的成败不仅仅在宏观上，从微观的层面依然重要，不能认为web服务分离了，数据库服务分离了，数据用了虚拟化分布式就可以一劳永逸高枕无忧了。其实真正最难的工作是如何能确定你现在所做一切以及将来要做的是必要的。

相信每个人告诉你的：你的老板是世界上最抠门的动物。他们不会傻乎乎的给你钱，让你搞这些看上去“乱七八糟”的东西，因此你要有足够的实力来证明，如何证明？你可以告诉他IIS或者Apache的配置已经在性能上最大承受我们的系统了，你可以告诉他数据库该优化的地方已经都优化过了，你可以告诉他现在系统的IO平均等待队列这个关键性能指标已经位于红色位置了。然而要告诉他这些之前你需要做的是：扎实的技术沉淀、细心的监控观察、足够的统计数据和富有远见的扩展计划（得要老板给钱给得开心啊）。

 

 

总的来说，有很多值得思考的地方，但是再好的也难以抵挡今天晚上德国队对乌拉圭队比赛的诱惑，先写到这儿，散了。