大型高并发高负载网站/论坛的系统架构

一个小型的网站，比如个人网站，可以使用最简单的html静态页面就实现了，配合一些图片达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单，随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。

大型网站，比如门户网站。在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面，还没法根本解决大型网站面临的高负载和高并发问题。

上面提供的几个解决思路在一定程度上也意味着更大的投入，并且这样的解决思路具备瓶颈，没有很好的扩展性，下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。

1、HTML静态化

其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。

同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。

2、图片服务器分离

大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadModule，保证更高的系统消耗和执行效率。

3、数据库集群和库表散列

大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。

在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。

上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

4、缓存

缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。

架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。

网站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了，.net不是很熟悉，相信也肯定有。

5、镜像

镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。

6、负载均衡

负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。
      负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。

硬件四层交换

第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。　第四层交换功能就象是虚 IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。

在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。

软件四层交换

大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。

软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。

一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。这样的架构我准备空了专门详细整理一下和大家探讨。

对于大型网站来说，前面提到的每个方法可能都会被同时使用到，我这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会，有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大，希望大家一起讨论，达到抛砖引玉之效。

      七层交换

      大家都知道TCP/IP的七层协议，四层交换是基于传输层的，在这一层只能处理连接的管理，但是无法和业务关联起来，通常只能针对tcp、udp的连接来进行处理，而真正的业务逻辑需要后面的服务器群自己来处理，随着技术的发展，今天，我们在很多高级的应用中出现了七层交换。

七层交换是基于TCP/IP的第七层应用层来实现的，在这一层上，首先我们可以区分出具体的应用，比如HTTP、TELNET、FTP、DNS等等，还能根据应用中传送的内容来进行策略的管理，比如我们有这么两个网站的路径 a.com/music/… 和a.com/photo/… 原来基于四层交换只能把这两个url的请求都分发到后面一组服务器上，但是七层交换可以判断访问的是music/还是photo/路径，然后分别分发到不通的服务器群上，从而实现更灵活的系统架构设计。

七层交换也分硬件和软件的实现方式，在这里我不细说了，硬件有著名的F5、Nortel等，软件有Haproxy等，当然，七层交换的软件目前还是在性能上要远远差别于硬件实现。

这个架构基于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上直接开启日志功能，按需要统计点击量的链接规则进行记录，然后定期更新数据库

