从“军事战争”总结了一些服务器架构思考[原创]
[
2009-5-28 15:31 | by 张宴 ]
2009-5-28 15:31 | by 张宴 ]
[文章作者：张宴 本文版本：v1.0 最后修改：2009.05.28 转载请注明原文链接：http://blog.zyan.cc/post/414/]
“客户端访问”与“服务器端响应”，犹如一场战争。初期，访问量较小，弄几台服务器随便拉起一只队伍，就能抵抗住客户端的进攻。慢慢的，访问量大起来，这时候，就需要讲究排兵布阵、战略战术、多兵种协调作战。于是，开始有了负载均衡服务器、Web服务器、缓存服务器、数据库服务器、存储服务器等多兵种；开始有了系统架构等战略战术。随着新项目和运营需求的越来越多，我们开始了多线作战。慢慢地，我总结了以下一些思考：
1、“收编绿林队伍”与“自己招兵买马”：
两者的关系就犹如“使用开源软件、框架”与“自己开发模块、写框架”，如果已有的开源软件、框架、架构能够较好地用于自己的项目，并便于扩展，则优先使用开源软件；如果没有现成的东西，或者已有的开源软件性能不高、扩展性差、学习成本高，则可以取长补短，在项目中打造自己的“队伍”。
2、适当利用“雇佣军”：
在多个项目同时进行时，不要认为自己能打赢每一场战斗，而每一场战斗都由自己亲自去打。确实，我相信很多人能够打赢一场场战斗，却只有少数人能够打赢一场战争。前暴雪北方“四大佬”创建的旗舰工作室的倒闭，印证了这样一个事实：一群天才，却没有让一个划时代意义的游戏诞生。旗舰工作室放着捷径不走却事必躬亲，自己做客户端、自己做语聊系统、自己做图像引擎、自己做客服系统，最终自己被自己给拖垮了。
不要让战线拉得太广，适当利用“雇佣军”，项目中的一些非重要、非核心的组成部分可以购买其他公司的成熟产品与服务，时间、费用、维护成本可能要更低。最近，我工作中的两项服务使用了“雇佣军”：(1)、购买ChinaCache CDN的Flash Media Server点播加速服务，支撑金山游戏视频宣传站点，节省了部署多节点的成本和时间；(2)、购买快网的智能DNS解析服务，来做金山游戏官网动态内容“北京多线、珠海电信、天津网通”三个机房服务器的智能DNS解析服务，节省了收集、整理，将来更新维护IP信息等工作。
3、打造“高技术兵器”：
现代战争的特点都拥一个有共同的前提那就是：都不可能离开“高技术兵器”。同样，要想承担高并发访问，而又希望系统架构简单一点、程序开发快捷一点，那么，则需要一款服务器端的“高技术兵器”。Web 2.0网站主要组成部分有内容页和列表页，内容页可以采用key-value形式的Memcached、Squid等开源产品来实现缓存，高并发访问下需要实时更新的列表页缓存，目前还没有合适的开源产品来解决。MySQL等数据库在高并发连接、大数据记录情况下性能低下，实时更新的列表页，成为最主要的瓶颈。我目前正在基于一些开源类库，开发的一款简单关系型数据库，将实现MySQL单表拥有的大部分复杂条件查询功能，并将达到单表千万级以上记录下，Memcached 60%左右的并发查询性能，预计6月6日开发完成进入测试阶段。
4、精简军队，提高战斗力：
军队越多，补给、后勤等开支也会越大，同样，服务器越多，维护成本、托管成本、复杂度也越高。所以，服务器不是越多越好，在能够保证容错性、避免单点故障的情况下，如果能用一台高配置服务器来解决的事，不要同两台低配置的服务器来干。
传统的系统架构只不过围绕负载均衡设备或服务器、Web服务器集群、数据库服务器集群、搜索引擎服务器集群、分布式存储服务器集群、缓存系统服务器集群等等，技术含量并不是特别高，只不过很多人没有生产环境的机会去实践而已。随着内存价格的下降，单台服务器扩充到64G内存的事情不再罕见；Intel将会在下周面向高端服务器领域发布代号为Nehalem-EX的8核XEON处理器。随着硬件性能的不断提高，我预测，将来的系统架构与服务器集群将不再从服务类型上划分，而将按“CPU密集型服务器集群”、“内存密集型服务器集群”、“存储密集型服务器集群”划分。我现在所设计的架构与开发的服务器端程序，也逐渐向后者转移。
最近，Google的工程师Luiz André Barroso and Urs Hölzle发表了一篇长达120页的论文，提出了一个数据中心就是一台计算机（The Datacenter as a Computer - An Introduction to the Design of Warehouse-Scale Machines ）
“客户端访问”与“服务器端响应”，犹如一场战争。初期，访问量较小，弄几台服务器随便拉起一只队伍，就能抵抗住客户端的进攻。慢慢的，访问量大起来，这时候，就需要讲究排兵布阵、战略战术、多兵种协调作战。于是，开始有了负载均衡服务器、Web服务器、缓存服务器、数据库服务器、存储服务器等多兵种；开始有了系统架构等战略战术。随着新项目和运营需求的越来越多，我们开始了多线作战。慢慢地，我总结了以下一些思考：
1、“收编绿林队伍”与“自己招兵买马”：
两者的关系就犹如“使用开源软件、框架”与“自己开发模块、写框架”，如果已有的开源软件、框架、架构能够较好地用于自己的项目，并便于扩展，则优先使用开源软件；如果没有现成的东西，或者已有的开源软件性能不高、扩展性差、学习成本高，则可以取长补短，在项目中打造自己的“队伍”。
2、适当利用“雇佣军”：
在多个项目同时进行时，不要认为自己能打赢每一场战斗，而每一场战斗都由自己亲自去打。确实，我相信很多人能够打赢一场场战斗，却只有少数人能够打赢一场战争。前暴雪北方“四大佬”创建的旗舰工作室的倒闭，印证了这样一个事实：一群天才，却没有让一个划时代意义的游戏诞生。旗舰工作室放着捷径不走却事必躬亲，自己做客户端、自己做语聊系统、自己做图像引擎、自己做客服系统，最终自己被自己给拖垮了。
不要让战线拉得太广，适当利用“雇佣军”，项目中的一些非重要、非核心的组成部分可以购买其他公司的成熟产品与服务，时间、费用、维护成本可能要更低。最近，我工作中的两项服务使用了“雇佣军”：(1)、购买ChinaCache CDN的Flash Media Server点播加速服务，支撑金山游戏视频宣传站点，节省了部署多节点的成本和时间；(2)、购买快网的智能DNS解析服务，来做金山游戏官网动态内容“北京多线、珠海电信、天津网通”三个机房服务器的智能DNS解析服务，节省了收集、整理，将来更新维护IP信息等工作。
3、打造“高技术兵器”：
现代战争的特点都拥一个有共同的前提那就是：都不可能离开“高技术兵器”。同样，要想承担高并发访问，而又希望系统架构简单一点、程序开发快捷一点，那么，则需要一款服务器端的“高技术兵器”。Web 2.0网站主要组成部分有内容页和列表页，内容页可以采用key-value形式的Memcached、Squid等开源产品来实现缓存，高并发访问下需要实时更新的列表页缓存，目前还没有合适的开源产品来解决。MySQL等数据库在高并发连接、大数据记录情况下性能低下，实时更新的列表页，成为最主要的瓶颈。我目前正在基于一些开源类库，开发的一款简单关系型数据库，将实现MySQL单表拥有的大部分复杂条件查询功能，并将达到单表千万级以上记录下，Memcached 60%左右的并发查询性能，预计6月6日开发完成进入测试阶段。
4、精简军队，提高战斗力：
军队越多，补给、后勤等开支也会越大，同样，服务器越多，维护成本、托管成本、复杂度也越高。所以，服务器不是越多越好，在能够保证容错性、避免单点故障的情况下，如果能用一台高配置服务器来解决的事，不要同两台低配置的服务器来干。
传统的系统架构只不过围绕负载均衡设备或服务器、Web服务器集群、数据库服务器集群、搜索引擎服务器集群、分布式存储服务器集群、缓存系统服务器集群等等，技术含量并不是特别高，只不过很多人没有生产环境的机会去实践而已。随着内存价格的下降，单台服务器扩充到64G内存的事情不再罕见；Intel将会在下周面向高端服务器领域发布代号为Nehalem-EX的8核XEON处理器。随着硬件性能的不断提高，我预测，将来的系统架构与服务器集群将不再从服务类型上划分，而将按“CPU密集型服务器集群”、“内存密集型服务器集群”、“存储密集型服务器集群”划分。我现在所设计的架构与开发的服务器端程序，也逐渐向后者转移。
最近，Google的工程师Luiz André Barroso and Urs Hölzle发表了一篇长达120页的论文，提出了一个数据中心就是一台计算机（The Datacenter as a Computer - An Introduction to the Design of Warehouse-Scale Machines ）
Nginx 0.8.x + PHP 5.2.10（FastCGI）搭建胜过Apache十倍的Web服务器（第5版）[原创]
[ 2009-5-6 13:40 | by 张宴 ]
2009-5-6 13:40 | by 张宴 ]
本文已有最新版本：
请点击《Nginx 0.8.x + PHP 5.2.13（FastCGI）搭建胜过Apache十倍的Web服务器（第6版）》
[文章作者：张宴 本文版本：v5.5 最后修改：2009.09.18 转载请注明原文链接：http://blog.zyan.cc/nginx_php_v5/]
前言：本文是我撰写的关于搭建“Nginx + PHP（FastCGI）”Web服务器的第5篇文章。本系列文章作为国内最早详细介绍 Nginx + PHP 安装、配置、使用的资料之一，为推动 Nginx 在国内的发展产生了积极的作用。这是一篇关于Nginx 0.7.x系列版本的文章，安装、配置方式与第4篇文章相差不大，但增加了MySQL安装配置的信息、PHP 5.2.10 的 php-fpm 补丁。Nginx 0.7.x系列版本虽然为开发版，但在很多大型网站的生产环境中已经使用。
链接：《2007年9月的第1版》、《2007年12月的第2版》、《2008年6月的第3版》、《2008年8月的第4版》
Nginx ("engine x") 是一个高性能的 HTTP 和反向代理服务器，也是一个 IMAP/POP3/SMTP 代理服务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的，它已经在该站点运行超过两年半了。Igor 将源代码以类BSD许可证的形式发布。
Nginx 超越 Apache 的高性能和稳定性，使得国内使用 Nginx 作为 Web 服务器的网站也越来越多，其中包括新浪博客、新浪播客、网易新闻等门户网站频道，六间房、56.com等视频分享网站，Discuz!官方论坛、水木社区等知名论坛，豆瓣、YUPOO相册、海内SNS、迅雷在线等新兴Web 2.0网站。
Nginx 的官方中文维基：http://wiki.nginx.org/NginxChs
在高并发连接的情况下，Nginx是Apache服务器不错的替代品。Nginx同时也可以作为7层负载均衡服务器来使用。根据我的测试结果，Nginx 0.8.15 + PHP 5.2.10 (FastCGI) 可以承受3万以上的并发连接数，相当于同等环境下Apache的10倍。
根据我的经验，4GB内存的服务器+Apache（prefork模式）一般只能处理3000个并发连接，因为它们将占用3GB以上的内存，还得为系统预留1GB的内存。我曾经就有两台Apache服务器，因为在配置文件中设置的MaxClients为4000，当Apache并发连接数达到3800时，导致服务器内存和Swap空间用满而崩溃。
而这台 Nginx 0.8.15 + PHP 5.2.10 (FastCGI) 服务器在3万并发连接下，开启的10个Nginx进程消耗150M内存（15M*10=150M），开启的64个php-cgi进程消耗1280M内存（20M*64=1280M），加上系统自身消耗的内存，总共消耗不到2GB内存。如果服务器内存较小，完全可以只开启25个php-cgi进程，这样php-cgi消耗的总内存数才500M。
在3万并发连接下，访问Nginx 0.8.15 + PHP 5.2.10 (FastCGI) 服务器的PHP程序，仍然速度飞快。下图为Nginx的状态监控页面，显示的活动连接数为28457（关于Nginx的监控页配置，会在本文接下来所给出的Nginx配置文件中写明）：
我生产环境下的两台Nginx + PHP5（FastCGI）服务器，跑多个一般复杂的纯PHP动态程序，单台Nginx + PHP5（FastCGI）服务器跑PHP动态程序的处理能力已经超过“700次请求/秒”，相当于每天可以承受6000万（700*60*60*24=60480000）的访问量（更多信息见此），而服务器的系统负载也不高：
2009年9月3日下午2：30，金山游戏《剑侠情缘网络版叁》临时维护1小时（http://kefu.xoyo.com/gonggao/jx3/2009-09-03/750438.shtml），大量玩家上官网，论坛、评论、客服等动态应用Nginx服务器集群，每台服务器的Nginx活动连接数达到2.8万，这是笔者遇到的Nginx生产环境最高并发值。
下面是用100个并发连接分别去压生产环境中同一负载均衡器VIP下、提供相同服务的两台服务器，一台为Nginx，另一台为Apache，Nginx每秒处理的请求数是Apache的两倍多，Nginx服务器的系统负载、CPU使用率远低于Apache：
你可以将连接数开到10000～30000，去压Nginx和Apache上的phpinfo.php，这是用浏览器访问Nginx上的phpinfo.php一切正常，而访问Apache服务器的phpinfo.php，则是该页无法显示。4G内存的服务器，即使再优化，Apache也很难在“webbench -c 30000 -t 60 http://xxx.xxx.xxx.xxx/phpinfo.php”的压力情况下正常访问，而调整参数优化后的Nginx可以。
webbench 下载地址：http://blog.zyan.cc/post/288/
注意：webbench 做压力测试时，该软件自身也会消耗CPU和内存资源，为了测试准确，请将 webbench 安装在别的服务器上。
测试结果：##### Nginx + PHP #####
测试结果：##### Apache + PHP #####
为什么Nginx的性能要比Apache高得多？这得益于Nginx使用了最新的epoll（Linux 2.6内核）和kqueue（freebsd）网络I/O模型，而Apache则使用的是传统的select模型。目前Linux下能够承受高并发访问的Squid、Memcached都采用的是epoll网络I/O模型。
处理大量的连接的读写，Apache所采用的select网络I/O模型非常低效。下面用一个比喻来解析Apache采用的select模型和Nginx采用的epoll模型进行之间的区别：
假设你在大学读书，住的宿舍楼有很多间房间，你的朋友要来找你。select版宿管大妈就会带着你的朋友挨个房间去找，直到找到你为止。而epoll版宿管大妈会先记下每位同学的房间号，你的朋友来时，只需告诉你的朋友你住在哪个房间即可，不用亲自带着你的朋友满大楼找人。如果来了10000个人，都要找自己住这栋楼的同学时，select版和epoll版宿管大妈，谁的效率更高，不言自明。同理，在高并发服务器中，轮询I/O是最耗时间的操作之一，select和epoll的性能谁的性能更高，同样十分明了。
安装步骤：
（系统要求：Linux 2.6+ 内核，本文中的Linux操作系统为CentOS 5.3，另在RedHat AS4上也安装成功）
请点击《Nginx 0.8.x + PHP 5.2.13（FastCGI）搭建胜过Apache十倍的Web服务器（第6版）》
[文章作者：张宴 本文版本：v5.5 最后修改：2009.09.18 转载请注明原文链接：http://blog.zyan.cc/nginx_php_v5/]
前言：本文是我撰写的关于搭建“Nginx + PHP（FastCGI）”Web服务器的第5篇文章。本系列文章作为国内最早详细介绍 Nginx + PHP 安装、配置、使用的资料之一，为推动 Nginx 在国内的发展产生了积极的作用。这是一篇关于Nginx 0.7.x系列版本的文章，安装、配置方式与第4篇文章相差不大，但增加了MySQL安装配置的信息、PHP 5.2.10 的 php-fpm 补丁。Nginx 0.7.x系列版本虽然为开发版，但在很多大型网站的生产环境中已经使用。
链接：《2007年9月的第1版》、《2007年12月的第2版》、《2008年6月的第3版》、《2008年8月的第4版》
Nginx ("engine x") 是一个高性能的 HTTP 和反向代理服务器，也是一个 IMAP/POP3/SMTP 代理服务器。 Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 Rambler.ru 站点开发的，它已经在该站点运行超过两年半了。Igor 将源代码以类BSD许可证的形式发布。
Nginx 超越 Apache 的高性能和稳定性，使得国内使用 Nginx 作为 Web 服务器的网站也越来越多，其中包括新浪博客、新浪播客、网易新闻等门户网站频道，六间房、56.com等视频分享网站，Discuz!官方论坛、水木社区等知名论坛，豆瓣、YUPOO相册、海内SNS、迅雷在线等新兴Web 2.0网站。
Nginx 的官方中文维基：http://wiki.nginx.org/NginxChs
在高并发连接的情况下，Nginx是Apache服务器不错的替代品。Nginx同时也可以作为7层负载均衡服务器来使用。根据我的测试结果，Nginx 0.8.15 + PHP 5.2.10 (FastCGI) 可以承受3万以上的并发连接数，相当于同等环境下Apache的10倍。
根据我的经验，4GB内存的服务器+Apache（prefork模式）一般只能处理3000个并发连接，因为它们将占用3GB以上的内存，还得为系统预留1GB的内存。我曾经就有两台Apache服务器，因为在配置文件中设置的MaxClients为4000，当Apache并发连接数达到3800时，导致服务器内存和Swap空间用满而崩溃。
而这台 Nginx 0.8.15 + PHP 5.2.10 (FastCGI) 服务器在3万并发连接下，开启的10个Nginx进程消耗150M内存（15M*10=150M），开启的64个php-cgi进程消耗1280M内存（20M*64=1280M），加上系统自身消耗的内存，总共消耗不到2GB内存。如果服务器内存较小，完全可以只开启25个php-cgi进程，这样php-cgi消耗的总内存数才500M。
在3万并发连接下，访问Nginx 0.8.15 + PHP 5.2.10 (FastCGI) 服务器的PHP程序，仍然速度飞快。下图为Nginx的状态监控页面，显示的活动连接数为28457（关于Nginx的监控页配置，会在本文接下来所给出的Nginx配置文件中写明）：
我生产环境下的两台Nginx + PHP5（FastCGI）服务器，跑多个一般复杂的纯PHP动态程序，单台Nginx + PHP5（FastCGI）服务器跑PHP动态程序的处理能力已经超过“700次请求/秒”，相当于每天可以承受6000万（700*60*60*24=60480000）的访问量（更多信息见此），而服务器的系统负载也不高：
2009年9月3日下午2：30，金山游戏《剑侠情缘网络版叁》临时维护1小时（http://kefu.xoyo.com/gonggao/jx3/2009-09-03/750438.shtml），大量玩家上官网，论坛、评论、客服等动态应用Nginx服务器集群，每台服务器的Nginx活动连接数达到2.8万，这是笔者遇到的Nginx生产环境最高并发值。
下面是用100个并发连接分别去压生产环境中同一负载均衡器VIP下、提供相同服务的两台服务器，一台为Nginx，另一台为Apache，Nginx每秒处理的请求数是Apache的两倍多，Nginx服务器的系统负载、CPU使用率远低于Apache：
你可以将连接数开到10000～30000，去压Nginx和Apache上的phpinfo.php，这是用浏览器访问Nginx上的phpinfo.php一切正常，而访问Apache服务器的phpinfo.php，则是该页无法显示。4G内存的服务器，即使再优化，Apache也很难在“webbench -c 30000 -t 60 http://xxx.xxx.xxx.xxx/phpinfo.php”的压力情况下正常访问，而调整参数优化后的Nginx可以。
webbench 下载地址：http://blog.zyan.cc/post/288/
注意：webbench 做压力测试时，该软件自身也会消耗CPU和内存资源，为了测试准确，请将 webbench 安装在别的服务器上。
测试结果：##### Nginx + PHP #####
引用
[root@localhost webbench-1.5]# webbench -c 100 -t 30 http://192.168.1.21/phpinfo.php
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://192.168.1.21/phpinfo.php
100 clients, running 30 sec.
Speed=102450 pages/min, 16490596 bytes/sec.
Requests: 51225 susceed, 0 failed.
top - 14:06:13 up 27 days, 2:25, 2 users, load average: 14.57, 9.89, 6.51
Tasks: 287 total, 4 running, 283 sleeping, 0 stopped, 0 zombie
Cpu(s): 49.9% us, 6.7% sy, 0.0% ni, 41.4% id, 1.1% wa, 0.1% hi, 0.8% si
Mem: 6230016k total, 2959468k used, 3270548k free, 635992k buffers
Swap: 2031608k total, 3696k used, 2027912k free, 1231444k cached
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://192.168.1.21/phpinfo.php
100 clients, running 30 sec.
Speed=102450 pages/min, 16490596 bytes/sec.
Requests: 51225 susceed, 0 failed.
top - 14:06:13 up 27 days, 2:25, 2 users, load average: 14.57, 9.89, 6.51
Tasks: 287 total, 4 running, 283 sleeping, 0 stopped, 0 zombie
Cpu(s): 49.9% us, 6.7% sy, 0.0% ni, 41.4% id, 1.1% wa, 0.1% hi, 0.8% si
Mem: 6230016k total, 2959468k used, 3270548k free, 635992k buffers
Swap: 2031608k total, 3696k used, 2027912k free, 1231444k cached
测试结果：##### Apache + PHP #####
引用
[root@localhost webbench-1.5]# webbench -c 100 -t 30 http://192.168.1.27/phpinfo.php
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://192.168.1.27/phpinfo.php
100 clients, running 30 sec.
Speed=42184 pages/min, 31512914 bytes/sec.
Requests: 21092 susceed, 0 failed.
top - 14:06:20 up 27 days, 2:13, 2 users, load average: 62.15, 26.36, 13.42
Tasks: 318 total, 7 running, 310 sleeping, 0 stopped, 1 zombie
Cpu(s): 80.4% us, 10.6% sy, 0.0% ni, 7.9% id, 0.1% wa, 0.1% hi, 0.9% si
Mem: 6230016k total, 3075948k used, 3154068k free, 379896k buffers
Swap: 2031608k total, 12592k used, 2019016k free, 1117868k cached
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://192.168.1.27/phpinfo.php
100 clients, running 30 sec.
Speed=42184 pages/min, 31512914 bytes/sec.
Requests: 21092 susceed, 0 failed.
top - 14:06:20 up 27 days, 2:13, 2 users, load average: 62.15, 26.36, 13.42
Tasks: 318 total, 7 running, 310 sleeping, 0 stopped, 1 zombie
Cpu(s): 80.4% us, 10.6% sy, 0.0% ni, 7.9% id, 0.1% wa, 0.1% hi, 0.9% si
Mem: 6230016k total, 3075948k used, 3154068k free, 379896k buffers
Swap: 2031608k total, 12592k used, 2019016k free, 1117868k cached
为什么Nginx的性能要比Apache高得多？这得益于Nginx使用了最新的epoll（Linux 2.6内核）和kqueue（freebsd）网络I/O模型，而Apache则使用的是传统的select模型。目前Linux下能够承受高并发访问的Squid、Memcached都采用的是epoll网络I/O模型。
处理大量的连接的读写，Apache所采用的select网络I/O模型非常低效。下面用一个比喻来解析Apache采用的select模型和Nginx采用的epoll模型进行之间的区别：
假设你在大学读书，住的宿舍楼有很多间房间，你的朋友要来找你。select版宿管大妈就会带着你的朋友挨个房间去找，直到找到你为止。而epoll版宿管大妈会先记下每位同学的房间号，你的朋友来时，只需告诉你的朋友你住在哪个房间即可，不用亲自带着你的朋友满大楼找人。如果来了10000个人，都要找自己住这栋楼的同学时，select版和epoll版宿管大妈，谁的效率更高，不言自明。同理，在高并发服务器中，轮询I/O是最耗时间的操作之一，select和epoll的性能谁的性能更高，同样十分明了。
安装步骤：
（系统要求：Linux 2.6+ 内核，本文中的Linux操作系统为CentOS 5.3，另在RedHat AS4上也安装成功）
