[转]高负载并发网站架构分析
时间：2022-08-15 07:00:00
因为我正在做一个高性能、大用户的论坛程序，对高性能、高并发性的服务器架构感兴趣，所以我在网上收集了很多信息与大家分享。我希望我能和你交流
msn: defender_ios@hotmail.com
———————————————————————————————————————
? 创建网站和开源软件 6
? 谈谈大型高负荷网站服务器的优化经验！ 8
? Lighttpd Squid Apache搭建高效率Web服务器 9
? 浏览量大的网站应该从哪些方面入手？ 17
? 用负载平衡技术建设高负载站点 20
? 大型网站的架构设计问题 25
? 开源平台的高并发集群思维 26
? 大型、高负荷网站架构和应用初步探索 时间：30-45分钟 27
? 谈谈大型高并发高负荷网站的系统架构 28
? mixi技术架构 51
mixi.jp：可扩展的开源软件SNS网站 51
总概要点: 51
1，Mysql 切分，采用Innodb运行 52
2，动态Cache 服务器 -- 52
美国Facebok.com,中国Yeejee.com,日本mixi.jp开源分布式缓存服务器均采用Memcache 52
3.图片缓存和添加 52
? memcached squid apache deflate解决网站大访问量问题 52
? FeedBurner:基于MySQL和JAVA的可扩展Web应用 53
? YouTube 的架构扩展 55
? 了解一下 Technorati 后台数据库架构 57
? Myspace架构历程 58
? eBay 的数据量 64
? eBay 应用服务器规模 67
? eBay 数据库分布扩展架构 68
? 从LiveJournal后台发展看大规模网站性能优化方法 70
一、LiveJournal发展历程 70
二、LiveJournal结构现状概况 70
三、从LiveJournal发展中学习 71
1.服务器 71
两台服务器 72
三、四台服务器 73
四、五台服务器 73
更多的服务器 74
我们现在在哪里： 75
我们现在在哪里？ 78
我们现在在哪里？ 79
9、缓存 80
10、Web访问负载均衡 80
11、MogileFS 81
? Craigslist 数据库架构 81
? Second Life 的数据拾零 82
? eBay思想金矿的结构 84
? 每天10亿次访问-eBay架构（一） 85
? 用武器缓存七种 加快网站应用和访问的发布时间： 92
? 可缓存的CMS系统设计 93
? 开发大型高负荷网站应用的几个要点[nightsailer] 105
? Memcached和Lucene笔记 110
? 开源软件的设计可以扩展网站 110
? 高负荷架构Lighttpd PHP(FastCGI) Memcached Squid 113
? 高并发高负载网站的系统架构 113
? "我在SOHU近年来，一些门户级程序系统(C/C 开发)" 115
? 中国顶级门户网站架构分析1 116
? 分析中国顶级门户网站架构 2 118
? 服务器用户数量大的承载方案 120
? YouTube Scalability Talk 121
? High Performance Web Sites by Nate Koechley 123
One dozen rules for faster pages 123
Why talk about performance? 123
Case Studies 124
Conclusion 124
? Rules for High Performance Web Sites 124
? 高并发应用，DB如何设计数千万的系统？ 125
? 高性能服务器设计 130
? 优点与应用：再谈CDN镜像加速技术 131
? 除程序设计优化外，zend eacc(memcached)另外，如何提高服务器的负载能力？ 135
? 如何规划你的大规模JAVA多并发服务器程序 139
? 如何构建Just so so”的网站？ 148
? 最便宜的高负荷网站架构 152
? 负载均衡技术全攻略 154
? 海量数据处理分析 164
? 一个很有意义的SQL优化过程(电子分公司大数据量统计)SQL） 166
? 如何优化大数据量模糊查询(架构，数据库设置，SQL..） 168
? 求助:海量数据处理方法 169
# re: 求助:海量数据处理方法 回复 更多评论 169
? 大量数据库查询策略 169
? SQL Server 2005年海量数据处理 170
? 分表处理设计思想和实现 174
? Linux系统高负载 MySQL完全优化数据库(1) 179
? 大型数据库的设计和编程技巧 我最近开发了一个访问统计系统，日志很大，都保存在数据库里。 我现在按照常规的设计方法设计表，查询很慢。 如何在这种情况下设计数据库？把一个表分成多个表吗？那么查询和插入数据库的技巧是什么呢？ 谢谢，村里的兄弟们！ 183
? 方案讨论，关于工程数据库的问题. [已结贴] 184
? web在设计软件时，考虑您的性能解决方案 190
? 大型Java Web讨论了系统服务器型问题 193
? 高并发高流量网站架构 210
1.1 互联网的发展 210
1.2 互联网网站建设的新趋势 210
1.3 新浪播客简介 211
2.1 镜像网站技术 211
2.2 CDN内容分发网络 213
2.3 应用层分布式设计 214
2.4 总结网络层架构 214
3.1 第四层交换简介 214
3.2 硬件实现 215
3.3 软件实现 215
? 网站架构的高性能和可扩展性 233
? 数据收集:高并发 高性能 高扩展性 Web 2.0 网站架构设计和优化策略 243
? CommunityServer性能问题分析 250
鸡肋多站点支持 250
内容数据的集中存储 250
过于依赖缓存 250
CCS的雪上加霜 250
如何解决？ 251
? Digg PHP's Scalability and Performance 251
? YouTube Architecture 253
Information Sources 254
Platform 254
What's Inside? 254
The Stats 254
Recipe for handling rapid growth 255
Web Servers 255
Video Serving 256
Serving Video Key Points 257
Serving Thumbnails 257
Databases 258
Data Center Strategy 259
Lessons Learned 260
1. Jesse ? Comments (78) ? April 10th 261
Library 266
Friendster Architecture 273
Information Sources 274
Platform 274
What's Inside? 274
Lessons Learned 274
? Feedblendr Architecture - Using EC2 to Scale 275
The Platform 276
The Stats 276
The Architecture 276
Lesson Learned 277
Related Articles 278
Comments 279
Re: Feedblendr Architecture - Using EC2 to Scale 279
Re: Feedblendr Architecture - Using EC2 to Scale 279
Re: Feedblendr Architecture - Using EC2 to Scale 280
? PlentyOfFish Architecture 281
Information Sources 282
The Platform 282
The Stats 282
What's Inside 283
Lessons Learned 286
? Wikimedia architecture 288
Information Sources 288
Platform 288
The Stats 289
The Architecture 289
Lessons Learned 291
? Scaling Early Stage Startups 292
Information Sources 293
The Platform 293
The Architecture 293
Lessons Learned 294
? Database parallelism choices greatly impact scalability 295
? Introduction to Distributed System Design 297
Table of Contents 297
Audience and Pre-Requisites 298
The Basics 298
So How Is It Done? 301
Remote Procedure Calls 305
Some Distributed Design Principles 307
Exercises 308
References 309
? Flickr Architecture 309
Information Sources 309
Platform 310
The Stats 310
The Architecture 311
Lessons Learned 316
Comments 318
How to store images 318
RE: How to store images? 318
? Amazon Architecture 319
Information Sources 319
Platform 320
The Stats 320
The Architecture 320
Lessons Learned 324
Comments 329
Jeff.. Bazos? 329
Werner Vogels, the CTO of 329
Re: Amazon Architecture 330
Re: Amazon Architecture 330
Re: Amazon Architecture 330
It's WSDL 330
Re: It's WSDL 331
Re: Amazon Architecture 331
? Scaling Twitter: Making Twitter 10000 Percent Faster 331
Information Sources 332
The Platform 332
The Stats 333
The Architecture 333
Lessons Learned 336
Related Articles 337
Comments 338
Re: Scaling Twitter: Making Twitter 10000 Percent Faster 338
Re: Scaling Twitter: Making Twitter 10000 Percent Faster 338
Re: Scaling Twitter: Making Twitter 10000 Percent Faster 338
Re: Scaling Twitter: Making Twitter 10000 Percent Faster 339
Re: Scaling Twitter: Making Twitter 10000 Percent Faster 339
Re: Scaling Twitter: Making Twitter 10000 Percent Faster 339
They could have been 20% better? 340
Re: Scaling Twitter: Making Twitter 10000 Percent Faster 340
Re: Scaling Twitter: Making Twitter 10000 Percent Faster 341
? Google Architecture 341
Information Sources 342
Platform 342
What's Inside? 342
The Stats 342
The Stack 343
Reliable Storage Mechanism with GFS (Google File System) 343
Do Something With the Data Using MapReduce 344
Storing Structured Data in BigTable 346
Hardware 347
Misc 347
Future Directions for Google 348
Lessons Learned 348
不管怎么样，先要找出瓶颈在哪个部分：是CPU负荷太高（经常100％），还是内存不够用（大量使用虚拟内存），还是磁盘I/O性能跟不上（硬盘指 示灯狂闪）？这几个都是可以通过升级硬件来解决或者改善的（使用更高等级的CPU，更快速和更大容量的内存，配置硬件磁盘阵列并使用更多数量的高速 SCSI硬盘），但这需要较大的投入。
软件方面，如果使用了更大容量的内存和改善的I/O性能，已经能够大幅提高数据库的运行效率，还可以配置查询缓存和进一步优化数据库结构和查询语句，就能让数据库的性能再进一大步。
如果在服务器硬件投入上有困难，那就尽量生成静态页面。
作 者: BBSADM
标 题: 目前的web系统架构
时 间: Fri Apr 6 20:15:56 2007
点 击: 100
------ nginx ---------
| | |
Squid fastcgi proxy
| (逐步迁移) |
静态文件 Njuwebbsd
(逐步迁移到fastcgi上)
最大好处是静态文件加速。
以后准备把帖子内容也静态化，实现最低负荷
而且用 nginx做前台便于负载均衡，测试机可以拿来做静态文件的负载均衡
? 初创网站与开源软件
前面有一篇文章中提到过开 源软件，不过主要是在系统运维的角度去讲的，主要分析一些系统级的开源软件(例如bind,memcached)，这里我们讨论的是用于搭建初创网站应用 的开源软件(例如phpbb,phparticle)，运行在Linux，MySQL，Apache,PHP,Java等下面。
创业期的网站往往采用比较简单的系统架构，或者是直接使用比较成熟的开源软件。使用开源软件的好处是搭建速度快，基本不需要开发，买个空间域名，下个软件一搭建，用个半天就搞定了，一个崭新的网站就开张了，在前期可以极大程度的节约时间成本和开发成本。
当然使用开源软件搭建应用也存在一些局限性，这是我们要重点研究的，而研究的目的就是如何在开源软件选型时以及接下来的维护过程中尽量避免。
一 方面是开源软件一般只有在比较成熟的领域才有，如果是一些创新型的项目很难找到合适的开源软件，这个时候没什么好的解决办法，如果非要用开源的话一般会找 一个最相似的改一下。实际上目前开源的项目也比较多了，在sf.net上可以找到各种各样的开源项目。选型的时候尽量应该选取一个程序架构比较简单的，不 一定越简单越好，但一定要简单，一目了然，别用什么太高级的特性，互联网应用项目不需要太复杂的框架。原因有两个，一个是框架复杂无非是为了实现更好的可 扩展性和更清晰的层次，而我们正在做的互联网应用范围一般会比开源软件设计时所考虑的范围小的多，所以有的应用会显得设计过度，另外追求完美的层次划分导 致的太复杂的继承派生关系也会影响到整个系统维护的工作量。建议应用只需要包含三个层就可以了，数据(实体)层，业务逻辑层，表现层。太复杂的设计容易降 低开发效率，提高维护成本，在出现性能问题或者突发事件的时候也不容易找到原因。
另外一个问题是开源软件的后期维护和继续开发可能会存在问题， 这一点不是绝对的，取决于开源软件的架构是否清晰合理，扩展性好，如果是较小的改动可能一般不会存在什么问题，例如添加一项用户属性或者文章属性，但有些 需求可能就不是很容易实现了。例如网站发展到一定阶段后可能会考虑扩展产品线，原来只提供一个论坛加上cms，现在要再加上商城，那用户系统就会有问题， 如何解决这个问题已经不仅仅是改一下论坛或者cms就可以解决了，这个时候我们需要上升到更高的层次来考虑问题，是否需要建立针对整个网站的用户认证系 统，实现单点登录，用户可以在产品间无缝切换而且保持登录状态。由于网站初始的用户数据可能大部分都存放在论坛里，这个时候我们需要把用户数据独立出来就 会碰到麻烦，如何既能把用户数据独立出来又不影响论坛原有系统的继续运行会是件很头痛的事情。经过一段时间的运行，除非是特别好的设计以及比较好的维护， 一般都会在论坛里存在各种各样乱七八糟的对用户信息的调用，而且是直接针对数据库的，这样如果要将用户数据移走的话要修改代码的工作量将不容忽视，而另外 一个解决办法是复制一份用户数据出来，以新的用户数据库为主，论坛里的用户数据通过同步或异步的机制实现同步。最好的解决办法就是在选型时选一个数据层封 装的比较好的，sql代码不要到处飞的软件，然后在维护的时候保持系统原有的优良风格，把所有涉及到数据库的操作都放到数据层或者实体层里，这样无论对数 据进行什么扩展，代码修改起来都比较方便，基本不会对上层的代码产生影响。
网站访问速度问题对初创网站来说一般考虑的比较少，买个空间或者托管 服务器，搭建好应用后基本上就开始运转了，只有到真正面临极大的速度访问瓶颈后才会真正对这个问题产生重视。实际上在从网站的开始阶段开始，速度问题就会 一直存在，并且会随着网站的发展也不断演进。一个网站最基本的要求，就是有比较快的访问速度，没有速度，再好的内容或服务也出不来。所以，访问速度在网站 初创的时候就需要考虑，无论是采用开源软件还是自己开发都需要注意，数据层尽量能够正确，高效的使用SQL。SQL包含的语法比较复杂，实现同样一个效果 如果考虑到应用层的的不同实现方法，可能有好几种方法，但里面只有一种是最高效的，而通常情况下，高效的SQL一般是那个最简单的SQL。在初期这个问题 可能不是特别明显，当访问量大起来以后，这个可能成为最主要的性能瓶颈，各种杂乱无章的SQL会让人看的疯掉。当然前期没注意的话后期也有解决办法，只不 过可能不会解决的特别彻底，但还是要吧非常有效的提升性能。看MySQL的SlowQuery Log是一个最为简便的方法，把执行时间超过1秒的查询记录下来，然后分析，把该加的索引加上，该简单的SQL简化。另外也可以通过 Showprocesslist查看当前数据库服务器的死锁进程，从而锁定导致问题的SQL语句。另外在数据库配置文件上可以做一些优化，也可以很好的提 升性能，这些文章在网站也比较多，这里就不展开。
这些工作都做了以后，下面数据库如果再出现性能问题就需要考虑多台服务器了，一台服务器已经解决不了问题了，我以前的文章中也提到过，这里也不再展开。
其它解决速度问题的办法就不仅仅是在应用里面就可以实现的了，需要从更高的高度去设计系统，考虑到服务器，网络的架构，以及各种系统级应用软件的配合，这里也不再展开。
良 好设计并实现的应用+中间件+良好的分布式设计的数据库+良好的系统配置+良好的服务器/网络结构，就可以支撑起一个较大规模的网站了，加上前面的几篇文 章，一个小网站发展到大网站的过程基本上就齐了。这个过程会是一个充满艰辛和乐趣的过程，也是一个可以逐渐过渡的过程，主动出击，提前考虑，减少救火可以 让这个过程轻松一些。
? 谈谈大型高负载网站服务器的优化心得!
因为工作的关系，我做过几个大型网站（书库、证券）的相关优化工作，一般是在世界排行1000-4000以内的~~
这些网站使用的程序各不一样，配置也不尽相同，但是它们有一个共同的特点，就是使用的是FREEBSD系统，高配置高负载，PV值非常高，都是需要用两台以上独立主机来支持的网站~
我在优化及跟踪的过程中，开始效果也差强人意，也不太理想，后来通过阅读大量资料才慢慢理清了一些思路，写出来希望给大家有所帮助。
WEB服务器配置是DUAL XEON 2.4G以上，2G内存以上，SCSI硬盘一块以上，FREEBSD 5.X以上~~
数据库服务器与WEB服务器类似~~
书库程序是使用的jieqi的，论坛是使用的Discuz!的
apache 2.x + php 4.x + mysql 4.0.x + zend + 100M光纤独享带宽
1、一定要重新编译内核，根据自己对内核认识的程度和服务器的具体配置来优化，记住打开SMP，也可以使用ULE调度。
2、要优化系统的值，一般是添加入/etc/sysctl.conf里面，要加大内核文件并发数量及其他优化等值。
3、APACHE 2使用perwork工作模式就可以了，我试过worker模式，实在是差强人意呀。修改httpd.conf里面的值，加大并发数量和关闭不需要的模块。因为apache非常消耗内存，尽量轻装上阵~~ 可以适当的使用长连接。关闭日志。
4、PHP编译的时候，注意要尽量以实用为目的加入参数，没有用到的坚决不加，以免浪费系统资源。
5、ZEND要使用较小的优化等级，15就足够了，1023级别只会加重服务器负载~
6、MYSQL要尽量少使用长连接，限制为2-3秒即可~
7、要全部采用手工编译方式，不要用ports安装，因为它会带上很多你不需要的模块，切记。
8、对于这类高负载高在线人数的大站，所有优化的思路就是把尽可能多的系统资源，提供给WEB和MYSQL服务，并且让这些服务单个进程可以占用尽可能少的系统资源。如果系统一开始大量使用SWAP，对于这些服务器来说，服务器状态将会极剧恶化。
9、长时间观察跟踪调试，有什么问题尽快解决~~
就想到这些东东，欢迎大家补充~~
梦飞
http://onlinecq.com/
2006/4/25
P.S. 补充我的几点优化：
1、编译Apache PHP MySQL时使用GCC参数传递对特定CPU进行优化；
2、如果网站小文件很多，可以考虑使用reiserfs磁盘系统，提升读写性能；
3、如不需要 .htaccess ，则将
对于apache服务器繁忙，加大内存可以解决不少问题。
纯交互站点，mysql性能会是一个瓶颈。需要长期跟踪更改参数。
? Lighttpd+Squid+Apache搭建高效率Web服务器
davies 发表于 2006-9-9 01:06 | 分类: Tech :: Web ::
架构原理
Apache通常是开源界的首选Web服务器，因为它的强大和可靠，已经具有了品牌效应，可以适用于绝大部分的应用场 合。但是它的强大有时候却显得笨重，配置文件得让人望而生畏，高并发情况下效率不太高。而轻量级的Web服务器Lighttpd却是后起之秀，其静态文件 的响应能力远高于Apache，据说是Apache的2-3倍。Lighttpd的高性能和易用性，足以打动我们，在它能够胜任的领域，尽量用它。 Lighttpd对PHP的支持也很好，还可以通过Fastcgi方式支持其他的语言，比如Python。
毕竟Lighttpd是轻量级的服务 器，功能上不能跟Apache比，某些应用无法胜任。比如Lighttpd还不支持缓存，而现在的绝大部分站点都是用程序生成动态内容，没有缓存的话即使 程序的效率再高也很难满足大访问量的需求，而且让程序不停的去做同一件事情也实在没有意义。首先，Web程序是需要做缓存处理的，即把反复使用的数据做缓 存。即使这样也还不够，单单是启动Web处理程序的代价就不少，缓存最后生成的静态页面是必不可少的。而做这个是 Squid的强项，它本是做代理的，支持高效的缓存，可以用来给站点做反向代理加速。把Squid放在Apache或者Lighttpd的前端来缓存 Web服务器生成的动态内容，而Web应用程序只需要适当地设置页面实效时间即可。
即使是大部分内容动态生成的网站，仍免不了会有一些静态元 素，比如图片、JS脚本、CSS等等，将Squid放在Apache或者Lighttp前端后，反而会使性能下降，毕竟处理HTTP请求是Web服务器的 强项。而且已经存在于文件系统中的静态内容再在Squid中缓存一下，浪费内存和硬盘空间。因此可以考虑将Lighttpd再放在Squid的前面，构成 Lighttpd+Squid+Apache的一条处理链，Lighttpd在最前面，专门用来处理静态内容的请求，把动态内容请求通过proxy模块转 发给Squid，如果Squid中有该请求的内容且没有过期，则直接返回给Lighttpd。新请求或者过期的页面请求交由Apache中Web程序来处 理。经过Lighttpd和Squid的两级过滤，Apache需要处理的请求将大大减少，减少了Web应用程序的压力。同时这样的构架，便于把不同的处 理分散到多台计算机上进行，由Lighttpd在前面统一把关。
在这种架构下，每一级都是可以进行单独优化的，比如Lighttpd可以采用异步IO方式，Squid可以启用内存来缓存，Apache可以启用MPM 等，并且每一级都可以使用多台机器来均衡负载，伸缩性很好。
实例讲解
下 面以daviesliu.net和rainbud.net域下面的几个站点为例来介绍一下此方案的具体做法。daviesliu.net域下有几个用 mod_python实现的blog站点，几个php的站点，一个mod_python的小程序，以后可能还会架设几个PHP和Django的站点。而服 务器非常弱，CPU为Celeron 500，内存为PC 100 384M，因此比较关注Web服务器的效率。这几个站点都是采用虚拟主机方式，开在同一台机器的同一个端口上。
Lighttpd服务于80端口，Squid运行在3128端口，Apache运行在81端口。
Lighttpd的配置
多个域名采用/var/www/domain/subdomain 的目录结构，用evhost模块配置document-root如下：
evhost.path-pattern = var.basedir + "/%0/%3/"
FtpSearch中有Perl脚本，需要启用CGI支持，它是用来做ftp站内搜索的，缓存的意义不大，直接由lighttpd的mod_cgi处理：
$HTTP["url"] =~ "^/cgi-bin/" { # only allow cgi's in this directory
dir-listing.activate = "disable" # disable directory listings
cgi.assign = ( ".pl" => "/usr/bin/perl", ".cgi" => "/usr/bin/perl" )
}
bbs使用的是phpBB，访问量不大，可以放在lighttpd(fastcgi)或者apache(mod_php)下，暂时使用 lighttpd，设置所有.php的页面请求有fastcgi处理：
fastcgi.server = ( ".php" => ( ( "host" => "127.0.0.1", "port"=> 1026, "bin-path" => "/usr/bin/php-cgi" ) ) )
blog.daviesliu.net 和 blog.rainbud.net 是用mod_python编写的blogxp程序，所有静态内容都有扩展名，而动态内容没有扩展名。blogxp是用python程序生成XML格式的数 据再交由mod_xslt转换成HTML页面，只能放在Apache下运行。该站点采用典型Lighttpd+Squid+Apache方式处理：
$HTTP["host"] =~ "^blog" {
$HTTP["url"] !~ "\." {
proxy.server = ( "" => ( "localhost" => ( "host"=> "127.0.0.1", "port"=> 3128 ) ) ) #3128端口为
}
}
share中有静态页面，也有用mod_python处理的请求，在/cgi/下：
$HTTP["host"] =~ "^share" {
proxy.server = (
"/cgi" => ( "localhost" => ( "host"=> "127.0.0.1", "port"=> 3128 ) )
)
}
Squid的配置
只允许本地访问：
http_port 3128
http_access allow localhost
http_access deny all
启用反向代理：
httpd_accel_host 127.0.0.1
httpd_accel_port 81 #apache的端口
httpd_accel_single_host on
httpd_accel_with_proxy on #启用缓存
httpd_accel_uses_host_header on #启用虚拟主机支持
此方向代理支持该主机上的所有域名。
Apache的配置
配置/etc/conf.d/apache2，让其加载mod_python、mod_xslt、mod_php模块：
APACHE2_OPTS="-D PYTHON -D XSLT -D PHP5"
所有网站的根目录：
AllowOverride All #允许.htaccess覆盖
Order allow,deny
Allow from all
基于域名的虚拟主机：
ServerName blog.daviesliu.net
DocumentRoot /var/www/daviesliu.net/blog
这里明显没有lighttpd的evhost配置方便。
blog.daviesliu.net下的.htaccess设置(便于开发，不用重启Apache):
SetHandler mod_python
PythonHandler blogxp.publisher
PythonDebug On
PythonAutoReload On
SetHandler None #静态文件直接由Apache处理
AddType text/xsl .xsl #防止对xsl文件进行转化
AddOutputFilterByType mod_xslt text/xml
XSLTCache off
XSLTProcess on
Header set Pragma "cache"
Header set Cache-Control "cache"
在blogxp.publisher里面，还需要设置返回的文档类型和过期时间：
req.content_type = "text/xml"
req.headers_out['Expires'] = formatdate( time.time() + 60 * 5 )
经过这样的配置，所有站点都可以通过80、3128、81三个端口进行正常访问，80端口用作对外的访问，以减少负荷。81端口可以用作开发时的调试，没有缓存的困扰。
性能测试
由于时间和精力有限，下面只用ab2做一个并不规范的性能对比测试(每项都测多次取平均)，评价指标为每秒钟的请求数。
测试命令,以测试lighttpd上并发10个请求 scripts/prototype.js 为例：
ab2 -n 1000 -c 10 http://blog.daviesliu.net/scripts/prototype.js
静态内容：prototype.js (27kB)
Con Lighttpd(:80) Squid(:3128) Apache(:81)
1 380 210 240
10 410 215 240
100 380 160 230
可见在静态内容上，Lighttpd表现强劲，而Squid在没有配内存缓存的情况下比另两个Web服务器的性能要差些。
动态页面：/rss (31kB)
Con Lighttpd(:80) Squid(:3128) Apache(:81)
1 103 210 6.17
10 110 200 6.04
100 100 100 6.24
在动态内容上，Squid的作用非常明显，而Lighttpd受限于Squid的效率，并且还要低一大截。如果是有多台Squid来做均衡的话，Lighttpd的功效才能发挥出来。
在单机且静态内容很少的情况下，可以不用Lighttpd而将Squid置于最前面。
14 Comments ?
1. Re:Lighttpd+Squid+Apache搭建高效率Web服务器
这种搭配倒是可以 不过正文描述有些地方有问题
light 可以自己加上cache支持 但从性能只考虑cache看比squid还好一点(平均每秒3000+线上实际数据)
squid 那块说的不太对 处理静态优化到99.99%以上的hitratio后 基本上作用非常大
对整体结构也很有好处
light+squid+apache的结构过渡时期实际在线也跑过 当时是后端没做压缩支持
实际上每一块都可以根据自己需要patch 没有最好 只有更合适 可管理性很重要
由 windtear 发表于 Wed Sep 13 13:38:15 2006
2. Re:Lighttpd+Squid+Apache搭建高效率Web服务器
lighttpd + php 访问量大的话经常会导致 php 死掉，然后 500
不管是 local 还是 remote 方式
无奈，换 zeus 了，很坚挺，商业的就是商业的。
由 soff 发表于 Wed Sep 13 13:39:01 2006
3. Re:Lighttpd+Squid+Apache搭建高效率Web服务器
His result looks weird, as a result, his conclusion is wrong.
Squid does not boost dynamic page at all, the speed gain in his test is because his client is requesting the same page in paralell, and squid will return the same page for the concurrent requests. I also guess that he did not configure expire time for static content in his web server, Squid will try to refetch the file with If-Modified-Since header for each request. That's why squid performs poor in the static test.
由 kxn 发表于 Wed Sep 13 13:41:24 2006
4. Re:Lighttpd+Squid+Apache搭建高效率Web服务器
不太同意这一点，对Squid而言，动态页面和静态页面是一样的，只要设置好HTTP头，
如果设置Expires，是没有缓存效果的
如果不能Cache动态页面的话，那怎么起到加速效果？
由 davies 发表于 Wed Sep 13 13:42:00 2006
5. Re:Lighttpd+Squid+Apache搭建高效率Web服务器
不好意思,英语不好,误导你了,上午在单位的机器没法输入中文
动态页面除非正确设置HTTP的过期时间头,否则就是没有加速效果的.反过来说,静态页面也需要设置过期时间头才对.
我说的设置 expire 时间是指的把过期时间设置到几分钟后或者几小时后,这样页面就在这段时间内完全缓冲在squid里面.
你实际测试动态页面有性能提升,这有几种可能,一是你的测试用的是并发请求同一个页面,squid对并发的同页面请求,如果拿到的结果里面没有 non cache 头,会把这一个结果同时发回给所有请求,相当于有一个非常短时间的cache,测试结果看起来会好很多,但是实际因为请求同一页面的机会不是很多,所以基 本没有啥改进,另一种情况是你用的动态页面程序是支持if-modified-since头的,他如果判断这个时间以后么有修改过,就直接返回not modified,速度也会加快很多.
所以其实squid在实际生产中大部分时间都是用于缓冲静态页面的,动态页面不是不能缓冲,但是需要页面程序里面做很多配合,才能达到比较好的效果
newsmth的 www 高峰时候是 600qps ,squid端还是比较轻松,瓶颈在后端.
由 kxn 发表于 Wed Sep 13 13:43:55 2006
6. Re:Lighttpd+Squid+Apache搭建高效率Web服务器
多谢你的详细解答!
我文章中写了，每个请求都会添加 Expires 头为当前时间的后5分钟，即每个页面的有效期为5分钟，Squid似乎会根据这个时间来判断是否刷新缓存，无需服务器支持If-modified-since
这个5分钟是根据页面的一般更新频率来确定的.
如果是访问量很大的Web应用，比如newsmth的www，如果将php页面的失效时间设置为1-2秒，则这段时间内的请求都会用缓存来回应，即 使在这段缓存时间内数据更新了，但并不影响用户的使用，1-2秒钟的滞后效应对用户的体验影响并不大，但换取的是更快的服务器响应尤其是访问量大但更新并 不频繁的blog部分，这样做可能很有效
当然，如果实现了If-modified-since接口，将更有效，但工作量太大
由 davies 发表于 Wed Sep 13 13:45:27 2006
7. Re:Lighttpd+Squid+Apache搭建高效率Web服务器
看来是我没有仔细看你文章了, 确实没有注意到你文章里面提了 expire 头
静态页面也可以设置 expire 头的,用 web server 的一个模块就可以
这样基本就是全部用 squid 缓冲了.
没有 expire 头的时候,squid就会每个请求都用 if modified since 去刷.
smthwww的php 页面expire时间是 5 分钟还是 10 分钟来着,我忘记了.
由 kxn 发表于 Wed Sep 13 13:46:46 2006
8. Re:Lighttpd+Squid+Apache搭建高效率Web服务器
总的感觉多此一举阿，如果没有非常巨大的访问量,squid的解决方案就足够了。
如果真用了lighttpd, 基本上没有什么必要要apache了,
除非是非常特别的应用, lighttpd基本上都能支持的.
单机折腾这么多层，是不会有什么性能收益的.
由 scaner 发表于 Wed Sep 13 13:48:44 2006
9. Re:Lighttpd+Squid+Apache搭建高效率Web服务器
其实lighttpd的缓存功能很强大，你可以看看他的cml文档，能很好的解决动态内容的缓存问题。而且如果是单机服务器的话在架个squid意义不大。当然除非你要缓存的东西实在太多，squid的Bloom Filter还是非常有效的。
由 Wei Litao [email] 发表于 Sat Sep 16 13:19:38 2006
10. Re: Lighttpd+Squid+Apache搭建高效率Web服务器
lighttpd有bug，内存泄漏比较严重。我现在用nginx，正在lilybbs上测试效果。其实把动态内容静态化才是最终出路。那些点击量真想去掉。
目前lilybbs的架构：
------ nginx ---------
| | |
Squid fastcgi proxy
| (逐步迁移) |
静态文件 Njuwebbsd
(逐步迁移到fastcgi上)
由 bianbian [email] [www] 发表于 Fri Apr 6 20:49:08 2007
11. Re: Lighttpd+Squid+Apache搭建高效率Web服务器
ft.不支持空格排版。架构请看：
http://bbs.nju.cn/blogcon?userid=BBSADM&file=1175861756
由 bianbian [www] 发表于 Fri Apr 6 20:51:11 2007
12. Re: Lighttpd+Squid+Apache搭建高效率Web服务器
另外。我觉得单机搞三层没什么必要，你这个情况可以完全抛弃apache。我现在的遗憾是nginx其他都很强，就是memcache没完善，所以必须弄个Squid
由 bianbian [www] 发表于 Fri Apr 6 20:57:11 2007
13. Re: Lighttpd+Squid+Apache搭建高效率Web服务器
我文中的那个方案只是在特殊场合才有用，呵呵
主来还是用来玩玩
点击其实可以通过分析log来离线做，或者单独放一些数据，用ajax来跟新这一部分，呵呵
由 davies 发表于 Sat Apr 7 01:31:18 2007
14. Re: Lighttpd+Squid+Apache搭建高效率Web服务器
头一次听说NginX，感觉应该是跟lighttpd同一个层次的东西，相差不会太大。如果要拼并发性能的话，估计平不过yaws，改天做个简单测试。
由 davies 发表于 Sat Apr 7 01:39:14
? 浏览量比较大的网站应该从哪几个方面入手？
________________________________________
作者: 游戏人间 时间: 2007-6-15 04:23 PM 标题: 浏览量比较大的网站应该从哪几个方面入手？
当然，提问前先将个人的一些理解分享。大家有的也请不吝共享，偶急切的需要这方面的经验....
下面所提到的主要是针对一般的网站，不包括下载或聊天室等特殊站点...
一、减少数据库的压力
缓存查询结果／建内存表
二、 减少Apache的压力——减少HTTP的请求次数
背景图片全部做成一张然后用CSS控制位置/不使用AJAX来进行即时验证(不考虑客户体验什么的,通过拖长客户时间来减轻服务器压力)
三、减轻I/O压力
页面局部缓存
作者: 蟋蟀 时间: 2007-6-15 05:29 PM
咱也说点，只是理论，不知道对不对．
流量大的网站咱没做过．
一横向
１＼首先要考虑的就是硬件，适当的投入硬件，要比你搞那么多软件优化要实惠的多．
２＼在就是从cpu 内存 硬盘 了．频繁操作的数据能存到内存中就存到内存中，能存到分布共享中就存储在分布共享内存中
其次考虑在考虑硬盘上．
二纵向
１＼从web的http的响应 应答考虑
web要有服务器，所以如何优化服务器，如何通过配置服务器加速操作，能缓存的缓存，这方面的东西不少。
２、要是动态脚本，考虑使用的数据库 如何优化数据库、如何建立合理的表等操作 这方面细节同样不少
３、用php脚本，尽量少的require 文件，毕竟每次php是一次性编译，而且每次到require都要返回 这个脚本方面的就要看程序员的水平了
还有很多
作者: fcicq 时间: 2007-6-19 09:30 PM
好久没出来了，难得碰上一篇可以回的帖子
一、减少数据库的压力
缓存查询结果／建内存表
有条件就把数据库尽量分开，减小数据库规模
杜绝超过0.5s的 queries - 非常重要！
开大内存索引
二、 减少Apache的压力——减少HTTP的请求次数
背景图片全部做成一张然后用CSS控制位置/不使用AJAX来进行即时验证(不考虑客户体验什么的,通过拖长客户时间来减轻服务器压力)
背景图片？这个没必要.
静态内容不要用apache!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
三、减轻I/O压力
页面局部缓存
作者: ￥ 时间: 2007-6-20 11:59 AM
可以lighttp+apache配合的...lighttp负责静态的如image,js,css等,apache负责php,用rewrite转发到lighttp
甚至有研究表明,lighttp处理fastcgi模式下的php,要比apache等要快
性能上,lighttp是要优于apache的,但稳定性就差点..
________________________________________
作者: sigmazel 时间: 2007-6-20 12:49 PM
WEB方面：
1.脚本引用的资源文件如css,js,image可以多放几台服务器上，尽可能的压缩。
2.适当的加入ajax
3.尽量控制php的代码行，如果方便的话，可以写成com或so级的
4.缓存
________________________________________
作者: php5 时间: 2007-6-20 06:55 PM
考虑硬件成本的话可以笼统地从以下着手
一、页面尽量静态化
二、配置服务器动态的走apache,静态的走Lighttpd
三、用最好的OS如FreeBSD
四、重点优化mysql性能从编译、配置上入手
五、最基本的控制好程序性能及SQL查询
六、做缓存、做代理反向代理
七、页面上的优化了，节省流量上的考虑
作者: 奶瓶 时间: 2007-6-21 10:52 AM
静态文件用apache的代价很大,其实lighttpd和NGINX这类的也并不会小太多,有一些支持“文件至网卡”模式的特殊静态服务器可能划 算一些。php的调用文件个数可以做到比较精确的控制,tmpfs一类的方法可以尝试,不要过分迷信memcached,本地cache适当用用回保不错
作者: fengchen9127 时间: 2007-6-21 11:13 AM
优化数据库访问。
前台实现完全的静态化当然最好，可以完全不用访问数据库，不过对于频繁更新的网站，静态化往往不能满足某些功能。
缓存技术就是另一个解决方案，就是将动态数据存储到缓存文件中，动态网页直接调用这些文件，而不必再访问数据库，WordPress和Z-Blog都大量使用这种缓存技术。我自己也写过一个Z-Blog的计数器插件，也是基于这样的原理。
如果确实无法避免对数据库的访问，那么可以尝试优化数据库的查询SQL.避免使用Select * from这样的语句，每次查询只返回自己需要的结果，避免短时间内的大量SQL查询。
禁止外部的盗链。
外部网站的图片或者文件盗链往往会带来大量的负载压力，因此应该严格限制外部对于自身的图片或者文件盗链，好在目前可以简单地通过refer来控制盗 链，Apache自己就可以通过配置来禁止盗链，IIS也有一些第三方的ISAPI可以实现同样的功能。当然，伪造refer也可以通过代码来实现盗链， 不过目前蓄意伪造refer盗链的还不多，可以先不去考虑，或者使用非技术手段来解决，比如在图片上增加水印。
控制大文件的下载。
大文件的下载会占用很大的流量，并且对于非SCSI硬盘来说，大量文件下载会消耗CPU，使得网站响应能力下降。因此，尽量不要提供超过2M的大文件下载，如果需要提供，建议将大文件放在另外一台服务器上。
使用不同主机分流主要流量
将文件放在不同的主机上，提供不同的镜像供用户下载。比如如果觉得RSS文件占用流量大，那么使用FeedBurner或者FeedSky等服务将RSS输出放在其他主机上，这样别人访问的流量压力就大多集中在FeedBurner的主机上，RSS就不占用太多资源了。
使用流量分析统计软件。
在网站上安装一个流量分析统计软件，可以即时知道哪些地方耗费了大量流量，哪些页面需要再进行优化，因此，解决流量问题还需要进行精确的统计分析才可以。
? 用负载均衡技术建设高负载站点
转载自:IT.COM.CN | 2005年11月04日 | 作者: | 浏览次数:57
Internet的快速增长使多媒体网络服务器，特别是Web服务器，面对的访问者数量快速增加，网络服务器需要具备提供大量并发访问服务的能力。例如 Yahoo每天会收到数百万次的访问请求，因此对于提供大负载Web服务的服务器来讲，CPU、I/O处理能力很快会成为瓶颈。
简单的提高硬件性能并不能真正解决这个问题，因为单台服务器的性能总是有限的，一般来讲，一台PC服务器所能提供的并发访问处理能力大约为 1000个，更为高档的专用服务器能够支持3000-5000个并发访问，这样的能力还是无法满足负载较大的网站的要求。尤其是网络请求具有突发性，当某 些重大事件发生时，网络访问就会急剧上升，从而造成网络瓶颈，例如在网上发布的克林顿弹劾书就是很明显的例子。必须采用多台服务器提供网络服务，并将网络 请求分配给这些服务器分担，才能提供处理大量并发服务的能力。
当使用多台服务器来分担负载的时候，最简单的办法是将不同的服务器用在不同的方面。按提供的内容进行分割时，可以将一台服务器用于提供新闻页 面，而另一台用于提供游戏页面；或者可以按服务器的功能进行分割，将一台服务器用于提供静态页面访问，而另一些用于提供CGI等需要大量消耗资源的动态页 面访问。然而由于网络访问的突发性，使得很难确定那些页面造成的负载太大，如果将服务的页面分割的过细就会造成很大浪费。事实上造成负载过大的页面常常是 在变化中的，如果要经常按照负载变化来调整页面所在的服务器，那么势必对管理和维护造成极大的问题。因此这种分割方法只能是大方向的调整，对于大负载的网 站，根本的解决办法还需要应用负载均衡技术。
负载均衡的思路下多台服务器为对称方式，每台服务器都具备等价的地位，都可以单独对外提供服务而无须其他服务器的辅助。然后通过某种负载分担技 术，将外部发送来的请求均匀分配到对称结构中的某一台服务器上，而接收到请求的服务器都独立回应客户机的请求。由于建立内容完全一致的Web服务器并不复 杂，可以使用服务器同步更新或者共享存储空间等方法来完成，因此负载均衡技术就成为建立一个高负载Web站点的关键性技术。
基于特定服务器软件的负载均衡
很多网络协议都支持“重定向”功能，例如在HTTP协议中支持Location指令，接收到这个指令的浏览器将自动重定向到Location指 明的另一个URL上。由于发送Location指令比起执行服务请求，对Web服务器的负载要小的多，因此可以根据这个功能来设计一种负载均衡的服务器。 任何时候Web服务器认为自己负载较大的时候，它就不再直接发送回浏览器请求的网页，而是送回一个Locaction指令，让浏览器去服务器集群中的其他 服务器上获得所需要的网页。
在这种方式下，服务器本身必须支持这种功能，然而具体实现起来却有很多困难，例如一台服务器如何能保证它重定向过的服务器是比较空闲的，并且不 会再次发送Location指令？Location指令和浏览器都没有这方面的支持能力，这样很容易在浏览器上形成一种死循环。因此这种方式实际应用当中 并不多见，使用这种方式实现的服务器集群软件也较少。有些特定情况下可以使用CGI（包括使用FastCGI或mod_perl扩展来改善性能）来模拟这 种方式去分担负载，而Web服务器仍然保持简洁、高效的特性，此时避免Location循环的任务将由用户的CGI程序来承担。
基于DNS的负载均衡
由于基于服务器软件的负载均衡需要改动软件，因此常常是得不偿失，负载均衡最好是在服务器软件之外来完成，这样才能利用现有服务器软件的种种优 势。最早的负载均衡技术是通过DNS服务中的随机名字解析来实现的，在DNS服务器中，可以为多个不同的地址配置同一个名字，而最终查询这个名字的客户机 将在解析这个名字时得到其中的一个地址。因此，对于同一个名字，不同的客户机会得到不同的地址，他们也就访问不同地址上的Web服务器，从而达到负载均衡 的目的。
例如如果希望使用三个Web服务器来回应对http://www.exampleorg.org.cn/的HTTP请求，就可以设置该域的DNS服务器中关于该域的数据包括有与下面例子类似的结果：
www1 IN A 192.168.1.1
www2 IN A 192.168.1.2
www3 IN A 192.168.1.3
www IN CNAME www1
www IN CNAME www2
www IN CNAME www3
此后外部的客户机就可能随机的得到对应www的不同地址，那么随后的HTTP请求也就发送给不同地址了。
DNS负载均衡的优点是简单、易行，并且服务器可以位于互联网的任意位置上，当前使用在包括Yahoo在内的Web站点上。然而它也存在不少缺 点，一个缺点是为了保证DNS数据及时更新，一般都要将DNS的刷新时间设置的较小，但太小就会造成太大的额外网络流量，并且更改了DNS数据之后也不能 立即生效；第二点是DNS负载均衡无法得知服务器之间的差异，它不能做到为性能较好的服务器多分配请求，也不能了解到服务器的当前状态，甚至会出现客户请 求集中在某一台服务器上的偶然情况。
反向代理负载均衡
使用代理服务器可以将请求转发给内部的Web服务器，使用这种加速模式显然可以提升静态网页的访问速度。因此也可以考虑使用这种技术，让代理服 务器将请求均匀转发给多台内部Web服务器之一上，从而达到负载均衡的目的。这种代理方式与普通的代理方式有所不同，标准代理方式是客户使用代理访问多个 外部Web服务器，而这种代理方式是多个客户使用它访问内部Web服务器，因此也被称为反向代理模式。
实现这个反向代理能力并不能算是一个特别复杂的任务，但是在负载均衡中要求特别高的效率，这样实现起来就不是十分简单的了。每针对一次代理，代 理服务器就必须打开两个连接，一个为对外的连接，一个为对内的连接，因此对于连接请求数量非常大的时候，代理服务器的负载也就非常之大了，在最后反向代理 服务器会成为服务的瓶颈。例如，使用Apache的mod_rproxy模块来实现负载均衡功能时，提供的并发连接数量受Apache本身的并发连接数量 的限制。一般来讲，可以使用它来对连接数量不是特别大，但每次连接都需要消耗大量处理资源的站点进行负载均衡，例如搜寻。
使用反向代理的好处是，可以将负载均衡和代理服务器的高速缓存技术结合在一起，提供有益的性能，具备额外的安全性，外部客户不能直接访问真实的 服务器。并且实现起来可以实现较好的负载均衡策略，将负载可以非常均衡的分给内部服务器，不会出现负载集中到某个服务器的偶然现象。
基于NAT的负载均衡技术
网络地址转换为在内部地址和外部地址之间进行转换，以便具备内部地址的计算机能访问外部网络，而当外部网络中的计算机访问地址转换网关拥有的某 一外部地址时，地址转换网关能将其转发到一个映射的内部地址上。因此如果地址转换网关能将每个连接均匀转换为不同的内部服务器地址，此后外部网络中的计算 机就各自与自己转换得到的地址上服务器进行通信，从而达到负载分担的目的。
地址转换可以通过软件方式来实现，也可以通过硬件方式来实现。使用硬件方式进行操作一般称为交换，而当交换必须保存TCP连接信息的时候，这种 针对OSI网络层的操作就被称为第四层交换。支持负载均衡的网络地址转换为第四层交换机的一种重要功能，由于它基于定制的硬件芯片，因此其性能非常优秀， 很多交换机声称具备400MB-800MB的第四层交换能力，然而也有一些资料表明，在如此快的速度下，大部分交换机就不再具备第四层交换能力了，而仅仅 支持第三层甚至第二层交换。
然而对于大部分站点来讲，当前负载均衡主要是解决Web服务器处理能力瓶颈的，而非网络传输能力，很多站点的互联网连接带宽总共也不过10MB，只有极少的站点能够拥有较高速的网络连接，因此一般没有必要使用这些负载均衡器这样的昂贵设备。
使用软件方式来实现基于网络地址转换的负载均衡则要实际的多，除了一些厂商提供的解决方法之外，更有效的方法是使用免费的自由软件来完成这项任 务。其中包括Linux Virtual Server Project中的NAT实现方式，或者本文作者在FreeBSD下对natd的修订版本。一般来讲，使用这种软件方式来实现地址转换，中心负载均衡器存 在带宽限制，在100MB的快速以太网条件下，能得到最快达80MB的带宽，然而在实际应用中，可能只有40MB-60MB的可用带宽。
扩展的负载均衡技术
上面使用网络地址转换来实现负载分担，毫无疑问所有的网络连接都必须通过中心负载均衡器，那么如果负载特别大，以至于后台的服务器数量不再在是 几台、十几台，而是上百台甚至更多，即便是使用性能优秀的硬件交换机也回遇到瓶颈。此时问题将转变为，如何将那么多台服务器分布到各个互联网的多个位置， 分散网络负担。当然这可以通过综合使用DNS和NAT两种方法来实现，然而更好的方式是使用一种半中心的负载均衡方式。
在这种半中心的负载均衡方式下，即当客户请求发送给负载均衡器的时候，中心负载均衡器将请求打包并发送给某个服务器，而服务器的回应请求不再返回给中心负载均衡器，而是直接返回给客户，因此中心负载均衡器只负责接受并转发请求，其网络负担就较小了。
上图来自Linux Virtual Server Project，为他们使用IP隧道实现的这种负载分担能力的请求/回应过程，此时每个后台服务器都需要进行特别的地址转换，以欺骗浏览器客户，认为它的回应为正确的回应。
同样，这种方式的硬件实现方式也非常昂贵，但是会根据厂商的不同，具备不同的特殊功能，例如对SSL的支持等。
由于这种方式比较复杂，因此实现起来比较困难，它的起点也很高，当前情况下网站并不需要这么大的处理能力。
比较上面的负载均衡方式，DNS最容易，也最常用，能够满足一般的需求。但如果需要进一步的管理和控制，可以选用反向代理方式或NAT方式，这 两种之间进行选择主要依赖缓冲是不是很重要，最大的并发访问数量是多少等条件。而如果网站上对负载影响很厉害的CGI程序是由网站自己开发的，也可以考虑 在程序中自己使用Locaction来支持负载均衡。半中心化的负载分担方式至少在国内当前的情况下还不需要。
? 大型网站的架构设计问题
在CSDN上看到一篇文章（http://blog.csdn.net/fww80/archive/2006/04/28/695293.aspx）讨论大型高并发负载网站的系统架构问题，作者提出了几点建议：
1. HTML静态化，这可以通过CMS自动实现；
2. 图片服务器分离（类似的，在视频网站中，视频文件也应独立出来）；
3. 数据库集群和库表散列，Oracle、MySQL等DBMS都有完美的支持；
4. 缓存，比如使用Apache的Squid模块，或者是开发语言的缓存模块，；
5. 网站镜像；
6. 负载均衡。
作 者将负载均衡称为“是大型网站解决高负荷访问和大量并发请求采用的终极解决办法”，并提出“一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的 基础上搭建squid集群”。在实践时可以考虑建立应用服务器集群和Web服务器集群，应用服务器集群可以采用Apache+Tomcat集群和 WebLogic集群等，Web服务器集群可以用反向代理，也可以用NAT的方式，或者多域名解析均可。
从提升网站性能的角度出发，静态资源不应和应用服务器放在一起，数据库服务器也应尽量独立开来。在典型的MVC模式中，由谁来完成数据逻辑处理的， 对系统性能有着至关重要的影响。以Java EE为例，在OO的设计思想中，我们强调系统的抽象、重用、可维护性，强调下层的更改不会扩散到上层逻辑，强调系统移植的便捷性，因而往往存在一种过分抽 象的问题，比如在Hibernate的基础上再加入一层DAO的设计。另外一方面，却会忽视利用DBMS本身的优秀特性（存储过程、触发器）来完成高效的 数据处理。诚然，如果客户要求将数据从Oracle移植到MySQL，那么DBMS特性的东西越少，移植便越容易。但事实上，在实践中，提出类似移植要求 的情况非常少见，因此在做架构设计时，不一定为了这种潜在的需求而大幅牺牲系统的性能与稳定性。此外，我不建议采用分布式数据库管理结构，这样带来的开销 太大，数据维护也是个头痛的问题，尽可能采用集中式的数据管理。
在商业系统中，算法逻辑本身并不复杂，在这种情况下，程序设计本身的好坏不会对系统的性能造成致命的影响。重要的影响因素反而变为软件系统架构本 身。在传统的CORBA、J2EE、DCOM等对象模型中，我们看到专家们对分布式对象计算的理论偏好，但实践证明，对象的分布带来的恶劣影响远远胜过其 积极意义。这也是现在轻量级的开发框架受推崇的一个重要原因。如果能用简单的，就不要用复杂的，例如能够用Python、RoR完成的任务，是否一定要用 Java来做？我看未必。对于用户来说，他们关心的不是采用什么先进的技术，而是我们提供的产品能否满足他的需求。而且，Python、RoR这些开发工 具已经强大到足以应对大部分网站应用，在各种缓存系统的帮助下，在其他技术的协调配合下，完全能够胜任高负载高并发的网站访问任务。
在HTML静态化方面，如果是对于更新相对较少的页面，可以这样处理，例如新闻、社区通告、或者类似与淘宝网的产品分类信息。但若数据更新频繁，这样做的意义便不大。
网站镜像是个传统的技术，更高级的应用来自流媒体领域的CDN(Content Delivery Network)，CDN的概念可以由流媒体数据扩展到图片、视频文件等静态资源的传输。不过，在电子商务领域，很少有这样的应用。
? 开源平台的高并发集群思考
目前碰到的高并发应用，需要高性能需求的主要是两个方面
1。网络
2。数据库
这两个方面的解决方式其实还是一致的
1。充分接近单机的性能瓶颈，自我优化
2。单机搞不定的时候(
数据传输瓶颈:
单位时间内磁盘读写/网络数据包的收发
cpu计算瓶颈)，把负荷分担给多台机器，就是所谓的负载均衡
网络方面单机的处理
1。底层包收发处理的模式变化(从select 模式到epoll / kevent)
2。应用模式的变化
2.1 应用层包的构造方式
2.2 应用协议的实现
2.3 包的缓冲模式
2.4 单线程到多线程
网络负载均衡的几个办法
1。代理模式：代理服务器只管收发包，收到包以后转给后面的应用服务器群（服务器群后可能还会有一堆堆的数据库服务器等等），并且把返回的结果再返回给请求端
2。虚拟代理ip：代理服务器收发包还负载太高，那就增加多台代理服务器，都来管包的转发。这些代理服务器可以用统一的虚拟ip，也可以单独的ip
3。p2p：一些广播的数据可以p2p的模式来减轻服务器的网络压力
数据库(指mysql)单机的处理
1。数据库本身结构的设计优化（分表，分记录，目的在于保证每个表的记录数在可定的范围内）
2。sql语句的优化
3。master + slave模式
数据库集群的处理
1。master + slave模式 （可有效地处理并发查询）
2。mysql cluster 模式 （可有效地处理并发数据变化）
相关资料：
http://dev.mysql.com/doc/refman/5.0/en/ndbcluster.html
? 大型、高负载网站架构和应用初探
时间：30-45分钟
开题：163,sina,sohu等网站他们有很多应用程序都是PHP写的，为什么他们究竟是如何能做出同时跑几千人甚至上万同时在线应用程序呢?
? 挑选性能更好web服务器
o 单台 Apache web server 性能的极限
o 选用性能更好的web server TUX,lighttpd,thttpd …
o 动，静文件分开，混合使用
? 应用程序优化,Cache的使用和共享
o 常见的缓存技术
? 生成静态文件
? 对象持久化 serialize & unserialize
o Need for Speed ，在最快的地方做 cache
? Linux 系统下的 /dev/shm
? tmpfs/ramdisk
? php内置的 shared memory function /IPC
? memcached
? MySQL的HEAP表
o 多台主机共享cache
? NFS,memcached,MySQL 优点和缺点比较
? MySQL数据库优化
o 配置 my.cnf，设置更大的 cache size
o 利用 phpMyAdmin 找出配置瓶颈，榨干机器的每一点油
o 集群(热同步,mysql cluster)
? 集群，提高网站可用性
o 最简单的集群，设置多条A记录，DNS轮询，可用性问题
o 确保高可用性和伸缩性能的成熟集群解决方案
? 通过硬件实现，如路由器,F5 network
? 通过软件或者操作系统实现
? 基于内核,通过修改TCP/IP数据报文负载均衡，并确保伸缩性的 LVS以及 确保可用性守护进程ldirectord
? 基于 layer 7，通过URL分发的 HAproxy
o 数据共享问题
? NFS,Samba,NAS,SAN
o 案例
? 解决南北互通，电信和网通速度问题
o 双线服务器
o CDN
? 根据用户IP转换到就近服务器的智能DNS,dnspod …
? Squid 反向代理,(优点,缺点)
o 案例
http://blog.yening.cn/2007/03/25/226.html#more-226
? 说说大型高并发高负载网站的系统架构
By Michael
转载请保留出处：俊麟 Michael’s blog (http://www.toplee.com/blog/?p=71)
Trackback Url : http://www.toplee.com/blog/wp-trackback.php?p=71
我在CERNET做过拨号接入平台的搭建，而后在Yahoo&3721从事过搜索引擎前端开发，又在MOP处理过大型社区猫扑大杂烩的架构升级 等工作，同时自己接触和开发过不少大中型网站的模块，因此在大型网站应对高负载和并发的解决方案上有一些积累和经验，可以和大家一起探讨一下。
一个小型的网站，比如个人网站，可以使用最简单的html静态页面就实现了，配合一些图片达到美化效果，所有的页面均存放在一个目录下，这样的 网站对系统架构、性能的要求都很简单，随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所 采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态 网站所能比拟的。
大型网站，比如门户网站。在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面，还没法根本解决大型网站面临的高负载和高并发问题。
上面提供的几个解决思路在一定程度上也意味着更大的投入，并且这样的解决思路具备瓶颈，没有很好的扩展性，下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。
1、HTML静态化
其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是 最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点 的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限 管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。
除了门户和信息发布类型的网站，对于交互性要求 很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略， 像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。目前很多博客也都实现了静态化，我使用的这个Blog程序WordPress还没有静态化， 所以如果面对高负载访问，http://www.toplee.com/一定不能承受
同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛 中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这 部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。
在进行html静态化的时候可以使用一种折中的方法，就是前端使用动态实现，在一定的策略下进行定时静态化和定时判断