关于大型论坛系统环境搭建(20万日IP负载平衡实战)–Nginx+Apache2+PHP+MySQL
理想论坛为国内人气最旺的股票论坛，注册会员已超过100万，并以每月60000人的速度稳定递增，每日页面访问量超过200万，并保持稳定增长的趋势,60分钟在线平均约2万多人，最高记录3万3千多。 目前主题超过30万，帖子接近1千万，数据库大小5.8GB，附件总大小大约150GB
之前理想论坛有三台服务器，两台WEB服务器以及一台数据库服务器，访问已经渐渐出现瓶颈，在猪头的建议下，站长决定增加一台服务器放数据库，另外三台做WEB，并且对原有的服务器的操作系统进行升级。
硬件具体情况
MySQL服务器： DualXeon 5335/8GB内存/73G SAS硬盘（RAID0+1）/CentOS5.1-x86_64/MySQL5
三台WEB服务器如下：
N1. Dual Xeon 3.0 2GB 内存
N1. Dual Xeon 3.0 4GB 内存
N1. Dual Xeon 3.0(双核) 4G内存
另外有三块300G的SCSI硬盘准备做RAID5，用来存放附件,四台机器通过内网连接
猪头考虑过的解决方案如下:
1. ZEUS + PHP5 + eAccelerator
2. squid + Apache2 + PHP + eAccelerator
3. nginx + PHP(fastcgi) + eAccelerator
4. nginx + Apache2 + PHP + eAccelerator
第一个方案，属于比较完美的，而且很稳定，但是最大的问题是ZEUS是收费软件，用盗版总会受良心责备的,所以暂时押后做候补方案
第二个方案，squid转发请求给Apache2，很多网站都采用这种方式，而且效率也非常高，猪头也测试了一下，但是问题非常严重，因为squid是把文件缓存起来的，所以每一个访问过的文件，squid都要把它打开，理想论坛拥有150G的附件，而且访问量巨大，这种情况下只有打开squid，机器很快就会因为打开文件过多而拒绝响应任何请求了,看来也不适合,只适合缓存文件只有几百M以内的网站.
第三个方案，猪头对第三个方案的测试结果是访问量大的时候，PHP经常会出现bad gateway，看来通过TCP连接Fastcgi执行PHP的方法不够稳定，猪头也测试了通过Unix Socket连接执行PHP，同样还是不稳定.
对比之下，猪头目前使用了第四种解决方案.
Apache2的安装。
(由于服务器采用FreeBSD7，所以大部分软件将会通过ports安装)
由于Apache2只需要处理PHP请求，所以其他模块基本上都不需要，所以不要选择安装其他模块，即使rewrite也不需要，因为rewrite将会在nginx上面实现，如果熟悉，还可以修改Makefile删掉不需要的部分，这样经过优化之后，apache将会以最稳定最高效的方式处理PHP请求
cd /usr/ports/www/apache20
make install clean
修改httpd.conf(这里仅列出要修改/增加的部分)
vi /usr/local/etc/apache2/httpd.conf
把KeepAlive On修改为KeepAlive Off，在下面添加
ServerLimit 2048
MaxClients增加到512
Listen 127.0.0.1:81 #由于httpd服务器不需要对外开放，仅仅处理nginx转发过来的PHP请求，所以仅仅需要监听本地的端口.
另外增加对PHP的支持
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
至于添加虚拟主机的部分将不再罗嗦，注意虚拟主机也监听本地81端口就可以了
PHP5的安装(GD库等模块请提前装好)
cd /usr/ports/lang/php5
修改一下Makefile，把需要的东西加上去吧
本来应该有这样一段的
CONFIGURE_ARGS= \
–with-layout=GNU \
–with-config-file-scan-dir=${PREFIX}/etc/php \
–disable-all \
–enable-libxml \
–with-libxml-dir=${LOCALBASE} \
–enable-reflection \
–program-prefix=”"
我们要把它修改成
CONFIGURE_ARGS= \
–with-layout=GNU \
–with-config-file-scan-dir=${PREFIX}/etc/php \
–disable-all \
–enable-libxml \
–with-libxml-dir=${LOCALBASE} \
–enable-reflection \
–program-prefix=”" \
–with-config-file-path=/etc –enable-mbstring –enable-ftp –with-gd –with-jpeg-dir=/usr/local –with-png-dir=/usr/local –enable-magic-quotes –with-mysql=/usr/local –with-pear –enable-sockets –with-ttf –with-freetype-dir=/usr/local –enable-gd-native-ttf –with-zlib –enable-sysvsem –enable-sysvshm –with-libxml-dir=/usr/local –with-pcre-regex –enable-xml
make install clean
cp work/php-5.2.5/php.ini-dist /etc/php.ini
安装eAccelerator
cd /usr/ports/www/eaccelerator
make install clean
把以下部分添加到php.ini尾端:
extension_dir=”/usr/local/lib/php/555-5555/”
extension=”eaccelerator.so”
eaccelerator.cache_dir=”/tmp/eaccelerator”
eaccelerator.shm_size=”64″
eaccelerator.enable=”1″
eaccelerator.optimizer=”1″
eaccelerator.check_mtime=”1″
eaccelerator.debug=”0″
eaccelerator.filter=”"
eaccelerator.shm_max=”0″
eaccelerator.shm_ttl=”60″
eaccelerator.shm_prune_period=”60″
eaccelerator.shm_only=”0″
eaccelerator.compress=”1″
eaccelerator.compress_level=”9″
eaccelerator.keys=”shm_and_disk”
eaccelerator.sessions=”shm_and_disk”
eaccelerator.content=”shm_and_disk”
建立缓存目录以及修改权限
mkdir /tmp/eaccelerator
chmod 777 /tmp/eaccelerator
chown nobody:nobody /tmp/eaccelerator
nginx的安装以及配置
cd /usr/ports/www/nginx
make install
有几个module是我们需要的，要选上
HTTP module
http_addition module
http_rewrite module
http_realip module
http_stub_status module
其他的看自己需要了
修改配置文件
vi /usr/local/etc/nginx/nginx.conf
user nobody nobody;
worker_processes 4;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid /var/log/nginx.pid;
events {
worker_connections 10240;
}
http {
include mime.types;
default_type application/octet-stream;
limit_zone one $binary_remote_addr 10m;
#log_format main ‘$remote_addr – $remote_user [$time_local] $request ‘
# ‘”$status” $body_bytes_sent “$http_referer” ‘
# ‘”$http_user_agent” “$http_x_forwarded_for”‘;
sendfile off;
tcp_nopush off;
#keepalive_timeout 0;
keepalive_timeout 10;
gzip off;
server {
listen 80;
server_name 网站名 网站名 网站名 网站名 网站名 网站名 网站名 网站名 网站名 网站名 网站名;
index index.html index.htm index.php;
root /home/www;
access_log /dev/null combined;
limit_conn one 5;#限制一个IP并发连接数为五个
error_page 404 /404.html;
error_page 403 /403.html;
location /status {
stub_status on;
access_log off;
auth_basic “NginxStatus”;
auth_basic_user_file conf/htpasswd;
}
#在根目录使用Discuz6.0 rewrite规则,如果你的论坛在二级目录下面,则要相应修改location
location / {
rewrite ^/archiver/((fid|tid)-[\w\-]+\.html)$ /archiver/index.php?$1 last;
rewrite ^/forum-([0-9]+)-([0-9]+)\.html$ /forumdisplay.php?fid=$1&page=$2 last;
rewrite ^/thread-([0-9]+)-([0-9]+)-([0-9]+)\.html$ /viewthread.php?tid=$1&extra=page\%3D$3&page=$2 last;
rewrite ^/space-(username|uid)-(.+)\.html$ /space.php?$1=$2 last;
rewrite ^/tag-(.+)\.html$ /tag.php?name=$1 last;
break;
error_page 404 /404.html;
error_page 403 /403.html;
}
#对附件做防盗链,没有正确的referer将会返回403页面
location ~* ^.+\.(gif|jpg|png|swf|flv|rar|zip|doc|pdf|gz|bz2|jpeg|bmp|xls)$ {
valid_referers none blocked server_names *.55188.NET *.55188.com;
if ($invalid_referer) {
rewrite ^/ http://
}
}
#转发PHP请求到本地的81端口,让Apache处理.
location ~ \.php$ {
proxy_pass http://127.0.0.1:81;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_hide_header Content-Type;
}
}
}
测试一下你的配置文件是否都正确
/usr/local/sbin/apachectl configtest
/usr/local/sbin/nginx -t
都没问题的话就启动服务器吧
/usr/local/sbin/apachectl start
/usr/local/sbin/nginx -c /usr/local/etc/nginx/nginx.conf
浏览一下主页，应该正常了
后继讨论，
1.数据库.
数据库的编译安装不再重复讨论，仅仅讨论环境，由于理想论坛的数据库比较大，而且发展比较快，所以要作比较前一点的预算，硬盘需要使用15K RPM的SAS硬盘做RAID0+1，操作系统需要使用64位版本，因为服务器需要8GB内存，要注意的时，使用了64位系统之后部分比较老的软件可能你无法找到64位的版本，这台机器就专门做MySQL服务器吧，如果数据库超过10G，应该考虑MySQL_Cluster
2.附件.
因为有三台服务器做WEB，所以附件要使用nfs的方式通过内网进行共享，至于如何设置nfs这里不再讨论，如果有不明白的请将学费交给Google
3.WEB.
由于三台机器硬件配置不一致,所以有必要考虑一下负载平衡的问题,nginx本身附带有负载平衡的功能,但是如果启用负载平衡的功能的话,每台机器都将会把客户端请求的数据缓存到本机,这样增加了硬盘的IO,对于理想论坛的访问量来说,这是个不小的开销,最后我们是使用DNS查询的方式来分配流量, 通过不同的A记录,配置好点的机器，多分一条A记录，配置差的就少一条A记录，这样从整体上看，流量分配应该比较平衡.
4.关于nginx并发连接
猪头给nginx限制了每个IP的并发连接，因为对于大论坛来说，总是比较出名的，不说人家攻击你什么的.采集都特别多,如果不限制,很容易出问题,经常会导致PHP罢工.
以上只是猪头愚见，如果有其他进展，猪头会更新本贴，如有疑问或者不同见解，欢迎提出讨论
当然还有很多很疯狂的方法，例如说把WEB文件(附件除外)全部放内存里面，MYSQL如果小于5G，也可以全部放内存里面，不过这些方法都是太极端的了，优化效果须然好，但是风险很大。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
优化之后的效果
由于还有两台机器升级没完成，只帖一下其中一台WEB的状况了。目前
Active connections: 1143
server accepts handled requests
555-5555555-5555555-5555
Reading: 67 Writing: 136 Waiting: 940
Apache最优化要关闭不用的模块，因为httpd请求全部让nginx处理了，Apache仅仅需要处理PHP就可以了，目前我开启的模块
LoadModule access_module libexec/apache2/mod_access.so
LoadModule setenvif_module libexec/apache2/mod_setenvif.so
LoadModule mime_module libexec/apache2/mod_mime.so
LoadModule autoindex_module libexec/apache2/mod_autoindex.so
LoadModule negotiation_module libexec/apache2/mod_negotiation.so
LoadModule alias_module libexec/apache2/mod_alias.so
LoadModule rewrite_module libexec/apache2/mod_rewrite.so
LoadModule php5_module libexec/apache2/libphp5.so
autoindex negotiation以及rewrite这些应该都关闭的，但是要做相应的修改.目前跑起来绝对比Fastcgi要好

