级别： 初级

李明慧 ([[email protected]][2]), 软件测试工程师, IBM

2009 年 4 月 02 日

本文在介绍 squid 反向代理的工作原理的基础上，指出反向代理技术在提高网站访问速度，增强网站可用性、安全性方面有很好的用途。作者在具体的实验环境下，利用 DNS 轮询和 Squid 反向代理技术，实现了网站的负载均衡，从而提高了网站的可用性和可靠性。

现在有许多大型的门户网站如 SINA 都采用 squid 反向代理技术来加速网站的访问速度，可将不同的 URL 请求分发到后台不同的 WEB 服务器上，同时互联网用户只能看到反向代理服务器的地址，加强了网站的访问安全。

反向代理的概念

反向代理服务器又称为 WEB 加速服务器，它位于 WEB 服务器的前端，充当 WEB 服

务器的内容缓存器。其系统结构如图 1

 [][3]

反向代理服务器是针对 WEB 服务器设置的，后台 WEB 服务器对互联网用户是透明的，用户只能看到反向代理服务器的地址，不清楚后台 WEB 服务器是如何组织架构的。当互联网用户请求 WEB 服务时，DNS 将请求的域名解析为反向代理服务器的 IP 地址，这样 URL 请求将被发送到反向代理服务器，由反向代理服务器负责处理用户的请求与应答、与后台 WEB 服务器交互。利用反向代理服务器减轻了后台 WEB 服务器的负载，提高了访问速度，同时避免了因用户直接与 WEB 服务器通信带来的安全隐患。

Squid 反向代理的实现原理     目前有许多反向代理软件，比较有名的有 Nginx 和 Squid 。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的，是一个高性能的 HTTP 和反向代理服务器，也是一个 IMAP/POP3/SMTP 代理服务器。

    代理服务器是使用非常普遍的一种将局域网主机联入互联网的一种方式，使用代理上网可以节约紧缺的IP地址资源，而且可以阻断外部主机对内部主机的访问，使 内部网主机免受外部网主机的攻击。但是，如果想让互联网上的主机访问内部网的主机资源（例如：Web站点），又想使内部网主机免受外部网主机攻击，一般的 代理服务是不能实现的，需要使用反向代理来实现。

本文将详细介绍反向代理服务的概念以及如何利用反向代理服务器提高WEB服务器的性能和安全性。

一．反向代理的概念

什么是反向代理呢？其实，反向代理也就是通常所说的WEB服务器加速，它是一种通过在繁忙的WEB服务器和Internet之间增加一个高速的WEB缓冲服务器（即：WEB反向代理服务器）来降低实际的WEB服务器的负载。典型的结构如下图所示：

Web服务器加速（反向代理）是针对Web服务器提供加速功能的。它作为代理Cache，但并不针对浏 览器用户，而针对一台或多台特定Web服务器（这也是反向代理名称的由来）。实施反向代理（如上图所示），只要将Reverse Proxy Cache设备放置在一台或多台Web服务器前端即可。当互联网用户访问某个WEB服务器时，通过DNS服务器解析后的IP地址是Reverse Proxy Server的IP地址,而非原始Web服务器的IP地址,这时Reverse Proxy Server设备充当Web服务器，浏览器可以与它连接，无需再直接与Web服务器相连。因此，大量Web服务工作量被卸载到反向代理服务上。不但能够防 止外部网主机直接和web服务器直接通信带来的安全隐患，而且能够很大程度上减轻web服务器的负担，提高访问速度。

二． 反向代理和其它代理的比较

下面将对几种典型的代理服务作一个简单的比较。在网络上常见的代理服务器有三种：

1． 标准的代理缓冲服务器

一个标准的代理缓冲服务被用于缓存静态的网页（例如：html文件和图片文件等）到本地网络上的一台主 机上（即代理服务器）。当被缓存的页面被第二次访问的时候，浏览器将直接从本地代理服务器那里获取请求数据而不再向原web站点请求数据。这样就节省了宝 贵的网络带宽，而且提高了访问速度。但是，要想实现这种方式，必须在每一个内部主机的浏览器上明确指明代理服务器的IP地址和端口号。客户端上网时，每次 都把请求送给代理服务器处理，代理服务器根据请求确定是否连接到远程web服务器获取数据。如果在本地缓冲区有目标文件，则直接将文件传给用户即可。如果 没有的话则先取回文件，先在本地保存一份缓冲，然后将文件发给客户端浏览器。

2． 透明代理缓冲服务器

透明代理缓冲服务和标准代理服务器的功能完全相同。但是，代理操作对客户端的浏览器是透明的（即不需指 明代理服务器的IP和端口）。透明代理服务器阻断网络通信，并且过滤出访问外部的HTTP（80端口）流量。如果客户端的请求在本地有缓冲则将缓冲的数据 直接发给用户，如果在本地没有缓冲则向远程web服务器发出请求，其余操作和标准的代理服务器完全相同。对于Linux操作系统来说，透明代理使用 Iptables或者Ipchains实现。因为不需要对浏览器作任何设置，所以，透明代理对于ISP（Internet服务器提供商）特别有用。

3． 反向代理缓冲服务器

反向代理是和前两种代理完全不同的一种代理服务。使用它可以降低原始WEB服务器的负载。反向代理服务 器承担了对原始WEB服务器的静态页面的请求，防止原始服务器过载。它位于本地WEB服务器和Internet之间，处理所有对WEB服务器的请求，阻止 了WEB服务器和Internet的直接通信。如果互联网用户请求的页面在代理服务器上有缓冲的话，代理服务器直接将缓冲内容发送给用户。如果没有缓冲则 先向WEB服务器发出请求，取回数据，本地缓存后再发送给用户。这种方式通过降低了向WEB服务器的请求数从而降低了WEB服务器的负载。

三．反向代理工作原理

反向代理服务器位于本地WEB服务器和Internet之间,如下图所示：

当用户浏览器发出一个HTTP请求时，通过域名解析将请求定向到反向代理服务器（如果要实现多个WEB 服务器的反向代理，需要将多个WEB服务器的域名都指向反向代理服务器）。由反向代理服务器处理器请求。反向代理一般只缓存可缓冲的数据（比如html网 页和图片等），而一些CGI脚本程序或者ASP之类的程序不缓存。它根据从WEB服务器返回的HTTP头标记来缓冲静态页面。有四个最重要HTTP头标 记：

