1. 名词解释
1.1 并发访问量
并发访问量 = 单位时间平均访问量（次/秒）X 单次请求平均处理时间（秒/次）
1.2 负载均衡
负载均衡有两方面的含义：
1）大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间；
2）单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。
通常，负载均衡会根据网络的不同层次（网络七层）来划分。其中，第二层的负载均衡指将多条物理链路当作一条单一的聚合逻辑链路使用，这就是链路聚合（Trunking）技术，它不是一种独立的设备，而是交换机等网络设备的常用技术。现代负载均衡技术通常操作于网络的第四层（传输层）或第七层（应用层），这是针对网络应用的负载均衡技术，它完全脱离于交换机、服务器而成为独立的技术设备。
2 网络层架构
2.1 镜像网站技术
镜像网站是指将一个完全相同的站点放到几个服务器上，分别有自己的URL，这些服务器上的网站互相称为镜像网站。
优点：网站备份
缺点：1）需要同时更新多个服务器的内容；2）用户自主选择服务器，不一定是最优的；3）在用户选择缺乏可控性，不能最有效地均衡负载。
2.2 CDN（内容分发网络）
优点：1）网站备份；2）网站代替用户选择内容服务器，增强了可控性
缺点：1）因为内容更新时需同步多台镜像服务器，所以只适用于内容更新不太频繁，或实时性要求不是很高的网站；其次，当某一镜像网站转移时，各地的DNS会滞后一段时间更新，可控性依然有不足。
2.3 应用层分布式设计
新浪播客提供了一个供播放器查询视频文件地址的接口。当用户打开视频播放页面的时候，播放器首先连接查询接口，通过接口获得视频文件所在的最优的镜像服务器地址，然后再到该服务器去下载视频文件。
优点：1）网站备份；2）对镜像网站具有完全的可控性
缺点：不适用于内容更新比较频繁的服务器
3 交换层架构
第四层交换 -> 硬件实现、软件实现
4 服务器优化
4.4.1 服务器整体性能考虑
常见的影响服务器处理速度的因素有：网络连接，硬盘读写，内存空间，CPU速度。服务器想要发挥最大的功效，关键的是消除瓶颈。
网络：
4.2 Socket优化
影响TCP/IP 栈性能的可调节内核参数。。。
磁盘读写：
4.3 硬盘级缓存
硬盘级别的缓存是指将需要动态生成的内容暂时缓存在硬盘上，在一个可接受的延迟时间范围内，同样的请求不再动态生成。Linux环境下硬盘级缓存一般使用Squid。
Squid是一个高性能的代理缓存服务器。它的原理是，当用户通过浏览器想下载（即浏览）一个web页面时，浏览器请求Squid为它取得这个页面。Squid随之连接到页面所在的原始服务器并向服务器取得该页面。然后Squid再将页面返回给用户端浏览器，并且同时在Squid本地缓存目录里保存一份副本。当下一次有用户需要同一页面时，Squid可以简单地从缓存中读取它的副本，而不用再次请求原始服务器。
4.4 读写分离
如果网站的硬盘读写性能是整个网站性能提升的一个瓶颈的话，可以考虑将硬盘的读，写功能分开，分别进行优化。在专门用来写的硬盘上，我们可以在Linux下使用软件RAID，而专门用来读的硬盘，则可以使用普通的服务器硬盘。
内存：
4.5 内存级缓存
内存级别的缓存是指将需要动态生成的内容暂时缓存在内存里，在一个可接受的延迟时间范围内，同样的请求不再动态生成。Linux环境下内存级缓存Memcached是一个不错的选择。
CPU：
4. CPU与IO均衡
在一个服务器集群中，当我们发现某些机器上CPU和IO的利用率相差很大的时候，可考虑将该服务器上的某些耗CPU资源的进程换成耗IO的进程，以达到均衡的目的。
5 应用程序层优化
5.1 网站服务器程序的选择
Apache——开源界的首选Web服务器。它的功能强大且可靠，而且适用于绝大部分的应用场合。但是它的强大有时候却显得笨重，配置文件复杂得让人望而生畏，高并发情况下效率不太高。
Lighttpd——轻量级的Web服务器，却是后起之秀。基于单进程多路复用技术，其静态文件的响应能力远高于Apache。 Lighttpd对PHP的支持也很好，还可以通过Fastcgi方式支持其他的语言，比如Python等。
可以考虑将Lighttpd放在Squid的前面，构成 Lighttpd->Squid->Apache的一条处理链。Lighttpd专门处理静态内容，Squid中有该请求的内容且没有过期则直接返回给Lighttpd，新请求或者过期的页面请求交由Apache来处理。这样的构架可以减少了Web应用程序的压力，同时便于把不同的处理分散到多台计算机上进行。
5.2 数据库选择
MySQL是Linux下网站开发的首选。
5.3 服务器端脚本解析器的选择
目前最常见的服务器端脚本有三种：ASP(Active Server Pages)，JSP(Java Server Pages)，PHP (Hypertext Preprocessor)。
在Linux下我们其实还有很多其他的选择：Python（Google使用），Perl等。使用这些不太常见的脚本语言的好处是，它们对于某些特殊的应用有别的脚本所不具有的优势；不好的地方是相关资料较少。
5.4 可配置性
在大型网站开发过程中，不管使用什么技术，网站的可配置性是必须的。
首先，也是最重要的一点，功能和展示必须分开。
再次，对于核心功能脚本，必须与服务器相关的配置内容（如数据库连接配置，脚本头文件路径等）及代码分离开。
最后，应该尽量做到修改配置文件后能实时生效，避免修改配置文件之后需要重启服务程序的情况。
5.5 封装和中间层思想
在功能块层次，如果使用JSP，则会基于语言的特征自然封装。如果使用PHP，则需要在脚本代码中显式的封装，将每一个功能块封装成一个函数，一个文件或者一个类。
在更高的层次，可以将网站分为表示层，逻辑层，持久层，分别进行封装。
6 扩容、容错处理
6.1 扩容
文件系统的扩容
数据库系统的扩容
6.2 容错
对于大面积网络中断：网站需要在用户主要分布区域保持数据存在。
对于服务器错误：一般采取冗余设计的方法来避免。
对于存储服务器（主要是负责写入的服务器）：可以使用RAID（冗余磁盘阵列）；对于数据库（主要是负责写入的主库），可以采用双主库设计。
对于提供服务的前台：可以使用第四层交换的集群，由多台服务器同时提供服务，不仅分担了流量压力，同时还可以互相作为备份。
在应用层程序中：要考虑“用户友好”的出错设计。
7 总结及展望
7.1 总结
对于一个高并发高流量的网站来说，任何一个环节的瓶颈都会造成网站性能的下降。
1）在全互联网层面，应该使用分布式设计，缩短网站与用户的网络距离；以及防止在网络意外情况下网站无法访问。
2）在局域网层面，应该使用服务器集群，一方面可以支撑更大的访问量，另一方面也作为冗余备份。
3）在单服务器层面，应该配置操作系统，文件系统及应用层软件，均衡各种资源的消耗，消除系统性能瓶颈。
4）在应用层，可以通过各种缓存来提升程序的效率，减少服务器资源消耗。
5）另外，还需要合理设计应用层程序，为以后的需求变更，扩容做好准备。
在每一个层次，都需要考虑容错的问题，严格消除单点故障，做到无论应用层程序错误，服务器软件错误，服务器硬件错误，还是网络错误，都不影响网站服务。
7.2 展望
当前Linux环境下有著名的LAMP（Linux＋Apache＋MySQL＋PHP/PERL/PYTHON）网站建设方案，但只是针对一般的中小网站而言。对于高并发高流量的大型商业网站，还没有一个完整的，性价比高的解决方案。除去服务器，硬盘，带宽等硬件投资外，还需要花费大量的预算和时间精力在软件解决方案上。
随着互联网的持续发展，Web2.0注定也会成就一个新的，高效的，成本较低的解决方案。这个方案应该包括透明的第三方CDN网络加速服务，价格低廉的第四层甚至更高层网络交换设备，优化了网络性能的操作系统，优化了读写性能，分布式，高可靠的文件系统，揉合了内存，硬盘等各个级别缓存的HTTP服务器，更为高效的服务器端脚本解析器，以及封装了大部分细节的应用层设计框架。