最近，帮一个朋友优化一个拥有20万主题，100万帖子，3万多会员，平均在线人数2000人的Discuz!论坛，采用 Linux2.6+Apache2+mod_php5+MySQL5，服务器配置为双至强+4G内存，优化前，系统平均负载（load average）基本维持在10以上，MySQL的CPU占用率基本在90%以上，优化后，系统平均负载降到0.5以下，MySQL的CPU占用率很少有 超过10%的时候。优化前YSlow得分只有35分，优化后YSlow得分86分。现将优化的过程和经验做一个记录：

首先，对Apache进行优化，编辑httpd.conf，设置 HostnameLookups、KeepAlive、MaxKeepAliveRequests以及KeepAliveTimeout四个参数，调整 MaxSpareServers、ServerLimit、MaxClients以及MaxRequestsPerChild参数，还可以考虑弃用 prefork而采用worker MPM。设置mod_deflate及mod_expires模块，不过注意Discuz!不能对PHP文件开启Expires，否则会出现问题。另外还 可以考虑开启mod_cache和mod_mem_cache模块。另外利用cronolog按天对日志进行轮循截断，如果日志特别大，也可以按小时截 断。另外再加上Awstats对日志进行分析，并用gzip对日志进行压缩，自动删除1个月前的日志。

其次，对PHP进行优化，编辑php.ini，调整output_buffering、zlib.output_compression及 max_execution_time、max_input_time、memory_limit等参数，并安装Xcache和Zend Optimizer。