• Last-Modified: 告诉反向代理页面什么时间被修改

• Expires: 告诉反向代理页面什么时间应该从缓冲区中删除

• Cache-Control: 告诉反向代理页面是否应该被缓冲

• Pragma: 告诉反向代理页面是否应该被缓冲.

例如：在默认情况下，ASP页面返回” Cache-control: private.” ，所以ASP页面时不会在反向代理服务器缓存的

什么是数据库分区？

　　数据库分区是一种物理数据库设计技术，DBA和数据库建模人员对其相当熟悉。虽然分区技术可以实现很多效果，但其主要目的是为了在特定的SQL操作中减少数据读写的总量以缩减响应时间。 分区主要有两种形式：//这里一定要注意行和列的概念（row是行，column是列）

　　1. 水平分区（Horizontal Partitioning）这种形式分区是对表的行进行分区，通过这样的方式不同分组里面的物理列分割的数据集得以组合，从而进行个体分割（单分区）或集体分割（1个或多个分区）。所有在表中定义的列在每个数据集中都能找到，所以表的特性依然得以保持。 　　举个简单例子：一个包含十年发票记录的表可以被分区为十个不同的分区，每个分区包含的是其中一年的记录。（朋奕注：这里具体使用的分区方式我们后面再说，可以先说一点，一定要通过某个属性列来分割，譬如这里使用的列就是年份） 　　2. 垂直分区（Vertical Partitioning） 这种分区方式一般来说是通过对表的垂直划分来减少目标表的宽度，使某些特定的列 被划分到特定的分区，每个分区都包含了其中的列所对应的行。 　　举个简单例子：一个包含了大text和BLOB列的表，这些text和BLOB列又不经常被访问，这时候就要把这些不经常使用的text和BLOB了划分到另一个分区，在保证它们数据相关性的同时还能提高访问速度。

　　在数据库供应商开始在他们的数据库引擎中建立分区（主要是水平分区）时，DBA和建模者必须设计好表的物理分区结构，不要保存冗余的数据（不同表中同时都包含父表中的数据）或相互联结成一个逻辑父对象（通常是视图）。这种做法会使水平分区的大部分功能失效，有时候也会对垂直分区产生影响。

在MySQL 5.1中进行分区

　　MySQL5.1中最激动人心的新特性应该就是对水平分区的支持了。这对MySQL的使用者来说确实是个好消息，而且她已经支持分区大部分模式： 　　Range（范围） – 这种模式允许DBA将数据划分不同范围。例如DBA可以将一个表通过年份划分成三个分区，80年代（1980’s）的数据，90年代（1990’s）的数据以及任何在2000年（包括2000年）后的数据。 　　Hash（哈希） – 这中模式允许DBA通过对表的一个或多个列的Hash Key进行计算，最后通过这个Hash码不同数值对应的数据区域进行分区，。例如DBA可以建立一个对表主键进行分区的表。 　　Key（键值） – 上面Hash模式的一种延伸，这里的Hash Key是MySQL系统产生的。 　　List（预定义列表） – 这种模式允许系统通过DBA定义的列表的值所对应的行数据进行分割。例如：DBA建立了一个横跨三个分区的表，分别根据2004年2005年和2006年值所对应的数据。 　　Composite（复合模式） – 很神秘吧，哈哈，其实是以上模式的组合使用而已，就不解释了。举例：在初始化已经进行了Range范围分区的表上，我们可以对其中一个分区再进行hash哈希分区。

　　分区带来的好处太多太多了，有多少？俺也不知道，自己猜去吧，要是觉得没有多少就别用，反正俺也不求你用。不过在这里俺强调两点好处：

　　性能的提升（Increased performance） – 在扫描操作中，如果MySQL的优化器知道哪个分区中才包含特定查询中需要的数据，它就能直接去扫描那些分区的数据，而不用浪费很多时间扫描不需要的地方了。需要举个例子？好啊，百万行的表划分为10个分区，每个分区就包含十万行数据，那么查询分区需要的时间仅仅是全表扫描的十分之一了，很明显的对比。同时对十万行的表建立索引的速度也会比百万行的快得多得多。如果你能把这些分区建立在不同的磁盘上，这时候的I/O读写速度就“不堪设想”（没用错词，真的太快了，理论上100倍的速度提升啊，这是多么快的响应速度啊，所以有点不堪设想了）了。 对数据管理的简化（Simplified data management） – 分区技术可以让DBA对数据的管理能力提升。通过优良的分区，DBA可以简化特定数据操作的执行方式。例如：DBA在对某些分区的内容进行删除的同时能保证余下的分区的数据完整性(这是跟对表的数据删除这种大动作做比较的)。 此外分区是由MySQL系统直接管理的，DBA不需要手工的去划分和维护。例如：这个例如没意思，不讲了，如果你是DBA，只要你划分了分区，以后你就不用管了就是了。

　　站在性能设计的观点上，俺们对以上的内容也是相当感兴趣滴。通过使用分区和对不同的SQL操作的匹配设计，数据库的性能一定能获得巨大提升。下面咱们一起用用这个MySQL 5.1的新功能看看。 下面所有的测试都在Dell Optiplex box with a Pentium 4 3.00GHz processor, 1GB of RAM机器上（炫耀啊……），Fedora Core 4和MySQL 5.1.6 alpha上运行通过。

如何进行实际分区

　　看看分区的实际效果吧。我们建立几个同样的MyISAM引擎的表，包含日期敏感的数据，但只对其中一个分区。分区的表（表名为part_tab）我们采用Range范围分区模式，通过年份进行分区：

1. mysql> CREATE TABLE part_tab