然后对MySQL进行优化。首先重新静态编译MySQL，使其只支持MyISAM和Memory两种引擎，并按Discuz!编码选择只支持 UTF-8或者GBK字符集。编辑my.cnf，设置skip-locking、skip-external-locking、skip- networking和skip-name-resolve，根据内存和数据库状态具体调整key_buffer_size、 query_cache_size、query_cache_limit、max_allowed_packet、table_cache、 thread_cache_size、sort_buffer_size、read_buffer_size、 read_rnd_buffer_size、join_buffer_size、tmp_table_size、max_tmp_tables、 back_log、max_connections、wait_timeout的参数。

对数据库进行优化，将threads和posts表中部分未索引的字段增加索引，并将supersite数据库表从bbs数据库独立出去。修改discuz!配置文件，设置开启pconnect。

对Discuz！设置进行优化。进入Discuz!系统设置，修改页面缓存设置中的缓存有效期和缓存系数，修改服务器优化中的禁止浏览器缓冲和页面 Gzip压缩，修改防盗链设置中下载附件来路检查，用JSMin自动对js文件进行缩减（Discuz! 6.1的common.js原文件29.3k，经JSMin缩减后为24.1k，再经deflate后为7.3k），修改attachments.php 文件，将：

//dheader('Cache-control: max-age=31536000');
//dheader('Expires: '.gmdate('D, d M Y H:i:s', $timestamp + 31536000).' GMT');