2.    -> ( c1 int default NULL,

我目前的nginx配置是拆散的，这样可以便于在很多个虚拟主机和目录里重用部分配置。

总体是划分为这样一个结构：

conf/ conf/nginx.conf conf/proxy.conf conf/rewrite.conf conf/location.conf conf/port.conf conf/upstream.conf conf/servers/ conf/servers/www.sudone.com conf/servers/www.163.com

1、nginx.conf

这就是nginx读取的主文件，没特殊情况是通用的

2、proxy.conf

代理的选项配置，也是通用的

3、rewrite.conf

所有主机的根目录公用的rewrite规则，默认是空文件，可以不使用。

4、location.conf

所有主机都会用到的location目录结构，默认是空文件，可以不使用。

5、port.conf

配置服务器绑定ip和端口，因为nginx如果各个主机ip端口配置有不同会有bug，所以最好是统一设定。

6、upstream.conf

upstream写在这里面，和业务分开，易于控制。

7、servers目录

这个目录下面放的是所有的虚拟主机配置，每个虚拟主机一个文件，由nginx.conf去include，这样处理这些配置变得很灵活。

可以在这里下载到公用的几个配置，带注释：

nginx.conf proxy.conf

整个框架的例子可以下载这个rar包：

nginx.conf.rar

图片服务通常数据容量较大，而且访问也频繁，鉴于此，图片服务就会有两种问题，一是存储问题，二是访问量问题。

存储问题就是硬盘容量问题，花钱买硬盘就可以了，看似简单，但着实也是最苦的问题。按目前探索来看，最好的方式是：在任何时刻遇到硬盘空间不够时，买颗硬盘插上，最多改改配置，就能立刻利用；另外，硬盘要能充分利用，不然图片存储量大再加上备份，很恐怖，最好是每颗硬盘都用上100%的空间。

访问量也是个大问题，如果服务不允许防盗链，那么访问量会引起带宽、服务器压力等问题，有钱的话直接扔CDN，没钱或者有更多的钱，就自己做吧。根据垣古不变的真理“越老的图，访问量也相对较少”这一点，分成两大部分，一边处理最新的图片，一边处理老旧的图片。最新的图片访问量大，但存储量较少；老图片访问量低，但存储量大。

大概分析完了，开始制定方案。

一、拟定一个存储目录规则：

在现有的/a/b/abcde.jpg这样的hash方式下多加一个日期的目录变成：/200810/16/a/b/abcde.jpg或者/2008/10/16/a/b/abcde.jpg。按日期制定这个目录规则后，就可以按年月来拆机器了。

二、分机器，分硬盘

按之前的计划，分成两个组，一组服务器用lvs做负载均衡负责新图片；另一组服务器做旧图片访问和备份。新图机器找几台好点的服务器，SCSI硬盘；旧图机器没太大要求，PC机就行，找够硬盘就可以，现在IDE的1T硬盘也不太贵，最好再搭个raid就省事了，最主要是这些机器要多。

照这个图，搭一搭

说明一下：

1、图片服务通过lvs作为入口，处理能力上还是有保障的。

2、利用nginx直接对外服务，不必用squid。

3、图中的红线是指主nginx会将/2006和/2007年的图片分别代理到两台存档服务器，如果发现主nginx的cpu占用比较大，那么可以考虑使用nginx的proxy_store将图片存到主服务器上，定期清理。

4、图中有一台存储分配服务器，作为图片服务更新图片的统一入口，有新图片或者修改图片的话，由这台服务器负责将图片放到正确的服务器上去。

5、旧图片服务器当前用年份来划分，每年增加两台服务器，亦可是加两块硬盘，注意，不要相信raid，一定要有两台机器，地理上分在两个城市则更好。

6、因为旧数据2006和2007年的数据基本上是没有变化的，所以假如硬盘够大，那么可以把两年的数据合并在一起。

7、如果细心定制，那么旧图片服务器的硬盘100%塞满是可以的，旧数据的容量基本上不会大幅增长，小小预留1-2G空间就可以了。

使用这个架构的话，到了2009年，我会把2008年的数据想办法迁到旧图服务器上，硬盘不够的话，加硬盘就可以了。如果图片量实在太大，主服务器连一年的数据都装不下，那可以用启用月份来划分；如果一个月都装不下了，那也太夸张了，那就启用日期吧；如果一天的数据都装不下，那就◎＃￥％……※。

如图，这是一个最简洁的架构。

在这个架构里，负载均衡器都可以省了，用最为廉价的dns来替代，dns的优点就是廉价，不用维护，也不愁性能和稳定，还可以跨机房多用几条带宽作分流。另外，在图片服务中，可以选择用另一个域名做dns。优点是主站中的任何cookie等header不会带到图片服务中，省了不少上传流量和服务器可能有的处理时间；缺点是多花了点域名的钱。目前门户都喜欢用这办法，小站用的话，用另一个域名还附带有一个特别的优点：因为部分域名服务商允许添加的二级域名有限，所以用别的域名可以节约有限的域名资源。dns这一块也可以用泛域名，不过貌似国内的泛域名支持不是特别的稳定，有些网站的泛域名，在linux下不能解析windows就正常，比较奇怪，我也没法解释。

在这个架构里我总共开了36个域名，但是一时没有那么多机器，所以有一些域名指向同一台机器。一般来说，一个刚上线的项目，放一台机也未尝不可，但是链接（包括域名）一定要固定下来，不然以后调整会非常痛苦。

域名的事情还是比较简单的，只要照着填写web表单就完成了，配置四台nginx服务器当然也是非常简单的，因为不需要什么特殊的功能，所以四台机用同一个配置，写一个root根目录和expires就完成了。expires可以大胆地配置一年expires 1y，或10y甚至expires max都没什么问题，因为假如客户端认为图片有误，他会按F5刷新，F5会跳过expires向服务器发送if-modified-since头，和服务器的源文件修改时间对比，假如一样，服务器返回一个304表示没有更新，否则会重新下载该图。

在这个架构里难处在于分发和管理图片，所以hash结构比较适合于在论坛、博客等用web浏览器上传的场合使用。用浏览器上传图片后，只需要用动态语言创造一个hash的文件地址，保存在上传机器上，然后使用rsync分发到四台图片服务器就可以了。在我这个架构里分了36个字母和数字，是给md5编码用的，md5图片存档地址可类似/7/5/2/23AE809DDACAF96AF0FD78ED04B6A265E05AA257.jpg，这样这张图片就会分配到这个架构的第4台机器。有些系统的图片是用当前时间或自动ID算出来的，hash结构可为图片ID%100叫求余数，相应的dns配置为纯数字就可以了，hash办法可以很多样，最紧要就是图片量要分得均匀，点击量不均匀倒是其次。删除的时候也不难办，给定一个图片地址，就很容易知道它在哪台机器，然后在这个地址写一个空文件，用rsync同步到图片服务器。

假如不是web浏览器上传的图片，而是用ftp上传的，就不适合使用这个架构，强行使用这个架构的话头还是自己的疼啊，可以使用这个架构试试，不久的将来我会再写一个最简单的架构。hash架构也有一个要命的缺点，就是这几台机器的硬盘虽然都不容易满，但是都快满的时候（它们一般是同时满的），就得为每台机都增加硬盘空间或增加一倍的服务器。

在这个最简单的hash架构上，没有设计任何保护措施，所以有一台服务器硬盘损毁，会造成1/4的图片无法访问；同时也先不讨论数据备份的问题。简单有简单之美，复杂的事情留待高人解决。

这个架构基于squid、nginx和lvs等技术，从架构上对bbs进行全面优化和保护，有如下特点：

1、高性能：所有的点击基本上全部由前端缓存负责，提供最快速的处理。

2、高保障度：不需考虑应用程序稳定与否、程序语言是何种、数据库是何种，都能从架构上保证稳定。

3、高可用性：对应用程序的修改达到最简化：在程序的某些地方加入清缓存的语句即可，当然还需要做页面静态化的工作和统计工作。

首先看图，这个图比较大：

这个架构的特点和一些流程的说明：

1、主域名和图片域名分离

域名分离可以使流量分离，缓存策略分离等等，好处诸多。bbs初期一定要做好规划，将图片用另外的域名独立服务，即使没有足够机器，域名也要先分开。另外，图片服务器可以使用有别于主域名的另一个域名，一个好处是可以减少读取cookie对图片服务器的压力，另一个是提高安全性，避免cookie泄露。

2、使用LVS作为前端、二级代理和数据库的访问入口

使用LVS作为入口，比其他任何一种方式都来得更优质。首先LVS的负载能力很强，因为它工作在网络协议的第4层，使用虚拟ip技术，所以它本身并不担负任何流量的处理，仅仅是一个封包转发的功能；第二，LVS的配置相对简单而且稳定，一般去调整的几率比较低，也减少了因人为等因素而出现故障；第三，LVS可以处理任何端口的负载均衡，所以它基本可以做所有服务的负载均衡和容错。在这个架构中，除了处理http的80端口之外，LVS也处理了数据库mysql的3306端口，在数据库这个应用中是采用的双机热备策略。

3、使用nginx+squid作为最前端的缓存组合

在这个架构中，是最能体现app_nginx_squid_nginx架构的优势的。在这个架构中的bbs运行在缓存上，用户每发布一张帖子，都需要使用purge指令清除该帖子的缓存，如果是squid在最前端，那么每次发布一张帖子，都需要在所有的squid中调用purge指令，这样在机器比较多的时候，purge将成为一个巨大的压力。

所以在这里将nginx放在最前端并使用手工url_hash的方式分流，将经常需要purge的帖子页面和列表页面按一个url对应一台squid的策略，分布到各台squid上，并提供了一台或一组backup的squid，个别squid出现异常时将自动使用backup的机器继续提供一段时间的服务直到其正常。在这样的架构下，purge就不再是关键问题，因为一个url只会对应到一台机器上，所以purge的时候，后端app_server找到对应的机器就可以了。

可以看到在前端中还有一台nginx(purge)的机器，这台机器是专用于purge的，只要发送purge指令和需要清除的url到这台机器，就可以找到相应的服务器并清除缓存了。另外，purge时还需要清理backup机器上的缓存，所以无论前端机器增加到多少，purge指令只会在2台机器上执行，如果backup机器使用到2-3台，purge指令就会在3-4台机器上执行，仍然在可接受范围之内。

nginx作为前端，另有的好处：

1/使用nginx的日志统计点击量非常方便 2/nginx也可作为缓存，一般可以直接负责favicon.ico和logo等固定的小图片

4、基于nginx的中层代理

nginx中层代理的优势，在：

nginx和squid配合搭建的web服务器前端系统

这篇文章中有解释。

在这个架构中，假如后端的app_server上把帖子页和列表页直接生成了静态页面，那么使用中层代理再做一次url_hash，将可以解决后端app_server的硬盘容量的压力，但是如果使用到url_hash的话，那做容错就相对麻烦了。所以建议不要采用生成静态页的方式，后端的压力一般不会非常的大，所以没有必要生成静态页。假如前端squid的命中率实在太低下，造成大量穿透，可以考虑使用二级代理暂顶。

5、基于LVS的数据库双机热备

在这个架构中，因为大量的并发和访问量都由前端的缓存处理掉了，所以后端的mysql主要压力来自于数据的写入，所以压力并不是非常大，并且负载比较稳定，一般不会随着访问量上升而提高过快，估计目前一台64位的机器，加满内存并使用高速的硬盘，前端负载数亿访问量时数据库都不会出现性能问题。在数据库这方面应主要考虑故障恢复，因为数据库崩溃的话，按照一般使用备份恢复的做法，耗时很长而且难免丢失数据，是很棘手的问题。使用双机热备的方案，出现故障时首先可由一台时刻同步着的备用数据库即刻充当主数据库，然后卸下的数据库可以有充分的时间对其进行维修，所以是个很安全有效的办法。

当然，数据库的优化还是要细心做的，参考：

mysql性能的检查和调优方法

细心地调一遍，性能会好很多。

6、图片服务器

图片服务器我在这个架构中没有特别详细的介绍，在大型的bbs系统下，图片常常会出现容灾现象——图片数量严重超过了单台前端服务器容纳能力，导致前端服务器命中率低下。处理容灾问题也是非常棘手的，往后会有更详细的介绍。

7、简单的点击量统计办法

1/使用js的script标签访问另一（台）组服务器的空文件，然后定期向数据库更新 2/在前端的nginx上直接开启日志功能，按需要统计点击量的链接规则进行记录，然后定期更新数据库

www.haohtml.com 和 blog.haohtml.com 域名均指向 Nginx 所在的服务器IP。

用户访问，将其负载均衡到192.168.1.2:80、192.168.1.3:80、192.168.1.4:80、192.168.1.5:80四台服务器。

用户访问，将其负载均衡到192.168.1.7服务器的8080、8081、8082端口。

以下为配置文件nginx.conf： 引用 user  www www;

worker_processes 10;

#error_log  logs/error.log; #error_log  logs/error.log  notice; #error_log  logs/error.log  info;

#pid        logs/nginx.pid;

#最大文件描述符 worker_rlimit_nofile 51200;

events { use epoll;

worker_connections 51200; }

http { include       conf/mime.types; default_type  application/octet-stream;

keepalive_timeout 120;

tcp_nodelay on;

upstream  www.haohtml.com { server   192.168.1.2:80; server   192.168.1.3:80; server   192.168.1.4:80; server   192.168.1.5:80; }

upstream  blog.haohtml.com  { server   192.168.1.7:8080; server   192.168.1.7:8081; server   192.168.1.7:8082; }

server { listen  80; server_name  www.haohtml.com;

location / { proxy_pass        ; proxy_set_header   Host             $host; proxy_set_header   X-Real-IP        $remote_addr; proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for; }

一、前言

二、编译安装

三、 安装MySQL、memcache

四、 安装Apache、PHP、eAccelerator、php-memcache

五、 安装Squid

六、后记

一、前言，准备工作

当前，LAMP开发模式是WEB开发的首选，如何搭建一个高效、可靠、稳定的WEB服务器一直是个热门主题，本文就是这个主题的一次尝试。

我们采用的架构图如下：

引用

——–               ———-                           ————-                   ———                 ————

| 客户端 | ===> |负载均衡器| ===> |反向代理/缓存| ===> |WEB服务器| ===> |数据库服务器|

——–               ———-                           ————-                   ———                 ————

Nginx                     Squid                     Apache,PHP                 MySQL

eAccelerator/memcache

准备工作：

引用

服务器： Intel(R) Xeon(TM) CPU 3.00GHz * 2, 2GB mem, SCISC 硬盘

操作系统：CentOs4.4，内核版本2.6.9-22.ELsmp，gcc版本3.4.4

软件：

Apache 2.2.3（能使用MPM模式）

PHP 5.2.0（选用该版本是因为5.2.0的引擎相对更高效）

eAccelerator 0.9.5（加速PHP引擎，同时也可以加密PHP源程序）

memcache 1.2.0（用于高速缓存常用数据）

libevent 1.2a（memcache工作机制所需）

MySQL 5.0.27（选用二进制版本，省去编译工作）

Nginx 0.5.4（用做负载均衡器）

squid-2.6.STABLE6（做反向代理的同时提供专业缓存功能）

二、编译安装

我从2002年底就开始关注drupal了，当时在国内看不到一点关于drupal的资料，2003年写过几篇关于drupal的介绍文章，到现在都经常看到很多介绍drupal的文章里引用我的话。记得2003年看到海微在研究drupal，并且发布了中文语言包，打开了drupal进入中国的大门。海微是我一直敬仰的一个人，以前一直致力于xoops的中文化工作，现在竟然搞Hiweed Linux操作系统了。

海微发布drupal中文语言包后我就一直开始用drupal，不过都是当作普通的blog程序来用，基本上不装插件，也没改过风格。中途试着改过几次风格，但试了几次都放弃了，感觉很麻烦。

最近看了几个用drupal做的强站，看了之后感觉就是震撼，根本看不出是用个开源代码的做的，看了之后我又萌发了修改drupal风格的念头，打算为我的极客集改个版。研究了两天，终于明白drupal模板的原理了，对CCK和views这两个超强模块也有了新的认识，把官方的主要模块都看了看，看得我眼都花了，实在是太多了，对drupal的评价就是：“只有想不到的，没有做不到的”你想要什么功能都有什么模块。这也是国外程序最大的特点，国内的人都抱怨国外的程序简单，不适合做大站，这都是因为没去研究过人家的模块。国外很多人把joomla，drupal叫做web操作系统，这很形象，人家只提供给你最底层的框架代码，其余的功能都留给模块了。就比如用windows一样，安装windows后可以使用，基本的功能也有，但你想要更多的功能就得装软件，你想让你的桌面变漂亮就得换主题。

Drupal属于开发型cms，最便于扩展的cms，在我看来它比joomla灵活很多，官方网站上的模块就有几千个，再加上cck的自定义字段功能，如果想用来做个门户网站功能上你也不用考虑太多了，所以现在Drupal程序员炙手可热，招一个Drupal程序员，不但可以为你节省更多的成本，还有利于以后的开发，毕竟核心代码你不用管了，和Linux一样，linux版本有几十个，但核心代码都是kernel小组开发的。

Drupal上手容易，各种模块装了就可以用，但如果想改模板需要熟悉CSS技术，也需要一定的PHP基础，当然还需要一定的英文基础，因为中文资料相对较少，但官方网站上的教程就够你看一辈子了。如果你css，php，英文都不错，那Drupal在你手中简直就是一个万能工具了，你会越来越对它爱不释手。

不得不承认，Drupal的模板是个门槛，在默认的模板基础上很难做出复杂的页面，和中国人心中的门户网站相差很远。要想做复杂的页面views成了必须用的模块，虽然它很灵活，但使用也很麻烦，而且如果调用太多很占资源，但这个你不必考虑太多，Drupal有很好缓存功能，还有很多缓存插件，数据查询都是一次性运行了放在一个表里随时调用，而且国外那么多大站用drupal充分说明了它的性能。

Drupal的模板核心就是区块(block)，你只需要把你的模板分成很多块，然后把drupa生成的区块排列在你的模板上，你安装的插件如果需要显示一般都会自动生成个区块。Drupal官方发布模板都比较简单，一般只适合做左中右结构的网站，如果你想自己在模板里多加一些容器来放Drupal的区块，需要phptemplate_regions函数，当然更方便的是module_invoke函数，可以让你的区块显示在你想放的任何地方。

drupal默认生成的各种区块里带有很多层的html代码，几乎每个html标签都有单独的css id或者class，这样方便你用css控制显示效果，这给我带来了极大的方便，不用动html代码就可以修改模板的显示效果。

这次给极客集改版让我学了很多东西，本来做了一个比较复杂的页面，调用比较多，研究了一下views模块，感觉太麻烦了，而我又不喜欢装模块，能不用的模块尽量不用，极客集只装了几个比较简单的模块(BUEditor,Google Sitemap,Month,Similar By Terms,Captcha)。views是最复杂的一个模块，代码体积几乎是drupal核心的三分之一，于是我打算放弃views做个比较简单的页面了。其实如果你PHP学的好的话完全可以不用views，views本质上就是生成一段Mysql查询语句。

Drupal的官方论坛是个大宝库，你遇到的问题几乎都可以在那里找到答案，随便提个问题就有很多热心人来帮你，而且还会有其他人给出不同的参考答案。这也是国外开源项目最让人羡慕的地方，真让人兴奋啊。去了官方社区才认识到自己很菜，

这篇文章不小心又成了鼓吹drupal的“枪稿”了，其实根本用不着夸它了，它刚刚获得了2007年最佳开源cms的大奖，去年这个奖是Joomla的。也许有人会问我“你整天说这个程序好，那个程序好，到底哪个最好啊？”，说实话我也不知道那个好，每个都有自己的特点，关键是看使用的人，有的人用个简单blog做的站比那些用大型CMS的都感觉复杂。我本人是见一个爱一个，我很多网站，都用不同的cms，它们都是我的情人，每个情人都能给我带来激情，哈哈。过几天打算写一篇比较国外cms的文章给大家参考，国内的不考虑，因为国内的都没特点，无法比较。

UA = getenv(“HTTP_USER_AGENT”);   $start  = strpos($this->UA,”(“)+1;//查看起始位置   $length = strpos($this->UA,”)”)-$start;//查看结束位置   $middle = trim(substr($this->UA,$start,$length)); //查看内容   $end  = trim(substr($this->UA,$start+$length+1));//附加内容   $message = explode(“;”,$middle);//转换成数组   //———-操作系统—————–   $os = trim($message[‘2’]);   $os_array = explode(” “,$os);   $this->PLATFORM = trim($os_array[‘0’]);//操作系统   //————浏览器————   $brower = trim($message[‘1’]);

  if(eregi(“msie”,$brower)){//IE核心浏览器    $brow_array =explode(” “,$brower);    $this->BROWSER = “IE”;    $this->VERSION = “”.$brow_array[‘1’];   }else{//其它浏览器    $brower =explode(” “,$end);    $brow_array =explode(“/”,$brower[‘1’]);    $this->BROWSER = $brow_array[‘0’];    $this->VERSION = $brow_array[‘1’];   }  }//End Function }//End Class $test=new browserdetector; echo $test->UA.”

”; echo $test->PLATFORM.”

”; echo $test->BROWSER.”

【eNet硅谷动力专稿】相信很多IT人士都有过搭建自己主页的经验，10多年前的个人主页都非常简单，很多由Frontpage构建，多属于静态HTML页面，最多加一点特效而已。不过10年间，技术的进步是惊人的。现在，一个网站绝不可能仅仅由几个HTML页面构成。我们随便举一个例子，国内图片网站yupoo.com，在chinarank排名1000左右，而Alexa排名则为5000左右，这个网站不算大，就是这样一个中型站点，拥有超过60台服务器，架构中涉及的Web服务器就包括了Lighttpd、Apache和 nginx。Yupoo的流量不算大，就已经拥有了60台服务器，事实上，排名前几位的网站，都拥有成千上万台服务器，如何协调这些服务器之间的工作负载，如何统一指挥调度，如何维护这些服务器硬件都是棘手的挑战。

　　负载均衡：

　　负载均衡是所有大中型网站必备的部署。显然，大型网站每天上千万独立IP的访问量，一个Web服务器根本承担不了，网站后台必需有多台服务器共同工作，因此各种负载均衡技术就应运而生了。

　　较早的负载均衡是DNS负载均衡。原理很简单，只要在域名解析的时候，将多个地址配置成同一个域名，负载均衡就完成了。不同用户点击同一个域名的时候，实际上只解析给用户一个地址，这样用户实际上访问的是不同的Web服务器，就减轻了每个服务器的负担。这个DNS负载均衡方法，一般而言是随机抽取地址。DNS负载均衡早期被广泛使用，优点是简单易用，但是DNS负载均衡还是有一些问题存在。如果某一台服务器发生了故障，而DNS的下一个刷新周期又没到，这样就可能导致某些用户无法访问站点的情况发生。而另一个缺点在于DNS负载均衡随机性太强，比如一段时间内众多访问都被指向同一个地址，而另外的地址却闲置，就造成了局部繁忙的不良现象。而且有时某处服务器正在运行其他应用而处于繁忙状态，DNS负载均衡也无从得知，而依旧平均的解析域名。

　　稍微复杂一点的负载均衡，是反向代理，当外部有请求到代理服务器，代理服务器再将该请求均匀的转发到内网的服务器上。这种方式被广泛采用，比如说上面提到的又拍网yupoo.com，就采用了nginx作为反向代理。此外，现在还可以购买专业的硬件设备，比如Plentyoffish.com(全球最大的婚介网站)就采用了网捷网络公司的Web交换器ServerIron作为硬件负载均衡，ServerIron 能够有效地处理 16，000，000个并发连接，并且可以改善服务器负载均衡和缓冲转换，像ServerIron这类的硬件产品并非只有网捷一家提供，由于大型网站预算充裕，因此也可以选择一些其他的硬件设备来做负载均衡。当然了，我们也别忽略了最基本的软件负载均衡——Windows Server就带有这样的功能。

　　负载均衡还有一个极为简单的方法，就是建立镜像站点。比如华军软件或者天空软件，都直接采用了镜像站点。这个方式很直接，省去了很多麻烦。以华军软件园为例，登陆华军软件园的时候，我们将有多种选择，可选电信、网通等网络；而下载某一软件的时候，为了使用户得到更快的速度，天空和华军在中国各地都安排了服务器，可以提供距离最近的下载服务。不过，也有一些麻烦，就是每一次选择都是人工手动选择。总之，这一系列负载均衡方法，都得以让大型网站的负载均匀，不会有哪个服务器有太大的压力。

　　CDN：

　　CDN( Content Delivery Network)，内容分发网络也是大型网站必备的部署之一。CDN的原理不难理解，就是将网页内容存放到离用户更近的缓存服务器上，减少路由，从而加快远距离的访问速度。比如说，你随意登陆一个国外小站，速度可能很慢。因为国外网站到国内的最终客户端的路径冗长，但是如果你登陆部署了CDN的网站，比如Plentyoffish.com，你会发现速度非常快，跟国内的网站访问速度差异已经无法从感知上判断。 依照Cache存放的位置不同，CDN也有一些类别，不同的网站会根据具体需求，有不同的选择。CDN通常是由独立的CDN商提供的。举一个例子，就是网易，我的查询时间是2008年2月28日，我们发现，同一个域名下的有很多个IP地址，这就说明了首页CDN的部署。

　　C:>nslookup www.163.com

　　Server: ns.lnpta.net.cn

　　Address: 202.96.64.68

　　Non-authoritative answer:

　　Name: www.cache.split.netease.com

　　Addresses: 202.108.9.37, 202.108.9.38, 202.108.9.39, 202.108.9.51

　　 202.108.9.52, 202.108.9.31, 202.108.9.32, 202.108.9.33, 202.108.9.34

　　 202.108.9.36

　　Aliases: www.163.com

　　而我们如果查询一个简单的个人网站，则不可能有CDN；另外，如果有兴趣，我们也可以仔细察看一个网站多个二级域名的CDN情况。

　　平台设计：

　　大型网站一般都有着非常复杂的与用户交互的内容，必须大量调用数据库，因此一个完善的数据库设计对于大型网站非常重要。例如上面提到的Plentyoffish.com，这个站其实是个人网站，但流量大的惊人，该网站有一个主要的数据库，两个搜索数据库，早些时候，plentyoffish.com的数据库设计问题频频，经常到数据库堵塞，所以站长花费时间最多的地方就是数据库优化。数据库优化没有什么特别的捷径，其实很少有一次成型的完美数据库构建，只能是按照特定的需要来设计数据库，如有不足再去着手改进。不过大型网站还是有一些共性，比如说图片存储单独使用图片数据库，尽量使用静态页面来减少数据库调用等等。

　　还有很多大型网站，都有着非常深厚的技术实力，可以开发属于自己的平台。比如说谷歌，Google.com就有着自己独特的平台，主要包括GFS、MapReduce和 BigTable。因为海量数据存储，所以常规的数据库调用查询是非常恐怖的，每次查询都将调用百亿个页面，成千上万个并发检索足以使得谷歌系统崩溃，因此Google File System将大量页面以独特的方法压缩之后再提供检索；整个系统一共包括超过两百个集群，再由MapReduce来协同作业。不仅仅谷歌，比如百度、中搜等等网站也都有自己研发的独特的平台。

　　硬件配置：

　　大型网站的硬件配置一定就好吗？答案是否定的。比如说全球最大的网站谷歌，google.com的整个架构的基础是几十万台普通的PC级别服务器。谷歌一些服务器的细节为商业机密，但是根据谷歌已经披露的资料显示，在2006年之前谷歌拥有45万台服务器，这些服务器都是非常普通的PC级服务器，甚至硬盘接口都还是有些过时的IDE接口。这也是谷歌的独特架构决定的，而对比谷歌，维基百科则拥有非常强势的服务器，全部为SCSI硬盘，而且主要的主机中都有多达6块硬盘，超过16GB内存。这比较容易理解，因为谷歌在全球拥有很多个数据中心，员工数量众多，完全有能力管理数以万计服务器的运行，而维基百科则为非营利机构，主要依靠捐赠生存，员工数量非常稀少，因此必须配备强势的服务器。其实，每个网站都应该根据自己独特的情况来配置硬件，目前1TB SATA硬盘已经步入了量产阶段，可是2年以前1TB的硬盘只能通过RAID 0来实现，可见硬件的更新速度非常惊人，所以即便预算充裕，在配置服务器的时候也应该多考虑实际用途，而不一定要拥有最好的配置。

　　总结：

　　以上只是大型网站的概括总结，其实每个网站都有自己独特的一面，所以以上的每一条规则都未必是死规定。比如说着重沟通的Twitter.com，本质就是一个异步聊天室，因此静态页面就不见的有必要。总之，网站架构没有死定律，只要合适网站的，就是好的架构。

FBD即Fully-buffer DIMM（全缓存模组技术），它是一种串行传输技术，可以提升内存的容量和传输带宽.是Intel在DDR2、DDR3的基础上发展出来的一种新型内存模 组与互联架构，既可以搭配现在的DDR2内存芯片，也可以搭配未来的DDR3内存芯片。FB-DIMM可以极大地提升系统内存带宽并且极大地增加内存最大容量。

FB-DIMM技术是Intel为了解决内存性能对系统整体性能的制约而发展出来的，在现有技术基础上实现了跨越式的性能提升，同时成本也相对低廉。在整 个计算机系统中，内存可谓是决定整机性能的关键因素，光有快的CPU，没有好的内存系统与之配合，CPU性能再优秀也无从发挥。这种情况是由计算机原理所 决定的，CPU在运算时所需要的数据都是从内存中获取，如果内存系统无法及时给CPU供应数据，CPU不得不长时间处在一种等待状态，硬件资源闲置，性能 自然无从发挥。对于普通的个人电脑来说，由于是单处理器系统，目前的内存带宽已经能满足其性能需求；而对于多路的服务器来说，由于是多处理器系统，其对内 存带宽和内存容量是极度渴求的，传统的内存技术已经无法满足其需求了。这是因为目前的普通DIMM采用的是一种“短线连接”(Stub-bus)的拓扑结 构，这种结构中，每个芯片与内存控制器的数据总线都有一个短小的线路相连，这样会造成电阻抗的不继续性，从而影响信号的稳定与完整，频率越高或芯片数据越 多，影响也就越大。虽然Rambus公司所推出的的XDR内存等新型内存技术具有极高的性能，但是却存在着成本太高的问题，从而使其得不到普及。而FB- DIMM技术的出现就较好的解决了这个问题，既能提供更大的内存容量和较理想的内存带宽，也能保持相对低廉的成本。FB-DIMM与XDR相比较，虽然性 能不及全新架构的XDR，但成本却比XDR要低廉得多。

与现有的普通DDR2内存相比，FB-DIMM技术具有极大的优势:在内存频率相同的情况下目前能提供四倍于普通内存的带宽，并且能支持的最大内存容量也 达到了普通内存的24倍，系统最大能支持192GB内存。FB-DIMM最大的特点就是采用已有的DDR2内存芯片(以后还将采用DDR3内存芯片)，但 它借助内存PCB上的一个缓冲芯片AMB(Advanced Memory Buffer，高级内存缓冲)将并行数据转换为串行数据流，并经由类似PCI Express的点对点高速串行总线将数据传输给处理器。

与普通的DIMM模块技术相比，FB-DIMM与内存控制器之间的数据与命令传输不再是传统设计的并行线路，而采用了类似于PCI-Express的串行 接口多路并联的设计，以串行的方式进行数据传输。在这种新型架构中，每个DIMM上的缓冲区是互相串联的，之间是点对点的连接方式，数据会在经过第一个缓 冲区后传向下一个缓冲区，这样，第一个缓冲区和内存控制器之间的连接阻抗就能始终保持稳定，从而有助于容量与频率的提升。

**ECC是“Error Checking and Correcting”的简写，中文名称是“错误检查和纠正”。ECC是一种能够实现“错误检查和纠正”的技术，ECC内存就是应用了这种技术的内存，一 般多应用在服务器及图形工作站上，这将使整个电脑系统在工作时更趋于安全稳定。 ** ECC内存即纠错内存，是在数据位上额外的位存储一个用数据加密的代码。当数据被写入内存，相应的ECC代码与此同时也被保存下来。当重新读回刚才存储的 数据时，保存下来的ECC代码就会和读数据时产生的ECC代码做比较。如果两个代码不相同，他们则会被解码，以确定数据中的那一位是不正确的。然后这一错 误位会被抛弃，内存控制器则会释放出正确的数据。被纠正的数据很少会被放回内存。假如相同的错误数据再次被读出，则纠正过程再次被执行。重写数据会增加处 理过程的开销，这样则会导致系统性能的明显降低。如果是随机事件而非内存的缺点产生的错误，则这一内存地址的错误数据会被再次写入的其他数据所取代。

使用ECC校验的内存，会对系统的性能造成不小的影响，不过这种纠错对服务器等应用而言是十分重要的，带ECC校验的内存价格比普通内存要昂贵许多，一般用户不建议使用！ 要了解ECC技术，就不能不提到Parity（奇偶校验）。在ECC技术出现之前，内存中应用最多的是另外一种技术，就是Parity（奇偶校验）。我们 知道，在数字电路中，最小的数据单位就是叫“比特（bit）”，也叫数据“位”，“比特”也是内存中的最小单位，它是通过“1”和“0”来表示数据高、低 电平信号的。在数字电路中8个连续的比特是一个字节（byte），在内存中不带“奇偶校验”的内存中的每个字节只有8位，若它的某一位存储出了错误，就会 使其中存储的相应数据发生改变而导致应用程序发生错误。而带有“奇偶校验”的内存在每一字节（8位）外又额外增加了一位用来进行错误检测。比如一个字节中 存储了某一数值（1、0、1、0、1、0、1、1），把这每一位相加起来（1＋0＋1＋0＋1＋0＋1＋1=5）。若其结果是奇数，对于偶校验，校验位就 定义为1，反之则为0；对于奇校验，则相反。当CPU返回读取存储的数据时，它会再次相加前8位中存储的数据，计算结果是否与校验位相一致。当CPU发现 二者不同时就作出视图纠正这些错误，但Parity有个缺点，当内存查到某个数据位有错误时，却并不一定能确定在哪一个位，也就不一定能修正错误，所以带 有奇偶校验的内存的主要功能仅仅是“发现错误”，并能纠正部分简单的错误。

通过上面的分析我们知道Parity内存是通过在原来数据位的基础上增加一个数据位来检查当前8位数据的正确性，但随着数据位的增加Parity用来检验 的数据位也成倍增加，就是说当数据位为16位时它需要增加2位用于检查，当数据位为32位时则需增加4位，依此类推。特别是当数据量非常大时，数据出错的 几率也就越大，对于只能纠正简单错误的奇偶检验的方法就显得力不从心了，正是基于这样一种情况，一种新的内存技术应允而生了，这就是ECC（错误检查和纠 正），这种技术也是在原来的数据位上外加校验位来实现的。不同的是两者增加的方法不一样，这也就导致了两者的主要功能不太一样。它与Parity不同的是 如果数据位是8位，则需要增加5位来进行ECC错误检查和纠正，数据位每增加一倍，ECC只增加一位检验位，也就是说当数据位为16位时ECC位为6 位，32位时ECC位为7位，数据位为64位时ECC位为8位，依此类推，数据位每增加一倍，ECC位只增加一位。总之，在内存中ECC能够容许错误，并 可以将错误更正，使系统得以持续正常的操作，不致因错误而中断，且ECC具有自动更正的能力，可以将Parity无法检查出来的错误位查出并将错误修正。

所有英特尔® 至强® 处理器特性：

英特尔® 虚拟化技术±

英特尔® 64 位内存扩展技术Φ

**病毒防护技术°**

处理器

号

架构

高速缓存

时钟

频率

前端

总线

功率

系统类型

四核

双核

超线程（HT）

技术†45 纳米技术 L5410

45 纳米

12 MB 二级缓存¹

2.33 GHz

1333 MHz

50 瓦

双路 L5420

45 纳米

12 MB 二级缓存¹

2.50 GHz

1333 MHz

50 瓦

双路 X3360

45 纳米

12 MB 二级缓存¹

2.83 GHz

1333 MHz

95 瓦

单路 X3350

45 纳米

12 MB 二级缓存¹

2.66 GHz

1333 MHz

95 瓦

咖啡图标是shstat.exe，看“任务管理器”里是否有这进程，没有就用系统的“搜索”，找到该文件并双击运行。

然后在开始菜单“运行”里键入：msconfig  打开“启动项”，看shstat.exe有否被勾上，若没有，勾之。如果启动项里连它名字也不见，那就找到该文件，建立一个快捷方式，拖放到开始菜单的“启动”里……