前的注释去掉。修改模板目录下adv.htm，去掉与Insenz有关的代码。

通过查看MySQL的status，可以看出优化后，长时间运行的Key_read_ratio基本保持在0.05%以 下，Threads_cache_hitrate保持在99.9%以上。个人感觉，Discuz!将Session保存在数据库中，极大地降低了 Query Cache的命中率，如果需要进一步优化，可以考虑修改Discuz!源码，将Session保存到Memcache中。

优化之后用Siege做并发压力测试，在200并发下，基本没有任何错误。如果将来人数更多，可以考虑将平台迁移到Ngix+PHP FastCGI上。

下面是用Siege在300并发下的测试结果：

#siege -c 300 -b -r 35 -f bbs.url
** SIEGE 2.67
** Preparing 300 concurrent users for battle.
The server is now under siege..      done.
Transactions:                  10500 hits
Availability:                 100.00 %
Elapsed time:                  52.68 secs
Data transferred:              65.67 MB
Response time:                  1.27 secs
Transaction rate:             199.32 trans/sec
Throughput:                     1.25 MB/sec
Concurrency:                  253.07
Successful transactions:       10500
Failed transactions:               0
Longest transaction:           24.88
Shortest transaction:           0.00

500并发下的测试结果：

#siege -c 500 -b -r 20 -f bbs.url
** SIEGE 2.67
** Preparing 300 concurrent users for battle.
The server is now under siege..      done.
Transactions:                   9979 hits
Availability:                  99.79 %
Elapsed time:                  86.52 secs
Data transferred:              82.66 MB
Response time:                  3.30 secs
Transaction rate:             115.34 trans/sec
Throughput:                     0.96 MB/sec
Concurrency:                  381.07
Successful transactions:        9979
Failed transactions:              21
Longest transaction:           34.80
Shortest transaction:           0.00

昨天，将服务器迁移到了Nginx+php-fpm，以下是迁移后测试，相差真的很明显，回头再写Nginx+php-fpm的经验：

[root@BBS ~]# siege -c 300 -r 50 -f bbs.url
** SIEGE 2.67
** Preparing 300 concurrent users for battle.
The server is now under siege..      done.
Transactions:                  15000 hits
Availability:                 100.00 %
Elapsed time:                  64.12 secs
Data transferred:              67.79 MB
Response time:                  0.55 secs
Transaction rate:             233.94 trans/sec
Throughput:                     1.06 MB/sec
Concurrency:                  128.95
Successful transactions:       14976
Failed transactions:               0
Longest transaction:            3.96
Shortest transaction:           0.00

[root@bbs ~]# siege -c 500 -r 50 -f bbs.url
** SIEGE 2.67
** Preparing 500 concurrent users for battle.
The server is now under siege..      done.
Transactions:                  25000 hits
Availability:                 100.00 %
Elapsed time:                  65.52 secs
Data transferred:              83.65 MB
Response time:                  0.57 secs
Transaction rate:             381.56 trans/sec
Throughput:                     1.28 MB/sec
Concurrency:                  216.02
Successful transactions:       21707
Failed transactions:               0
Longest transaction:            5.83
Shortest transaction:           0.00