由于自己正在做一个高性能大用户量的论坛程序，对高性能高并发服务器架构比较感兴趣，于是在网上收集了不少这方面的资料和大家分享。希望能和大家交流
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
2、两台服务器 72
3、四台服务器 73
4、五台服务器 73
5、更多服务器 74
6、现在我们在哪里： 75
7、现在我们在哪里 78
8、现在我们在哪里 79
9、缓存 80
10、Web访问负载均衡 80
11、MogileFS 81
? Craigslist 的数据库架构 81
? Second Life 的数据拾零 82
? eBay架构的思想金矿 84
? 一天十亿次的访问－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 ，则将 <Files .htaccess> 设置为 None
对于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"
所有网站的根目录：
<Directory "/var/www">
AllowOverride All #允许.htaccess覆盖
Order allow,deny
Allow from all
</Directory>
基于域名的虚拟主机：
<VirtualHost *:81>
ServerName blog.daviesliu.net
DocumentRoot /var/www/daviesliu.net/blog
</VirtualHost>
这里明显没有lighttpd的evhost配置方便。
blog.daviesliu.net下的.htaccess设置(便于开发，不用重启Apache):
SetHandler mod_python
PythonHandler blogxp.publisher
PythonDebug On
PythonAutoReload On

<FilesMatch "\.">
SetHandler None #静态文件直接由Apache处理
</FilesMatch>

<IfModule mod_xslt.c>
AddType text/xsl .xsl #防止对xsl文件进行转化
AddOutputFilterByType mod_xslt text/xml
XSLTCache off
XSLTProcess on
</IfModule>
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&amp;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静态化的时候可以使用一种折中的方法，就是前端使用动态实现，在一定的策略下进行定时静态化和定时判断调用，这个能实现很多灵活性的操作，我开发的台球网站故人居(http://www.8zone.cn/)就是使用了这样的方法，我通过设定一些html静态化的时间间隔来对动态网站内容进行缓存，达到分担大部分的压力到静态页面上，可以应用于中小型网站的架构上。故人居网站的地址：http://www.8zone.cn/，顺便提一下，有喜欢台球的朋友多多支持我这个免费网站:)
2、图片服务器分离
　 　大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型 网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为 图片问题而崩溃。
　　在应用服务器和图片服务器上，可以进行不同的配置优化，比如Apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadModule，保证更高的系统消耗和执行效率。
　　我的台球网站故人居8zone.cn也使用了图片服务器架构上的分离，目前是仅仅是架构上分离，物理上没有分离，由于没有钱买更多的服务器:)，大家可以看到故人居上的图片连接都是类似img.9tmd.com或者img1.9tmd.com的URL。
　　另外，在处理静态页面或者图片、js等访问方面，可以考虑使用lighttpd代替Apache，它提供了更轻量级和更高效的处理能力。
3、数据库集群和库表散列
　　大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。
　　在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。
　 　上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并 且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者 功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的 架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系 统随时增加一台低成本的数据库进来补充系统性能。
4、缓存
　　缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。
　　架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的mod_proxy缓存模块，也可以使用外加的Squid进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。
　 　网站程序开发方面的缓存，Linux上提供的Memcached是常用的缓存方案，不少web编程语言都提供memcache访问接口，php、 perl、c和java都有，可以在web开发中使用，可以实时或者Cron的把数据、对象等内容进行缓存，策略非常灵活。一些大型社区使用了这样的架 构。
　　另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块和 eAccelerator加速和Cache模块，还要知名的Apc、XCache（国人开发的，支持！）php缓存模块，Java就更多了，.net不是 很熟悉，相信也肯定有。
5、镜像
　　镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带 来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的 细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。
6、负载均衡
　　负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。
　　负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。另外有关初级的负载均衡DNS轮循和较专业的CDN架构就不多说了。
6.1 硬件四层交换
　 　第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。　第四层交换功能就象 是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复 杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同 决定。
　　在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。
6.2 软件四层交换
　　大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。
　 　软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满 足多种应用需求，这对于分布式的系统来说必不可少。
　　一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集 群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。这样的架构我准备空了 专门详细整理一下和大家探讨。
总结：
　　对于大型网站来说，前面提到的每个方法可能都会被同时使用到，Michael这里介绍得比较 浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会，有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大，希望大家 一起讨论，达到抛砖引玉之效。
　　转载请保留出处：俊麟 Michael’s blog (http://www.toplee.com/blog/?p=71)
Trackback Url : http://www.toplee.com/blog/wp-trackback.php?p=71
This entry is filed under 其他技术, 技术交流. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
(2 votes, average: 6.5 out of 10)
Loading ...
58 Responses to “说说大型高并发高负载网站的系统架构”
1
pi1ot says:
April 29th, 2006 at 1:00 pm
Quote
各模块间或者进程间的通信普遍异步化队列化也相当重要，可以兼顾轻载重载时的响应性能和系统压力,数据库压力可以通过file cache分解到文件系统，文件系统io压力再通过mem cache分解，效果很不错.
2
Exception says:
April 30th, 2006 at 4:40 pm
Quote
写得好！现在，网上像这样的文章不多，看完受益匪浅
3
guest says:
May 1st, 2006 at 8:13 am
Quote
完全胡说八道!
“大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的”,你以为是在内存中动态生成图片啊.无论是什么文件,在容器输出时只是读文件,输出给response而已,和是什么文件有什么关系.
关键是静态文件和动态页面之间应该采用不同策略,如静态文件应该尽量缓存,因为无论你请求多少次输出内容都是相同的,如果用户页面中有二十个就没有必要请求二十次,而应该使用缓存.而动态页面每次请求输出都不相同(否则就应该是静态的),所以不应该缓存.
所以即使在同一服务器上也可以对静态和动态资源做不同优化,专门的图片服务器那是为了资源管理的方便,和你说的性能没有关系.
4
Michael says:
May 2nd, 2006 at 1:15 am
Quote
动 态的缓存案例估计楼上朋友没有遇到过，在处理inktomi的搜索结果的案例中，我们使用的全部是面对动态的缓存，对于同样的关键词和查询条件来说，这样 的缓存是非常重要的，对于动态的内容缓存，编程时使用合理的header参数可以方便的管理缓存的策略，比如失效时间等。
我们说到有关图片影响 性能的问题，一般来说都是出自于我们的大部分访问页面中图片往往比html代码占用的流量大，在同等网络带宽的情况下，图片传输需要的时间更长，由于传输 需要花很大开销在建立连接上，这会延长用户client端与server端的http连接时长，这对于apache来说，并发性能肯定会下降，除非你的返 回全部是静态的，那就可以把 httpd.conf 中的 KeepAlives 为 off ，这样可以减小连接处理时间，但是如果图片过多会导致建立的连接次数增多，同样消耗性能。
另外我们提到的理论更多的是针对大型集群的案例，在这样的环境下，图片的分离能有效的改进架构，进而影响到性能的提升，要知道我们为什么要谈架构？架构可能为了安全、为了资源分配、也为了更科学的开发和管理，但是终极目都是为了性能。
另外在RFC1945的HTTP协议文档中很容易找到有关Mime Type和Content length部分的说明，这样对于理解图片对性能影响是很容易的。
楼上的朋友完全是小人作为，希望别用guest跟我忽悠，男人还害怕别人知道你叫啥？再说了，就算说错了也不至于用胡说八道来找茬！大家重在交流和学习，我也不是什么高人，顶多算个普通程序员而已。
5
Ken Kwei says:
June 3rd, 2006 at 3:42 pm
Quote
Michael 您好，这篇文章我看几次了，有一个问题，您的文章中提到了如下一段：
“对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。”
对 于大型的站点来说，他的数据库和 Web Server 一般都是分布式的，在多个区域都有部署，当某个地区的用户访问时会对应到一个节点上，如果是对社区内的帖子实时静态化，有更新时再重新静态化，那么在节点 之间如何立刻同步呢？数据库端如何实现呢？如果用户看不到的话会以为发帖失败？造成重复发了，那么如何将用户锁定在一个节点上呢，这些怎么解决？谢谢。
6
Michael says:
June 3rd, 2006 at 3:57 pm
Quote
对于将一个用户锁定在某个节点上是通过四层交换来实现的，一般情况下是这样，如果应用比较小的可以通过程序代码来实现。大型的应用一般通过类似LVS和硬件四层交换来管理用户连接，可以制定策略来使用户的连接在生命期内保持在某个节点上。
静态化和同步的策略比较多，一般采用的方法是集中或者分布存储，但是静态化却是通过集中存储来实现的，然后使用前端的proxy群来实现缓存和分担压力。
7
javaliker says:
June 10th, 2006 at 6:38 pm
Quote
希望有空跟你学习请教网站负载问题。
8
barrycmster says:
June 19th, 2006 at 4:14 pm
Quote
Great website! Bookmarked! I am impressed at your work!
9
heiyeluren says:
June 21st, 2006 at 10:39 am
Quote
一般对于一个中型网站来说，交互操作非常多，日PV百万左右，如何做合理的负载？
10
Michael says:
June 23rd, 2006 at 3:15 pm
Quote
heiyeluren on June 21, 2006 at 10:39 am said:
一般对于一个中型网站来说，交互操作非常多，日PV百万左右，如何做合理的负载？
交互如果非常多，可以考虑使用集群加Memory Cache的方式，把不断变化而且需要同步的数据放入Memory Cache里面进行读取，具体的方案还得需要结合具体的情况来分析。
11
donald says:
June 27th, 2006 at 5:39 pm
Quote
请问，如果一个网站处于技术发展期，那么这些优化手段应该先实施哪些后实施哪些呢？
或者说从成本（技术、人力和财力成本）方面，哪些先实施能够取得最大效果呢？
12
Michael says:
June 27th, 2006 at 9:16 pm
Quote
donald on June 27, 2006 at 5:39 pm said:
请问，如果一个网站处于技术发展期，那么这些优化手段应该先实施哪些后实施哪些呢？
或者说从成本（技术、人力和财力成本）方面，哪些先实施能够取得最大效果呢？
先 从服务器性能优化、代码性能优化方面入手，包括webserver、dbserver的优化配置、html静态化等容易入手的开始，这些环节争取先榨取到 最大化的利用率，然后再考虑从架构上增加投入，比如集群、负载均衡等方面，这些都需要在有一定的发展积累之后再做考虑比较恰当。
13
donald says:
June 30th, 2006 at 4:39 pm
Quote
恩，多谢Michael的耐心讲解
14
Ade says:
July 6th, 2006 at 11:58 am
Quote
写得好,为人也不错.
15
ssbornik says:
July 17th, 2006 at 2:39 pm
Quote
Very good site. Thanks for author!
16
echonow says:
September 1st, 2006 at 2:28 pm
Quote
赞一个先，是一篇很不错的文章，不过要真正掌握里面的东西恐怕还是需要时间和实践！
先问一下关于图片服务器的问题了！
我的台球网站故人居9tmd.com也使用了图片服务器架构上的分离，目前是仅仅是架构上分离，物理上没有分离，由于没有钱买更多的服务器:)，大家可以看到故人居上的图片连接都是类似img.9tmd.com或者img1.9tmd.com的URL。
这个，楼主这个img.9tmd.com是虚拟主机吧，也就是说是一个apache提供的服务吧，这样的话对于性能的提高也很有意义吗？还是只是铺垫，为了方便以后的物理分离呢？
17
Michael says:
September 1st, 2006 at 3:05 pm
Quote
echonow on September 1, 2006 at 2:28 pm said:
赞一个先，是一篇很不错的文章，不过要真正掌握里面的东西恐怕还是需要时间和实践！
先问一下关于图片服务器的问题了！
我的台球网站故人居9tmd.com也使用了图片服务器架构上的分离，目前是仅仅是架构上分离，物理上没有分离，由于没有钱买更多的服务器:)，大家可以看到故人居上的图片连接都是类似img.9tmd.com或者img1.9tmd.com的URL。
这个，楼主这个img.9tmd.com是虚拟主机吧，也就是说是一个apache提供的服务吧，这样的话对于性能的提高也很有意义吗？还是只是铺垫，为了方便以后的物理分离呢？
这 位朋友说得很对，因为目前只有一台服务器，所以从物理上无法实现真正的分离，暂时使用虚拟主机来实现，是为了程序设计和网站架构上的灵活，如果有了一台新 的服务器，我只需要把图片镜像过去或者同步过去，然后把img.9tmd.com的dns解析到新的服务器上就自然实现了分离，如果现在不从架构和程序上 实现，今后这样的分离就会比较痛苦:)
18
echonow says:
September 7th, 2006 at 4:59 pm
Quote
谢谢lz的回复，现在主要实现问题是如何能在素材上传时直接传到图片服务器上呢，总不至于每次先传到web，然后再同步到图片服务器吧
19
Michael says:
September 7th, 2006 at 11:25 pm
Quote
echonow on September 7, 2006 at 4:59 pm said:
谢谢lz的回复，现在主要实现问题是如何能在素材上传时直接传到图片服务器上呢，总不至于每次先传到web，然后再同步到图片服务器吧
通过samba或者nfs实现是比较简单的方法。然后使用squid缓存来降低访问的负载，提高磁盘性能和延长磁盘使用寿命。
20
echonow says:
September 8th, 2006 at 9:42 am
Quote
多谢楼主的耐心指导，我先研究下，用共享区来存储确实是个不错的想法!
21
Michael says:
September 8th, 2006 at 11:16 am
Quote
echonow on September 8, 2006 at 9:42 am said:
多谢楼主的耐心指导，我先研究下，用共享区来存储确实是个不错的想法!
不客气，欢迎常交流！
22
fanstone says:
September 11th, 2006 at 2:26 pm
Quote
Michael，谢谢你的好文章。仔细看了，包括回复，受益匪浅。
Michael on June 27, 2006 at 9:16 pm said:
donald on June 27, 2006 at 5:39 pm said:
请问，如果一个网站处于技术发展期，那么这些优化手段应该先实施哪些后实施哪些呢？
或者说从成本（技术、人力和财力成本）方面，哪些先实施能够取得最大效果呢？
先 从服务器性能优化、代码性能优化方面入手，包括webserver、dbserver的优化配置、html静态化等容易入手的开始，这些环节争取先榨取到 最大化的利用率，然后再考虑从架构上增加投入，比如集群、负载均衡等方面，这些都需要在有一定的发展积累之后再做考虑比较恰当。
尤其这个部分很 是有用，因为我也正在建一个电子商务类的网站，由于是前期阶段，费用的问题毕竟有所影响，所以暂且只用了一台服务器囊括过了整个网站。除去前面所说的图片 服务器分离，还有什么办法能在网站建设初期尽可能的为后期的发展做好优化（性能优化，系统合理构架，前面说的websever、dbserver优化，后 期譬如硬件等扩展尽可能不要过于烦琐等等）？ 也就是所谓的未雨绸缪了，尽可能在先期考虑到后期如果发展壮大的需求，预先做好系统规划，并且在前期资金不足的情况下尽量做到网站以最优异的性能在运行。 关于达到这两个要求，您可以给我一些稍稍详细一点的建议和技术参考吗？谢谢！
看了你的文章，知道你主要关注*nix系统架构的，我的是.net和win2003的，不过我觉得这个影响也不大。主要关注点放在外围的网站优化上。
谢谢!希望能得到您的一些好建议。
23
Michael says:
September 11th, 2006 at 2:55 pm
Quote
回复fanstone：
关于如何在网站的前期尽可能低成本的投入，做到性能最大化利用，同时做好后期系统架构的规划，这个问题可以说已经放大到超出技术范畴，不过和技术相关的部分还是有不少需要考虑的。
一 个网站的规划关键的就是对阶段性目标的规划，比如预测几个月后达到什么用户级别、存储级别、并发请求数，然后再过几个月又将什么情况，这些预测必须根据具 体业务和市场情况来进行预估和不断调整的，有了这些预测数据作为参考，就能进行技术架构的规划，否则技术上是无法合理进行架构设计的。
在网站发展规划基础上，考虑今后要提供什么样的应用？有些什么样的域名关系？各个应用之间的业务逻辑和关联是什么？面对什么地域分布的用户提供服务？等等。。。
上面这些问题有助于规划网站服务器和设备投入，同时从技术上可以及早预测到未来将会是一个什么架构，在满足这个架构下的每个节点将需要满足什么条件，就是初期架构的要求。
总的来说，不结合具体业务的技术规划是没有意义的，所以首先是业务规划，也就是产品设计，然后才是技术规划。
24
fanstone says:
September 11th, 2006 at 8:52 pm
Quote
谢谢解答，我再多看看！
25
Roc says:
March 22nd, 2007 at 11:48 pm
Quote
很 好的文章，楼主说的方法非常适用，目前我们公司的网站也是按照楼主所说的方法进行设计的，效果比较好，利于以后的扩展，另外我再补充一点，其实楼主也说 了，网站的域名也需要提前考虑和规划，比如网站的图片内容比较多，可以按应用图片的类型可以根据不同的业务需求采用不同的域名img1~imgN等，便于 日后的扩展和移至，希望楼主能够多发一些这样的好文章。
26
zhang says:
April 3rd, 2007 at 9:08 am
Quote
图片服务器与主数据分离的问题。
图片是存储在硬盘里好还是存储在数据库里好？
请您分硬盘和数据库两种情况解释下面的疑问。
当存放图片的服务器容量不能满足要求时如何办？
当存放图片的服务器负载不能满足要求时如何办？
谢谢。
27
Michael says:
April 3rd, 2007 at 2:29 pm
Quote
zhang on April 3, 2007 at 9:08 am said:
图片服务器与主数据分离的问题。
图片是存储在硬盘里好还是存储在数据库里好？
请您分硬盘和数据库两种情况解释下面的疑问。
当存放图片的服务器容量不能满足要求时如何办？
当存放图片的服务器负载不能满足要求时如何办？
谢谢。
肯定是存储在硬盘里面，出现存储在数据库里面的说法实际上是出自一些虚拟主机或者租用空间的个人网站和企业网站，因为网站数据量小，也为了备份方便，从大型商业网站来说，没有图片存储在数据库里面的大型应用。数据库容量和效率都会是极大的瓶颈。
你 提到的后面两个问题。容量和负载基本上是同时要考虑的问题，容量方面，大部分的解决方案都是使用海量存储，比如专业的盘阵，入门级的磁盘柜或者高级的光纤 盘阵、局域网盘阵等，这些都是主要的解决方案。记得我原来说过，如果是考虑低成本，一定要自己使用便宜单台服务器来存储，那就需要从程序逻辑上去控制，比 如你可以多台同样的服务器来存储，分别提供NFS的分区给前端应用使用，在前端应用的程序逻辑中自己去控制存储在哪一台服务器的NFS分区上，比如根据 Userid或者图片id、或者别的逻辑去进行散列，这个和我们规划大型数据库存储散列分表或者分库存储的逻辑类似。
基本上图片负载高的解决办法有两种，前端squid缓存和镜像，通过对存储设备（服务器或者盘阵）使用镜像，可以分布到多台服务器上对外提供图片服务，然后再配合squid缓存实现负载的降低和提高用户访问速度。
希望能回答了您的问题。
28
Michael says:
April 3rd, 2007 at 2:41 pm
Quote
Roc on March 22, 2007 at 11:48 pm said:
很 好的文章，楼主说的方法非常适用，目前我们公司的网站也是按照楼主所说的方法进行设计的，效果比较好，利于以后的扩展，另外我再补充一点，其实楼主也说 了，网站的域名也需要提前考虑和规划，比如网站的图片内容比较多，可以按应用图片的类型可以根据不同的业务需求采用不同的域名img1~imgN等，便于 日后的扩展和移至，希望楼主能够多发一些这样的好文章。
欢迎常来交流，还希望能得到你的指点。大家相互学习。
29
zhang says:
April 4th, 2007 at 11:39 pm
Quote
非常感谢您的回复，
希望将来有合作的机会。
再次感谢。
30
Charles says:
April 9th, 2007 at 2:50 pm
Quote
刚才一位朋友把你的 BLOG 发给我看，问我是否认识你，所以我就仔细看了一下你的 BLOG，发现这篇文章。
很不错的一篇文章，基本上一个大型网站需要做的事情都已经提及了。我自己也曾任职于三大门户之一，管理超过 100 台的 SQUID 服务器等，希望可以也分享一下我的经验和看法。
1、图片服务器分离
这个观点是我一直以来都非常支持的。特别是如果程序与图片都放在同一个 APAHCE 的服务器下，每一个图片的请求都有可能导致一个 HTTPD 进程的调用，而 HTTPD 如果包含有 PHP 模块的的时候，就会占用过多的内存，而这个是没有任何必要的。
使用独立的图片服务器不但可以避免以上这个情况，更可以对不同的使用性质的图片设置不同的过期时间，以便同一个用户在不同页面访问相同图片时不会再次从服务器（基于是缓存服务器）取数据，不但止快速，而且还省了带宽。还有就是，对于缓存的时间上，亦可以做调立的调节。
在 我过往所管理的图片服务器中，不但止是将图片与应用及页面中分离出来，还是为不同性质的图片启用不同的域名。以缓解不同性质图片带来的压力。例如 photo.img.domain.com 这个域名是为了摄影服务的，平时使用 5 台 CACHE，但到了 5.1 长假期后，就有可能需要独立为他增加至 10 台。而增加的这 5 台可以从其他负载较低的图片服务器中调动过来临时使用。
2、数据库集群
一 套 ORACLE RAC 的集群布置大概在 40W 左右，这个价格对于一般公司来说，是没有必要的。因为 WEB 的应用逻辑相对较简单，而 ORACLE 这些大型数据库的价值在于数据挖掘，而不在于简单的存储。所以选择 MySQL 或 PostgreSQL 会实际一些。
简单的 MySQL 复制就可以实现较好的效果。读的时候从 SLAVE 读，写的时候才到 MASTER 上更新。实际的情况下，MySQL 的复制性能非常好，基本上不会带来太高的更新延时。使用 balance （http://www.inlab.de/balance.html）这个软件，在本地（127.0.0.1）监听 3306 端口，再映射多个 SLAVE 数据库，可以实现读取的负载均衡。
3、图片保存于磁盘还是数据库？
对 于这个问题，我亦有认真地考虑过。如果是在 ext3 的文件系统下，建 3W 个目录就到极限了，而使用 xfs 的话就没有这个限制。图片的存储，如果需要是大量的保存，必须要分隔成很多个小目录，否则就会有 ext3 只能建 3W 目录的限制，而且文件数及目录数太多会影响磁盘性能。还没有算上空间占用浪费等问题。
更更重要的是，对于一个大量小文件的数据备份，要占用极大的资源和非常长的时间。在这些问题前面，可能将图片保存在数据库是个另外的选择。
可以尝试将图片保存到数据库，前端用 PHP 程序返回实际的图片，再在前端放置一个 SQUID 的服务器，可以避免性能问题。那么图片的备份问题，亦可以利用 MySQL 的数据复制机制来实现。这个问题就可以得到较好的解决了。
4、页面的静态化我就不说了，我自己做的 wordpress 就完全实现了静态化，同时能很好地兼顾动态数据的生成。
5、缓存
我自己之前也提出过使用 memcached，但实际使用中不是非常特别的理想。当然，各个应用环境不一致会有不一致的使用结果，这个并不重要。只要自己觉得好用就用。
6、软件四层交换
LVS 的性能非常好，我有朋友的网站使用了 LVS 来做负责均衡的调度器，数据量非常大都可以轻松支撑。当然是使用了 DR 的方式。
其实我自己还想过可以用 LVS 来做 CDN 的调度。例如北京的 BGP 机房接受用户的请求，然后通过 LVS 的 TUN 方式，将请求调度到电信或网通机房的实际物理服务器上，直接向用户返回数据。
这种是 WAN 的调度，F5 这些硬件设备也应用这样的技术。不过使用 LVS 来实现费用就大大降低。
以上都只属个人观点，能力有限，希望对大家有帮助。 ：）
31
Michael says:
April 9th, 2007 at 8:17 pm
Quote
很少见到有朋友能在我得blog上留下这么多有价值的东西，代表别的可能看到这篇文章的朋友一起感谢你。
balance （http://www.inlab.de/balance.html） 这个东西准备看一下。
32
Michael says:
April 16th, 2007 at 1:29 am
Quote
如 果要说3Par的光纤存储局域网技术细节，我无法给您太多解释，我对他们的产品没有接触也没有了解，不过从SAN的概念上是可以知道大概框架的，它也是一 种基于光纤通道的存储局域网，可以支持远距离传输和较高的系统扩展性，传统的SAN使用专门的FC光通道SCSI磁盘阵列，从你提供的内容来看，3Par 这个东西建立在低成本的SATA或FATA磁盘阵列基础上，这一方面能降低成本，同时估计3Par在技术上有创新和改进，从而提供了廉价的高性能存储应 用。
这个东西细节只有他们自己知道，你就知道这是个商业的SAN （存储局域网，说白了也是盘阵，只是通过光纤通道独立于系统外的）。
33
zhang says:
April 16th, 2007 at 2:10 am
Quote
myspace和美国的许多银行都更换为了3Par
请您在百忙之中核实一下，是否确实像说的那么好。
下面是摘抄：
Priceline.com 是一家以销售空座机票为主的网络公司，客户数量多达680万。该公司近期正在内部实施一项大规模的SAN系统整合计划，一口气购进了5套3PARdata 的服务器系统，用以替代现有的上百台Sun存储阵列。如果该方案部署成功的话，将有望为Priceline.com节省大量的存储管理时间、资本开销及系 统维护费用。
　　Priceline.com之前一直在使用的SAN系统是由50台光纤磁盘阵列、50台SCSI磁盘阵列和15台存储服务器构 成的。此次，该公司一举购入了5台3Par S400 InServ Storage Servers存储服务器，用以替代原来的服务器系统，使得设备整体能耗、占用空间及散热一举降低了60%。整个系统部署下来，总存储容量将逼近 30TB。
　　Priceline的首席信息官Ron Rose拒绝透露该公司之前所使用的SAN系统设备的供应商名称，不过，消息灵通人士表示，PriceLine原来的存储环境是由不同型号的Sun系统混合搭建而成的。
　 　“我们并不愿意随便更换系统供应商，不过，3Par的存储系统所具备的高投资回报率，实在令人难以抗拒，”Rose介绍说，“我们给了原来的设备供应商 以足够的适应时间，希望它们的存储设备也能够提供与3Par一样的效能，最后，我们失望了。如果换成3Par的存储系统的话，短期内就可以立刻见到成 效。”
　　Rose接着补充说，“原先使用的那套SAN系统，并没有太多让我们不满意的地方，除了欠缺一点灵活性之外：系统的配置方案堪称不错，但并不是最优化的。使用了大量价格偏贵的光纤磁盘，许多SAN端口都是闲置的。”
自 从更换成3Par的磁盘阵列之后，该公司存储系统的端口数量从90个骤减为24个。“我们购买的软件许可证都是按端口数量来收费的。每增加一个端口，需要 额外支付500-1,500美元，单单这一项，就为我们节省了一笔相当可观的开支，”Rose解释说。而且，一旦启用3Par的精简自动配置软件，系统资 源利用率将有望提升30%，至少在近一段时间内该公司不必考虑添置新的磁盘系统。
　　精简自动配置技术最大的功效就在于它能够按照应用程序的实 际需求来分配存储资源，有效地降低了空间闲置率。如果当前运行的应用程序需要额外的存储资源的话，该软件将在不干扰应用程序正常运行的前提下，基于“按 需”和“公用”的原则来自动发放资源空间，避免了人力干预，至少为存储管理员减轻了一半以上的工作量。
　　3Par的磁盘阵列是由低成本的SATA和FATA（即：低成本光纤信道接口）磁盘驱动器构成的，而并非昂贵的高效能FC磁盘，大大降低了系统整体成本。
　 　3Par推出的SAN解决方案，实际上是遵循了“允许多个分布式介质服务器共享通过光纤信道SAN 连接的公共的集中化存储设备”的设计理念。“这样一来，就不必给所有的存储设备都外挂一个代理服务程序了，”Rose介绍说。出于容灾容错和负载均衡的考 虑，Priceline搭建了两个生产站点，每一个站点都部署了一套3Par SAN系统。此外，Priceline还购买了两台3Par Inservs服务器，安置在主数据中心内，专门用于存放镜像文件。第5台服务器设置在Priceline的企业资料处理中心内，用于存放数据仓库；第6 台服务器设置在实验室内，专门用于进行实际网站压力测试。
MySpace目前采用了一种新型SAN设备——来自加利福尼亚州弗里蒙特的 3PARdata。在3PAR的系统里，仍能在逻辑上按容量划分数据存储，但它不再被绑定到特定磁盘或磁盘簇，而是散布于大量磁盘。这就使均分数据访问负 荷成为可能。当数据库需要写入一组数据时，任何空闲磁盘都可以马上完成这项工作，而不再像以前那样阻塞在可能已经过载的磁盘阵列处。而且，因为多个磁盘都 有数据副本，读取数据时，也不会使SAN的任何组件过载。
3PAR宣布，VoIP服务供应商Cbeyond Communications已向它订购了两套InServ存储服务器，一套应用于该公司的可操作支持系统，一套应用于测试和开发系统环境。3PAR的总 部设在亚特兰大，该公司的产品多销往美国各州首府和大城市，比如说亚特兰大、达拉斯、丹佛、休斯顿、芝加哥，等等。截至目前为止，3PAR售出的服务器数 量已超过了15,000台，许多客户都是来自于各行各业的龙头企业，它们之所以挑选3PAR的产品，主要是看中了它所具备的高性能、可扩展性、操作简单、 无比伦比的性价比等优点，另外，3PAR推出的服务器系列具有高度的集成性能，适合应用于高速度的T1互联网接入、本地和长途语音服务、虚拟主机（Web hosting）、电子邮件、电话会议和虚拟个人网络（VPN）等服务领域。
亿万用户网站MySpace的成功秘密
◎ 文 / David F. Carr 译 / 罗小平
高 速增长的访问量给社区网络的技术体系带来了巨大挑战。MySpace的开发者多年来不断重构站点软件、数据库和存储系统，以期与自身的成长同步——目前， 该站点月访问量已达400亿。绝大多数网站需要应对的流量都不及MySpace的一小部分，但那些指望迈入庞大在线市场的人，可以从MySpace的成长 过程学到知识。
MySpace开发人员已经多次重构站点软件、数据库和存储系统，以满足爆炸性的成长需要，但此工作永不会停息。“就像粉刷金门 大桥，工作完成之时，就是重新来过之日。”（译者注：意指工人从桥头开始粉刷，当到达桥尾时，桥头涂料已经剥落，必须重新开始）MySpace技术副总裁 Jim Benedetto说。
既然如此，MySpace的技术还有何可学之处？因为MySpace事实上已经解决了很多系统扩展性问题，才能走到今天。
Benedetto说他的项目组有很多教训必须总结，他们仍在学习，路漫漫而修远。他们当前需要改进的工作包括实现更灵活的数据缓存系统，以及为避免再次出现类似7月瘫痪事件的地理上分布式架构。
背景知识
当 然，这么多的用户不停发布消息、撰写评论或者更新个人资料，甚至一些人整天都泡在Space上，必然给MySpace的技术工作带来前所未有的挑战。而传 统新闻站点的绝大多数内容都是由编辑团队整理后主动提供给用户消费，它们的内容数据库通常可以优化为只读模式，因为用户评论等引起的增加和更新操作很少。 而MySpace是由用户提供内容，数据库很大比例的操作都是插入和更新，而非读取。
浏览MySpace上的任何个人资料时，系统都必须先查询数据库，然后动态创建页面。当然，通过数据缓存，可以减轻数据库的压力，但这种方案必须解决原始数据被用户频繁更新带来的同步问题。
MySpace的站点架构已经历了5个版本——每次都是用户数达到一个里程碑后，必须做大量的调整和优化。Benedetto说，“但我们始终跟不上形势的发展速度。我们重构重构再重构，一步步挪到今天”。
在每个里程碑，站点负担都会超过底层系统部分组件的最大载荷，特别是数据库和存储系统。接着，功能出现问题，用户失声尖叫。最后，技术团队必须为此修订系统策略。
虽然自2005年早期，站点账户数超过7百万后，系统架构到目前为止保持了相对稳定，但MySpace仍然在为SQL Server支持的同时连接数等方面继续攻坚，Benedetto说，“我们已经尽可能把事情做到最好”。
里程碑一：50万账户
按Benedetto 的说法，MySpace最初的系统很小，只有两台Web服务器和一个数据库服务器。那时使用的是Dell双CPU、4G内存的系统。
单个数据库就意味着所有数据都存储在一个地方，再由两台Web服务器分担处理用户请求的工作量。但就像MySpace后来的几次底层系统修订时的情况一样，三服务器架构很快不堪重负。此后一个时期内，MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。
但到在2004年早期，MySpace用户数增长到50万后，数据库服务器也已开始汗流浃背。
但和Web服务器不同，增加数据库可没那么简单。如果一个站点由多个数据库支持，设计者必须考虑的是，如何在保证数据一致性的前提下，让多个数据库分担压力。
在 第二代架构中，MySpace运行在3个SQL Server数据库服务器上——一个为主，所有的新数据都向它提交，然后由它复制到其他两个；另两个全力向用户供给数据，用以在博客和个人资料栏显示。这 种方式在一段时间内效果很好——只要增加数据库服务器，加大硬盘，就可以应对用户数和访问量的增加。
里程碑二：1-2百万账户
MySpace 注册数到达1百万至2百万区间后，数据库服务器开始受制于I/O容量——即它们存取数据的速度。而当时才是2004年中，距离上次数据库系统调整不过数 月。用户的提交请求被阻塞，就像千人乐迷要挤进只能容纳几百人的夜总会，站点开始遭遇“主要矛盾”，Benedetto说，这意味着MySpace永远都 会轻度落后于用户需求。
“有人花5分钟都无法完成留言，因此用户总是抱怨说网站已经完蛋了。”他补充道。
这一次的数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能，如登录、用户资料和博客。于是，站点的扩展性问题看似又可以告一段落了，可以歇一阵子。
垂 直分割策略利于多个数据库分担访问压力，当用户要求增加新功能时，MySpace将投入新的数据库予以支持它。账户到达2百万后，MySpace还从存储 设备与数据库服务器直接交互的方式切换到SAN（Storage Area Network，存储区域网络）——用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施极大提升了系统性能、正常运 行时间和可靠性，Benedetto说。
里程碑三：3百万账户
当用户继续增加到3百万后，垂直分割策略也开始难以为继。尽管站点的各 个应用被设计得高度独立，但有些信息必须共享。在这个架构里，每个数据库必须有各自的用户表副本——MySpace授权用户的电子花名册。这就意味着一个 用户注册时，该条账户记录必须在9个不同数据库上分别创建。但在个别情况下，如果其中某台数据库服务器临时不可到达，对应事务就会失败，从而造成账户非完 全创建，最终导致此用户的该项服务无效。
另外一个问题是，个别应用如博客增长太快，那么专门为它服务的数据库就有巨大压力。
2004 年中，MySpace面临Web开发者称之为“向上扩展”对“向外扩展”（译者注：Scale Up和Scale Out，也称硬件扩展和软件扩展）的抉择——要么扩展到更大更强、也更昂贵的服务器上，要么部署大量相对便宜的服务器来分担数据库压力。一般来说，大型站 点倾向于向外扩展，因为这将让它们得以保留通过增加服务器以提升系统能力的后路。
但成功地向外扩展架构必须解决复杂的分布式计算问题，大型站点如Google、Yahoo和Amazon.com，都必须自行研发大量相关技术。以Google为例，它构建了自己的分布式文件系统。
另外，向外扩展策略还需要大量重写原来软件，以保证系统能在分布式服务器上运行。“搞不好，开发人员的所有工作都将白费”，Benedetto说。
因此，MySpace首先将重点放在了向上扩展上，花费了大约1个半月时间研究升级到32CPU服务器以管理更大数据库的问题。Benedetto说，“那时候，这个方案看似可能解决一切问题。”如稳定性，更棒的是对现有软件几乎没有改动要求。
糟糕的是，高端服务器极其昂贵，是购置同样处理能力和内存速度的多台服务器总和的很多倍。而且，站点架构师预测，从长期来看，即便是巨型数据库，最后也会不堪重负，Benedetto说，“换句话讲，只要增长趋势存在，我们最后无论如何都要走上向外扩展的道路。”
因 此，MySpace最终将目光移到分布式计算架构——它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来说，就不能再像过去那样将应 用拆分，再以不同数据库分别支持，而必须将整个站点看作一个应用。现在，数据库模型里只有一个用户表，支持博客、个人资料和其他核心功能的数据都存储在相 同数据库。
既然所有的核心数据逻辑上都组织到一个数据库，那么MySpace必须找到新的办法以分担负荷——显然，运行在普通硬件上的单个数据 库服务器是无能为力的。这次，不再按站点功能和应用分割数据库，MySpace开始将它的用户按每百万一组分割，然后将各组的全部数据分别存入独立的 SQL Server实例。目前，MySpace的每台数据库服务器实际运行两个SQL Server实例，也就是说每台服务器服务大约2百万用户。Benedetto指出，以后还可以按照这种模式以更小粒度划分架构，从而优化负荷分担。
当然，还是有一个特殊数据库保存了所有账户的名称和密码。用户登录后，保存了他们其他数据的数据库再接管服务。特殊数据库的用户表虽然庞大，但它只负责用户登录，功能单一，所以负荷还是比较容易控制的。
里程碑四：9百万到1千7百万账户
2005 年早期，账户达到9百万后，MySpace开始用Microsoft的C#编写ASP.NET程序。C#是C语言的最新派生语言，吸收了C++和Java 的优点，依托于Microsoft .NET框架（Microsoft为软件组件化和分布式计算而设计的模型架构）。ASP.NET则由编写Web站点脚本的ASP技术演化而来，是 Microsoft目前主推的Web站点编程环境。
可以说是立竿见影，MySpace马上就发现ASP.NET程序运行更有效率，与 ColdFusion相比，完成同样任务需消耗的处理器能力更小。据技术总监Whitcomb说，新代码需要150台服务器完成的工作，如果用 ColdFusion则需要246台。Benedetto还指出，性能上升的另一个原因可能是在变换软件平台，并用新语言重写代码的过程中，程序员复审并 优化了一些功能流程。
最终，MySpace开始大规模迁移到ASP.NET。即便剩余的少部分ColdFusion代码，也从Cold- Fusion服务器搬到了ASP.NET，因为他们得到了BlueDragon.NET（乔治亚州阿尔法利塔New Atlanta Communications公司的产品，它能将ColdFusion代码自动重新编译到Microsoft平台）的帮助。
账户达到1千万时，MySpace再次遭遇存储瓶颈问题。SAN的引入解决了早期一些性能问题，但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。
原因之一是每数据库1百万账户的分割策略，通常情况下的确可以将压力均分到各台服务器，但现实并非一成不变。比如第七台账户数据库上线后，仅仅7天就被塞满了，主要原因是佛罗里达一个乐队的歌迷疯狂注册。
某个数据库可能因为任何原因，在任何时候遭遇主要负荷，这时，SAN中绑定到该数据库的磁盘存储设备簇就可能过载。“SAN让磁盘I/O能力大幅提升了，但将它们绑定到特定数据库的做法是错误的。”Benedetto说。
最初，MySpace通过定期重新分配SAN中数据，以让其更为均衡的方法基本解决了这个问题，但这是一个人工过程，“大概需要两个人全职工作。”Benedetto说。
长期解决方案是迁移到虚拟存储体系上，这样，整个SAN被当作一个巨型存储池，不再要求每个磁盘为特定应用服务。MySpace目前采用了一种新型SAN设备——来自加利福尼亚州弗里蒙特的3PARdata。
在 3PAR的系统里，仍能在逻辑上按容量划分数据存储，但它不再被绑定到特定磁盘或磁盘簇，而是散布于大量磁盘。这就使均分数据访问负荷成为可能。当数据库 需要写入一组数据时，任何空闲磁盘都可以马上完成这项工作，而不再像以前那样阻塞在可能已经过载的磁盘阵列处。而且，因为多个磁盘都有数据副本，读取数据 时，也不会使SAN的任何组件过载。
当2005年春天账户数达到1千7百万时，MySpace又启用了新的策略以减轻存储系统压力，即增加数据 缓存层——位于Web服务器和数据库服务器之间，其唯一职能是在内存中建立被频繁请求数据对象的副本，如此一来，不访问数据库也可以向Web应用供给数 据。换句话说，100个用户请求同一份资料，以前需要查询数据库100次，而现在只需1次，其余都可从缓存数据中获得。当然如果页面变化，缓存的数据必须 从内存擦除，然后重新从数据库获取——但在此之前，数据库的压力已经大大减轻，整个站点的性能得到提升。
缓存区还为那些不需要记入数据库的数据提供了驿站，比如为跟踪用户会话而创建的临时文件——Benedetto坦言他需要在这方面补课，“我是数据库存储狂热分子，因此我总是想着将万事万物都存到数据库。”但将像会话跟踪这类的数据也存到数据库，站点将陷入泥沼。
增加缓存服务器是“一开始就应该做的事情，但我们成长太快，以致于没有时间坐下来好好研究这件事情。”Benedetto补充道。
里程碑五：2千6百万账户
2005 年中期，服务账户数达到2千6百万时，MySpace切换到了还处于beta测试的SQL Server 2005。转换何太急？主流看法是2005版支持64位处理器。但Benedetto说，“这不是主要原因，尽管这也很重要；主要还是因为我们对内存的渴 求。”支持64位的数据库可以管理更多内存。
更多内存就意味着更高的性能和更大的容量。原来运行32位版本的SQL Server服务器，能同时使用的内存最多只有4G。切换到64位，就好像加粗了输水管的直径。升级到SQL Server 2005和64位Windows Server 2003后，MySpace每台服务器配备了32G内存，后于2006年再次将配置标准提升到64G。
意外错误
如果没有对系统架构的历次修改与升级，MySpace根本不可能走到今天。但是，为什么系统还经常吃撑着了？很多用户抱怨的“意外错误”是怎么引起的呢？
原 因之一是MySpace对Microsoft的Web技术的应用已经进入连Microsoft自己也才刚刚开始探索的领域。比如11月，超出SQL Server最大同时连接数，MySpace系统崩溃。Benedetto说，这类可能引发系统崩溃的情况大概三天才会出现一次，但仍然过于频繁了，以致 惹人恼怒。一旦数据库**，“无论这种情况什么时候发生，未缓存的数据都不能从SQL Server获得，那么你就必然看到一个‘意外错误’提示。”他解释说。
去年夏天，MySpace的Windows 2003多次自动停止服务。后来发现是操作系统一个内置功能惹的祸——预防分布式拒绝服务攻击（黑客使用很多客户机向服务器发起大量连接请求，以致服务器 瘫痪）。MySpace和其他很多顶级大站点一样，肯定会经常遭受攻击，但它应该从网络级而不是依靠Windows本身的功能来解决问题——否则，大量 MySpace合法用户连接时也会引起服务器反击。
“我们花了大约一个月时间寻找Windows 2003服务器自动停止的原因。”Benedetto说。最后，通过Microsoft的帮助，他们才知道该怎么通知服务器：“别开枪，是友军。”
紧 接着是在去年7月某个周日晚上，MySpace总部所在地洛杉矶停电，造成整个系统停运12小时。大型Web站点通常要在地理上分布配置多个数据中心以预 防单点故障。本来，MySpace还有其他两个数据中心以应对突发事件，但Web服务器都依赖于部署在洛杉矶的SAN。没有洛杉矶的SAN，Web服务器 除了恳求你耐心等待，不能提供任何服务。
Benedetto说，主数据中心的可靠性通过下列措施保证：可接入两张不同电网，另有后备电源和一台储备有30天燃料的发电机。但在这次事故中，不仅两张电网失效，而且在切换到备份电源的过程中，操作员烧掉了主动力线路。
2007年中，MySpace在另两个后备站点上也建设了SAN。这对分担负荷大有帮助——正常情况下，每个SAN都能负担三分之一的数据访问量。而在紧急情况下，任何一个站点都可以独立支撑整个服务，Benedetto说。
MySpace仍然在为提高稳定性奋斗，虽然很多用户表示了足够信任且能原谅偶现的错误页面。
“作 为开发人员，我憎恶Bug，它太气人了。”Dan Tanner这个31岁的德克萨斯软件工程师说，他通过MySpace重新联系到了高中和大学同学。“不过，MySpace对我们的用处很大，因此我们可 以原谅偶发的故障和错误。” Tanner说，如果站点某天出现故障甚至崩溃，恢复以后他还是会继续使用。
这就是为什么Drew在论坛里咆哮 时，大部分用户都告诉他应该保持平静，如果等几分钟，问题就会解决的原因。Drew无法平静，他写道，“我已经两次给MySpace发邮件，而它说一小时 前还是正常的，现在出了点问题……完全是一堆废话。”另一个用户回复说，“毕竟它是免费的。”Benedetto坦承100%的可靠性不是他的目标。“它 不是银行，而是一个免费的服务。”他说。
换句话说，MySpace的偶发故障可能造成某人最后更新的个人资料丢失，但并不意味着网站弄丢了用户 的钱财。“关键是要认识到，与保证站点性能相比，丢失少许数据的故障是可接受的。”Benedetto说。所以，MySpace甘冒丢失2分钟到2小时内 任意点数据的危险，在SQL Server配置里延长了“checkpoint”操作——它将待更新数据永久记录到磁盘——的间隔时间，因为这样做可以加快数据库的运行。
Benedetto 说，同样，开发人员还经常在几个小时内就完成构思、编码、测试和发布全过程。这有引入Bug的风险，但这样做可以更快实现新功能。而且，因为进行大规模真 实测试不具可行性，他们的测试通常是在仅以部分活跃用户为对象，且用户对软件新功能和改进不知就里的情况下进行的。因为事实上不可能做真实的加载测试，他 们做的测试通常都是针对站点。
“我们犯过大量错误，”Benedetto说，“但到头来，我认为我们做对的还是比做错的多。”
34
zhang says:
April 16th, 2007 at 2:15 am
Quote
了解联合数据库服务器
为 达到最大型网站所需的高性能级别，多层系统一般在多个服务器之间平衡每一层的处理负荷。SQL Server 2005 通过对 SQL Server 数据库中的数据进行水平分区，在一组服务器之间分摊数据库处理负荷。这些服务器独立管理，但协作处理应用程序的数据库请求；这样一组协作服务器称为“联合 体”。
只有在应用程序将每个 SQL 语句发送到包含该语句所需的大部分数据的成员服务器时，联合数据库层才能达到非常高的性能级别。这称为使用语句所需的数据来配置 SQL 语句。使用所需的数据来配置 SQL 语句不是联合服务器所特有的要求。群集系统也有此要求。
虽然服务器联合体与单个数据库服务器对应用程序来说是一样的，但在实现数据库服务层的方式上存在内部差异，
35
Michael says:
April 16th, 2007 at 3:18 am
Quote
关 于MySpace是否使用了3Par的SAN，并且起到多大的关键作用，我也无法考证，也许可以通过在MySpace工作的朋友可以了解到，但是从各种数 据和一些案例来看，3Par的确可以改善成本过高和存储I/O性能问题，但是实际应用中，除非电信、银行或者真的类似MySpace这样规模的站点，的确 很少遇到存储连SAN都无法满足的情况，另外，对于数据库方面，据我知道，凡电信、金融和互联网上电子商务关键数据应用，基本上Oracle才是最终的解 决方案。 包括我曾经工作的Yahoo，他们全球超过70%以上应用使用MySQL，但是和钱相关的或者丢失数据会承担责任的应用，都是使用Oracle。在UDB 方面，我相信Yahoo的用户数一定超过MySpace的几千万。
事实上，国内最值得研究的案例应该是腾讯，腾讯目前的数据量一定是惊人的，在和周小旻的一次短暂对话中知道腾讯的架构专家自己实现了大部分的技术，细节我无法得知。
36
Michael says:
April 16th, 2007 at 3:23 am
Quote
图 片存储到数据库我依然不赞同，不过一定要这么做也不是不可以，您提到的使用CGI程序输出到用户客户端，基本上每种web编程语言都支持，只要能输出标准 的HTTP Header信息就可以了，比如PHP可以使用 header(”content-type:image/jpeg\r\n”); 语句输出当前http返回的文件mime类型为图片，同时还有更多的header()函数可以输出的HTTP Header信息，包括 content-length 之类的（提供range 断点续传需要），具体的可以参考PHP的手册。 另外，perl、asp、jsp这些都提供类似的实现方法，这不是语言问题，而是一个HTTP协议问题。
37
zhang says:
April 16th, 2007 at 8:52 am
Quote
早晨，其实已经是上午，起床后，
看到您凌晨3：23的回复，非常感动。
一定注意身体。
好像您还没有太太，
太太和孩子也像正规程序一样，会良好地调节您的身体。
千万不要使用野程序调节身体，会中毒。
开个玩笑。
38
zhang says:
April 16th, 2007 at 8:59 am
Quote
看到您凌晨3：23的回复，
非常感动！
一定注意身体，
好像您还没有太太，
太太和孩子就像正规程序一样，能够良好地调节您的身体，
千万不要使用野程序调节身体，会中毒。
开个玩笑。
39
Michael says:
April 16th, 2007 at 11:04 am
Quote
zhang on April 16, 2007 at 8:59 am said:
看到您凌晨3：23的回复，
非常感动！
一定注意身体，
好像您还没有太太，
太太和孩子就像正规程序一样，能够良好地调节您的身体，
千万不要使用野程序调节身体，会中毒。
开个玩笑。
哈哈，最近我是有点疯狂，不过从大学开始，似乎就习惯了晚睡，我基本多年都保持2点左右睡觉，8点左右起床，昨晚有点夸张，因为看一个文档和写一些东西一口气就到3点多了，临睡前看到您的留言，顺便就回复了。
40
myld says:
April 18th, 2007 at 1:38 pm
Quote
感谢楼主写了这么好的文章，谢谢！！！
41
楓之谷外掛 says:
April 27th, 2007 at 11:04 pm
Quote
看ㄋ你的文章，很有感覺的說．我自己也做網站，希望可以多多交流一下，大家保持聯繫．
http://www.gameon9.com/
http://www.gameon9.com.tw/
42
南半球 says:
May 9th, 2007 at 8:22 pm
Quote
关于两位老大讨论的：图片保存于磁盘还是数据库
个人觉得数据库存文件的话，查询速度可能快点，但数据量很大的时候要加上索引，这样添加记录的速度就慢了
mysql对大数据量的处理能力还不是很强，上千万条记录时，性能也会下降
数据库另外一个瓶颈问题就是连接
用 数据库，就要调用后台程序（JSP/JAVA,PHP等）连接数据库，而数据库的连接连接、传输数据都要耗费系统资源。数据库的连接数也是个瓶颈问题。曾 经写过一个很烂的程序，每秒访问3到5次的数据库，结果一天下来要连接20多万次数据库，把对方的mysql数据库搞瘫痪了。
43
zhang says:
May 19th, 2007 at 12:07 am
Quote
抽空儿回这里浏览了一下，
有收获，
“写真照”换了，显得更帅了。
ok
44
Michael says:
May 19th, 2007 at 12:17 am
Quote
zhang on May 19, 2007 at 12:07 am said:
抽空儿回这里浏览了一下，
有收获，
“写真照”换了，显得更帅了。
ok
哈哈，让您见笑了
45
David says:
May 30th, 2007 at 3:27 pm
Quote
很好，虽然我不是做web的，但看了还是收益良多。
46
pig345 says:
June 13th, 2007 at 10:23 am
Quote
感谢Michael
47
疯子日记 says:
June 13th, 2007 at 10:12 pm
Quote
回复:说说大型高并发高负载网站的系统架构 …
好文章!学习中………….
48
terry says:
June 15th, 2007 at 4:29 pm
Quote
推荐nginx
49
7u5 says:
June 16th, 2007 at 11:54 pm
Quote
拜读
50
Michael says:
June 16th, 2007 at 11:59 pm
Quote
terry on June 15, 2007 at 4:29 pm said:
推荐nginx
欢迎分享Nginx方面的经验:)
51
说说大型高并发高负载网站的系统架构 - 红色的河 says:
June 21st, 2007 at 11:40 pm
Quote
[…] 来源：http://www.toplee.com/blog/archives/71.html 时间：11:40 下午 | 分类：技术文摘 标签：系统架构, 大型网站, 性能优化 […]
52
laoyao2k says:
June 23rd, 2007 at 11:35 am
Quote
看到大家都推荐图片分离，我也知道这样很好，但页面里的图片的绝对网址是开发的时候就写进去的，还是最终执行的时候替换的呢？
如果是开发原始网页就写进去的，那本地调试的时候又是怎么显示的呢？
如果是最终执行的时候替换的话，是用的什么方法呢？
53
Michael says:
June 23rd, 2007 at 8:21 pm
Quote
都可以，写到配置文件里面就可以，或者用全局变量定义，方法很多也都能实现，哪怕写死了在开发的时候把本地调试也都配好图片server，在hosts文件里面指定一下ip到本地就可以了。
假设用最终执行时候的替换，就配置你的apache或者别的server上的mod_rewrite模块来实现，具体的参照相关文档。
54
laoyao2k says:
June 25th, 2007 at 6:43 pm
Quote
先谢谢博主的回复，一直在找一种方便的方法将图片分离。
看来是最终替换法比较灵活，但我知道mod_rewrite是用来将用户提交的网址转换成服务器上的真实网址。
看了博主的回复好像它还有把网页执行的结果进行替换后再返回给浏览器的功能，是这样吗？
55
Michael says:
June 25th, 2007 at 11:00 pm
Quote
不是，只转换用户请求，对url进行rewrite，进行重定向到新的url上，规则很灵活，建议仔细看看lighttpd或者apache的mod_rewrite文档，当然IIS也有类似的模块。
56
laoyao2k says:
June 25th, 2007 at 11:56 pm
Quote
我知道了，如果要让客户浏览的网页代码里的图片地址是绝对地址，只能在开发时就写死了(对于静态页面)或用变量替换(对于动态页面更灵活些)，是这样吗？
我以为有更简单的方法呢，谢博主指点了。
57
马蜂不蛰 says:
July 24th, 2007 at 1:25 pm
Quote
请教楼主：
我正在搞一个医学教育视频资源在线预览的网站，只提供几分钟的视频预览，用swf格式，会员收看预览后线下可购买DVD光碟。
系统架构打算使用三台服务器：网页服务器、数据库服务器、视频服务器。
网页使用全部静态，数据库用SQL Server 2000，CMS是用ASP开发的。
会员数按十万级设计，不使用库表散列技术，请楼主给个建议，看看我的方案可行不？
58
Michael says:
July 24th, 2007 at 11:56 pm
Quote
这个数量级的应用好好配置优化一下服务器和代码，三台服务器完全没有问题，关键不是看整体会员数有多少，而是看同时在线的并发数有多少，并发不多就完全没有问题了，并发多的话，三台的这种架构还是有些问题的。
? mixi技术架构
mixi.jp：使用开源软件搭建的可扩展SNS网站
总概关键点：
1，Mysql 切分，采用Innodb运行
2，动态Cache 服务器 --
美国Facebok.com,中国Yeejee.com,日本mixi.jp均采用开源分布式缓存服务器Memcache
3，图片缓存和加

于敦德 2006-6-27
Mixi目前是日本排名第三的网站，全球排名42，主要提供SNS服务：日记，群组，站内消息，评论，相册等 等，是日本最大的SNS网站。Mixi从2003年12月份开始开发，由现在它的CTO - Batara Kesuma一个人焊，焊了四个月，在2004年2月份开始上线运行。两个月后就注册了1w用户，日访问量60wPV。在随后的一年里，用户增长到了 21w，第二年，增长到了200w。到今年四月份已经增长到370w注册用户，并且还在以每天1.5w人的注册量增长。这些用户中70%是活跃用户（活跃 用户：三天内至少登录一次的用户），平均每个用户每周在线时间为将近3个半小时。

下面我们来看它的技术架构。Mixi采用开源软件作为架构的基础：Linux 2.6，Apache 2.0，MySQL，Perl 5.8，memcached，Squid等等。到目前为止已经有100多台MySQL数据库服务器，并且在以每月10多台的速度增长。Mixi的数据库连 接方式采用的是每次查询都进行连接，而不是持久连接。数据库大多数是以InnoDB方式运行。Mixi解决扩展问题主要依赖于对数据库的切分。
首 先进行垂直切分，按照表的内容将不同的表划分到不同的数据库中。然后是水平切分，根据用户的ID将不同用户的内容再划分的不同的数据库中，这是比较通常的 做法，也很管用。划分的关键还是在于应用中的实现，需要将操作封装在在数据层，而尽量不影响业务层。当然完全不改变逻辑层也不可能，这时候最能检验以前的 设计是否到位，如果以前设计的不错，那创建连接的时候传个表名，用户ID进去差不多就解决问题了，而以前如果sql代码到处飞，或者数据层封装的不太好的 话那就累了。
这样做了以后并不能从根本上解决问题，尤其是对于像mixi这种SNS网站，页面上往往需要引用大量的用户信息，好友信息，图片， 文章信息，跨表，跨库操作相当多。这个时候就需要发挥memcached的作用了，用大内存把这些不变的数据全都缓存起来，而当修改时就通知cache过 期，这样应用层基本上就可以解决大部分问题了，只会有很小一部分请求穿透应用层，用到数据库。Mixi的经验是平均每个页面的加载时间在0.02秒左右 （当然根据页面大小情况不尽相似），可以说明这种做法是行之有效的。Mixi一共在32台机器上有缓存服务器，每个Cache Server 2G内存，这些Cache Server与App Server装在一起。因为Cache Server对CPU消耗不大，而有了Cache Server的支援，App Server对内存要求也不是太高，所以可以和平共处，更有效的利用资源。

http://dbplus.blog.51cto.com/194965/33632
? memcached+squid+apache deflate解决网站大访问量问题
不 许联想的RSS之前停了两天，据说是因为服务器负荷不了技术人员建议给关了，不输出RSS能减轻多少负载呢？所以月光博客不干了，出来给支了几招，但对于 个人博客可能管用，对于流量更大的专业网站显然需要进一步的优化。途牛最近的访问量增长得比较快，所以很多页面load比较慢。之前我们就一直使用 memcached进行了缓存以减轻数据库的压力，近期又对sql查询进行了优化，数据库的性能得到了明显的改善。途牛有很大一部分资源是图片，针对这个 我们使用squid进行了缓存，这部分还包括js、css等一些静态文件。由于我们又有社区，用户的反馈比较多，所以页面并没有使用缓存，而是使用 Apache的deflate模块进行压缩。技术实现都比较简单但非常实用，通过这几步优化，途牛在响应速度上有了不小的提高。

? FeedBurner:基于MySQL和JAVA的可扩展Web应用
于敦德 2006-6-27
FeedBurner（以 下简称FB，呵呵）我想应该是大家耳熟能详的一个名字，在国内我们有一个同样的服务商，叫做FeedSky。在2004年7月份，FB的流量是 300kbps，托管是5600个源，到2005年4月份，流量已经增长到5Mbps，托管了47700个源；到2005年9月份流量增长到20M，托管 了109200个源，而到2006年4月份，流量已经到了115Mbps，270000个源，每天点击量一亿次。
FB的服务使用Java实现，使用了Mysql数据库。我们下面来看一下FB在发展的过程中碰到的问题，以及解决的方案。
在 2004年8月份，FB的硬件设备包括3台Web服务器，3台应用服务器和两台数据库服务器，使用DNS轮循分布服务负载，将前端请求分布到三台Web服 务器上。说实话，如果不考虑稳定性，给5600个源提供服务应该用不了这么多服务器。现在的问题是即使用了这么多服务器他们还是无法避免单点问题，单点问 题将至少影响到1/3的用户。FB采用了监控的办法来解决，当监控到有问题出现时及时重启来避免更多用户受到影响。FB采用了Cacti(http://www.cacti.net/)和Nagios(http://www.nagios.org/)来做监控。
FB 碰到的第二个问题是访问统计和管理。可以想象，每当我们在RSS阅读器里点击FB发布的内容，都需要做实时的统计，这个工作量是多么的巨大。大量写操作将 导致系统的效率急剧下降，如果是Myisam表的话还会导致表的死锁。FB一方面采用异步写入机制，通过创建执行池来缓冲写操作；只对本日的数据进行实时 统计，而以前的数据以统计结果形式存储，进而避免每次查看访问统计时的重复计算。所以每一天第一次访问统计信息时速度可能会慢，这个时候应该是FB在分析 整理前一天的数据，而接下来的访问由于只针对当日数据进行分析，数据量小很多，当然也会快很多。FB的Presentation是这样写，但我发现好像我 的FB里并没有今天实时的统计，也许是我观察的不够仔细-_-!
现在第三个问题出现了，由于大多数的操作都集中在主数据库上，数据库服务器的读 写出现了冲突，前面提到过Myiasm类型的数据库在写入的时候会锁表，这样就导致了读写的冲突。在开始的时候由于读写操作比较少这个问题可能并不明显， 但现在已经到了不能忽视的程度。解决方案是平衡读写的负载，以及扩展HibernateDaoSupport，区分只读与读写操作，以实现针对读写操作的 不同处理。
。解决方案是使用内存做缓存，而非数据库，他们同样使用了我们前面推荐的memcached，同时他们还使用了Ehcache(?现 在是第四个问题：数据库全面负载过高。由于使用数据库做为缓存，同时数据库被所有的应用服务器共享，速度越来越慢，而这时数据库大小也到了Myisam的 上限-4GB，FB的同学们自己都觉得自己有点懒http://ehcache.sourceforge.net/)，一款基于Java的分布式缓存工具。
第 五个问题：流行rss源带来大量重复请求，导致系统待处理请求的堆积。同时我们注意到在RSS源小图标有时候会显示有多少用户订阅了这一RSS源，这同样 需要服务器去处理，而目前所有的订阅数都在同一时间进行计算，导致对系统资源的大量占用。解决方案，把计算时间错开，同时在晚间处理堆积下来的请求，但这 仍然不够。
问题六：状态统计写入数据库又一次出问题了。越来越多的辅助数据（包括广告统计，文章点击统计，订阅统计）需要写入数据库，导致太多的写操作。解决方案：每天晚上处理完堆积下来的请求后对子表进行截断操作：
– FLUSH TABLES; TRUNCATE TABLE ad_stats0;
这样的操作对Master数据库是成功的，但对Slave会失败，正确的截断子表方法是：
– ALTER TABLE ad_stats TYPE=MERGE UNION=(ad_stats1,ad_stats2);
– TRUNCATE TABLE ad_stats0;
– ALTER TABLE ad_stats TYPE=MERGE UNION=(ad_stats0,ad_stats1,ad_stats2);
解决方案的另外一部分就是我们最常用的水平分割数据库。把最常用的表分出去，单独做集群，例如广告啊，订阅计算啊，
第 七个问题，问题还真多，主数据库服务器的单点问题。虽然采用了Master-Slave模式，但主数据库Master和Slave都只有一台，当 Master出问题的时候需要太长的时间进行Myisam的修复，而Slave又无法很快的切换成为Master。FB试了好多办法，最终的解决方案好像 也不是非常完美。从他们的实验过程来看，并没有试验Master-Master的结构，我想Live Journal的Master-Master方案对他们来说应该有用，当然要实现Master-Master需要改应用，还有有些麻烦的。
第八个问题，停电!芝加哥地区的供电状况看来不是很好，不过不管好不好，做好备份是最重要的，大家各显神通吧。
这个Presentation好像比较偏重数据库，当然了，谁让这是在Mysql Con上的发言，不过总给人一种不过瘾的感觉。另外一个感觉，FB的NO们一直在救火，没有做系统的分析和设计。
最后FB的运维总监Joe Kottke给了四点建议：
1、 监控网站数据库负载。
2、 “explain”所有的SQL语句。
3、 缓存所有能缓存的东西。
4、 归档好代码。
最后，FB用到的软件都不是最新的，够用就好，包括：Tomcat5.0，Mysql 4.1，Hibernate 2.1，Spring，DBCP。
? YouTube 的架构扩展
flyincat 发布于：2007-07-25 09:23
作者：Fenng | English Version 【可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明】
网址：http://www.dbanotes.net/opensource/youtube_web_arch.html
在西雅图扩展性的技术研讨会上，YouTube 的 Cuong Do 做了关于 YouTube Scalability 的报告。视频内容在 Google Video 上有(地址)，可惜国内用户看不到。
Kyle Cordes 对这个视频中的内容做了介绍。里面有不少技术性的内容。值得分享一下。(Kyle Cordes 的介绍是本文的主要来源)
简 单的说 YouTube 的数据流量, "一天的YouTube流量相当于发送750亿封电子邮件.", 2006 年中就有消息说每日 PV 超过 1 亿,现在? 更夸张了,"每天有10亿次下载以及6,5000次上传", 真假姑且不论, 的确是超乎寻常的海量. 国内的互联网应用,但从数据量来看,怕是只有 51.com 有这个规模. 但技术上和 YouTube 就没法子比了.

Web 服务器

YouTube 出于开发速度的考虑，大部分代码都是 Python 开发的。Web 服务器有部分是 Apache， 用 FastCGI 模式。对于视频内容则用 Lighttpd 。据我所知，MySpace 也有部分服务器用 Lighttpd ，但量不大。YouTube 是 Lighttpd 最成功的案例。(国内用 Lighttpd 站点不多，豆瓣用的比较舒服。by Fenng)

视频

视频的缩略图(Thumbnails)给服务器带来了很大的挑战。每个视频平均有4个缩略图，而每个 Web 页面上更是有多个，每秒钟因为这个带来的磁盘 IO 请求太大。YouTube 技术人员启用了单独的服务器群组来承担这个压力，并且针对 Cache 和 OS 做了部分优化。另一方面，缩略图请求的压力导致 Lighttpd 性能下降。通过 Hack Lighttpd 增加更多的 worker 线程很大程度解决了问题。而最新的解决方案是起用了 Google 的 BigTable，这下子从性能、容错、缓存上都有更好表现。看人家这收购的，好钢用在了刀刃上。
出于冗余的考虑，每个视频文件放在一组迷你 Cluster 上，所谓 "迷你 Cluster" 就是一组具有相同内容的服务器。最火的视频放在 CDN 上，这样自己的服务器只需要承担一些"漏网"的随即访问即可。YouTube 使用简单、廉价、通用的硬件，这一点和 Google 风格倒是一致。至于维护手段，也都是常见的工具，如 rsync, SSH 等，只不过人家更手熟罢了。

数据库

YouTube 用 MySQL 存储元数据--用户信息、视频信息什么的。数据库服务器曾经一度遇到 SWAP 颠簸的问题，解决办法是删掉了 SWAP 分区! 管用。
最 初的 DB 只有 10 块硬盘，RAID 10 ，后来追加了一组 RAID 1。够省的。这一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,参见这里). 在扩展性方面，路线也是和其他站点类似，复制，分散 IO。最终的解决之道是"分区",这个不是数据库层面的表分区，而是业务层面的分区(在用户名字或者 ID 上做文章,应用程序控制查找机制)
YouTube 也用 Memcached.
很想了解一下国内 Web 2.0 网站的数据信息,有谁可以提供一点 ?
--EOF--
回复(0) |引用(0)|收藏(0)|推荐给朋友|推荐到群组|22次阅读|
标签： 系统架构
引用地址： http://www.mtime.com/blog/trackback/460579/

? 了解一下 Technorati 的后台数据库架构
作者：Fenng | English Version 【可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明】
网址：http://www.dbanotes.net/web/technorati_db_arch.html
Technorati (现在被阻尼了, 可能你访问不了)的 Dorion Carroll在 2006 MySQL 用户会议上介绍了一些关于 Technorati 后台数据库架构的情况.
基本情况
目 前处理着大约 10Tb 核心数据, 分布在大约 20 台机器上.通过复制, 多增加了 100Tb 数据, 分布在 200 台机器上. 每天增长的数据 1TB. 通过 SOA 的运用, 物理与逻辑的访问相隔离,　似乎消除了数据库的瓶颈. 值得一提的是, 该扩展过程始终是利用普通的硬件与开源软件来完成的. 毕竟 , Web 2.0 站点都不是烧钱的主. 从数据量来看，这绝对是一个相对比较大的 Web 2.0 应用.
Tag 是 Technorati 最为重要的数据元素. 爆炸性的 Tag 增长给 Technorati 带来了不小的挑战.
2005 年 1 月的时候, 只有两台数据库服务器, 一主一从. 到了 06 年一月份, 已经是一主一从, 6 台 MyISAM 从数据库用来对付查询, 3 台 MyISAM 用作异步计算.
一些核心的处理方法:
1) 根据实体(tags/posttags))进行分区
衡量数据访问方法，读和写的平衡.然后通过不同的维度进行分区．( Technorati 数据更新不会很多, 否则会成为数据库灾难)
2) 合理利用 InnoDB 与 MyISAM
InnoDB 用于数据完整性/写性能要求比较高的应用. MyISAM 适合进行 OLAP 运算. 物尽其用.
3) MySQL 复制
复制数据到从主数据库到辅数据库上,平衡分布查询与异步计算, 另外一个功能是提供冗余． 如图:

后记
拜读了一个藏袍的两篇大做(mixi.jp：使用开源软件搭建的可扩展SNS网站 / FeedBurner:基于MySQL和JAVA的可扩展Web应用) 心痒难当, 顺藤摸瓜, 发现也有文档提及 Technorati , 赶紧照样学习一下. 几篇文档读罢, MySQL 的 可扩展性让我刮目相看.
或许,应该把注意力留一点给 MySQL 了 .
--End.
? Myspace架构历程

亿万用户网站MySpace的成功秘密

◎ 文 / David F. Carr 译 / 罗小平

高速增长的访问量给社区网络的技术体系带来了巨大挑战。MySpace的开发者多年来不断重构站点软件、数据库和存储系统，以期与自身的成长同步 ——目前，该站点月访问量已达400亿。绝大多数网站需要应对的流量都不及MySpace的一小部分，但那些指望迈入庞大在线市场的人，可以从 MySpace的成长过程学到知识。

用户的烦恼
Drew，是个来自达拉斯的17岁小伙子，在他的MySpace个人资料页上，可以看到他的袒胸照，看样子是自己够着手拍的。他的好友栏全是漂亮姑娘和靓车的链接，另外还说自己参加了学校田径队，爱好吉他，开一辆蓝色福特野马。
不过在用户反映问题的论坛里，似乎他的火气很大。“赶紧弄好这该死的收件箱！”他大写了所有单词。使用MySpace的用户个人消息系统可以收发信息，但当他要查看一条消息时，页面却出现提示：“非常抱歉……消息错误”。

Drew的抱怨说明1.4亿用户非常重视在线交流系统，这对MySpace来说是个好消息。但也恰是这点让MySpace成了全世界最繁忙的站点之一。
11月，MySpace的美国国内互联网用户访问流量首次超过Yahoo。comScore Media Metrix公司提供的资料显示，MySpace当月访问量为387亿，而Yahoo是380.5亿。
显然，MySpace的成长太快了——从2003年11月正式上线到现在不过三年。这使它很早就要面对只有极少数公司才会遇到的高可扩展性问题的严峻挑战。
事实上，MySpace的Web服务器和数据库经常性超负荷，其用户频繁遭遇“意外错误”和“站点离线维护”等告示。包括Drew在内的MySpace用户经常无法收发消息、更新个人资料或处理其他日常事务，他们不得不在论坛抱怨不停。

尤其是最近，MySpace可能经常性超负荷。因为Keynote Systems公司性能监测服务机构负责人Shawn White说，“难以想象，在有些时候，我们发现20%的错误日志都来自MySpace，有时候甚至达到30%以至40%……而Yahoo、 Salesforce.com和其他提供商用服务的站点，从来不会出现这样的数字。”他告诉我们，其他大型站点的日错误率一般就1%多点。

顺便提及，MySpace在2006年7月24号晚上开始了长达12小时的瘫痪，期间只有一个可访问页面——该页面解释说位于洛杉矶的主数据中心发 生故障。为了让大家耐心等待服务恢复，该页面提供了用Flash开发的派克人（Pac-Man）游戏。Web站点跟踪服务研究公司总经理Bill Tancer说，尤其有趣的是，MySpace瘫痪期间，访问量不降反升，“这说明了人们对MySpace的痴迷——所有人都拥在它的门口等着放行”。
现Nielsen Norman Group 咨询公司负责人、原Sun Microsystems公司工程师，因在Web站点方面的评论而闻名的Jakob Nielsen说，MySpace的系统构建方法显然与Yahoo、eBay以及Google都不相同。和很多观察家一样，他相信MySpace对其成长 速度始料未及。“虽然我不认为他们必须在计算机科学领域全面创新，但他们面对的的确是一个巨大的科学难题。”他说。

MySpace开发人员已经多次重构站点软件、数据库和存储系统，以满足爆炸性的成长需要，但此工作永不会停息。“就像粉刷金门大桥，工作完成之 时，就是重新来过之日。”（译者注：意指工人从桥头开始粉刷，当到达桥尾时，桥头涂料已经剥落，必须重新开始）MySpace技术副总裁Jim Benedetto说。
既然如此，MySpace的技术还有何可学之处？因为MySpace事实上已经解决了很多系统扩展性问题，才能走到今天。

Benedetto说他的项目组有很多教训必须总结，他们仍在学习，路漫漫而修远。他们当前需要改进的工作包括实现更灵活的数据缓存系统，以及为避免再次出现类似7月瘫痪事件的地理上分布式架构。

背景知识
MySpace目前的努力方向是解决扩展性问题，但其领导人最初关注的是系统性能。
3年多前，一家叫做 Intermix Media（早先叫eUniverse。这家公司从事各类电子邮件营销和网上商务）的公司推出了MySpace。而其创建人是Chris DeWolfe和Tom Anderson，他们原来也有一家叫做ResponseBase的电子邮件营销公司，后于2002年出售给Intermix。据Brad Greenspan（Intermix前CEO）运作的一个网站披露，ResponseBase团队为此获得2百万美金外加分红。Intermix是一家 颇具侵略性的互联网商务公司——部分做法可能有点过头。2005年，纽约总检察长Eliot Spitzer——现在是纽约州长——起诉Intermix使用恶意广告软件推广业务，Intermix最后以790万美元的代价达成和解。

2003年，美国国会通过《反垃圾邮件法》（CAN-SPAM Act），意在控制滥发邮件的营销行为。Intermix领导人DeWolfe和Anderson意识到新法案将严重打击公司的电子邮件营销业务，“因此 必须寻找新的方向。”受聘于Intermix负责重写公司邮件营销软件的Duc Chau说。
当时有个叫Friendster的交友网 站，Anderson和DeWolfe很早就是它的会员。于是他们决定创建自己的网上社区。他们去除了Friendster在用户自我表述方面的诸多限 制，并重点突出音乐（尤其是重金属乐），希望以此吸引用户。Chau使用Perl开发了最初的MySpace版本，运行于Apache Web服务器，后台使用MySQL数据库。但它没有通过终审，因为Intermix的多数开发人员对ColdFusion（一个Web应用程序环境，最初 由Allaire开发，现为Adobe所有）更为熟悉。因此，最后发布的产品采用ColdFusion开发，运行在Windows上，并使用MS SQL Server作为数据库服务器。
Chau就在那时离开了公司，将开发工作交给其他人，包括Aber Whitcomb（Intermix的技术专家，现在是MySpace技术总监）和Benedetto（MySpace现技术副总裁，大概于MySpace上线一个月后加入）。

MySpace上线的2003年，恰恰是Friendster在满足日益增长的用户需求问题上遭遇麻烦的时期。在财富杂志最近的一次采访 中，Friendster总裁Kent Lindstrom承认他们的服务出现问题选错了时候。那时，Friendster传输一个页面需要20到30秒，而MySpace只需2到3秒。

结果，Friendster用户开始转投MySpace，他们认为后者更为可靠。
今天，MySpace无疑已是社区网站之王。社区网站是 指那些帮助用户彼此保持联系、通过介绍或搜索、基于共同爱好或教育经历交友的Web站点。在这个领域比较有名的还有最初面向大学生的Facebook、侧 重职业交流的LinkedIn，当然还少不了Friendster。MySpace宣称自己是“下一代门户”，强调内容的丰富多彩（如音乐、趣事和视频 等）。其运作方式颇似一个虚拟的夜总会——为未成年人在边上安排一个果汁吧，而显著位置则是以性为目的的约会，和寻找刺激派对气氛的年轻人的搜索服务。

用户注册时，需要提供个人基本信息，主要包括籍贯、性取向和婚姻状况。虽然MySpace屡遭批评，指其为网上性犯罪提供了温床，但对于未成年人，有些功能还是不予提供的。
MySpace 的个人资料页上表述自己的方式很多，如文本式“关于本人”栏、选择加载入MySpace音乐播放器的歌曲，以及视频、交友要求等。它还允许用户使用 CSS（一种Web标准格式语言，用户以此可设置页面元素的字体、颜色和页面背景图像）自由设计个人页面，这也提升了人气。不过结果是五花八门——很多用 户的页面布局粗野、颜色迷乱，进去后找不到东南西北，不忍卒读；而有些人则使用了专业设计的模版（可阅读《Too Much of a Good Thing?》第49页），页面效果很好。
在网站上线8个月后，开始有大量用户邀请朋友注册MySpace，因此用户量大增。“这就是网络的力量，这种趋势一直没有停止。”Chau说。

拥有Fox电视网络和20th Century Fox影业公司的媒体帝国——新闻集团，看到了他们在互联网用户中的机会，于是在2005年斥资5.8亿美元收购了MySpace。新闻集团董事局主席 Rupert Murdoch最近向一个投资团透露，他认为MySpace目前是世界主要Web门户之一，如果现在出售MySpace，那么可获60亿美元——这比 2005年收购价格的10倍还多！新闻集团还惊人地宣称，MySpace在2006年7月结束的财政年度里总收入约2亿美元，而且预期在2007年 度，Fox Interactive公司总收入将达到5亿美元，其中4亿来自MySpace。
然而MySpace还在继续成长。12月份，它的 注册账户达到1.4亿，而2005年11月时不过4千万。当然，这个数字并不等于真实的用户个体数，因为有些人可能有多个帐号，而且个人资料也表明有些是 乐队，或者是虚构的名字，如波拉特（译者注：喜剧电影《Borat》主角），还有像Burger King（译者注：美国最大的汉堡连锁集团）这样的品牌名。

当然，这么多的用户不停发布消息、撰写评论或者更新个人资料，甚至一些人整天都泡在Space上，必然给MySpace的技术工作带来前所未有的挑 战。而传统新闻站点的绝大多数内容都是由编辑团队整理后主动提供给用户消费，它们的内容数据库通常可以优化为只读模式，因为用户评论等引起的增加和更新操 作很少。而MySpace是由用户提供内容，数据库很大比例的操作都是插入和更新，而非读取。
浏览MySpace上的任何个人资料时，系统都必须先查询数据库，然后动态创建页面。当然，通过数据缓存，可以减轻数据库的压力，但这种方案必须解决原始数据被用户频繁更新带来的同步问题。

MySpace的站点架构已经历了5个版本——每次都是用户数达到一个里程碑后，必须做大量的调整和优化。Benedetto说，“但我们始终跟不上形势的发展速度。我们重构重构再重构，一步步挪到今天”。
尽 管MySpace拒绝了正式采访，但Benedetto在参加11月于拉斯维加斯召开的SQL Server Connections会议时还是回答了Baseline的问题。本文的不少技术信息还来源于另一次重要会议——Benedetto和他的老板——技术总 监Whitcomb今年3月出席的Microsoft MIX Web开发者大会。
据他们讲，MySpace很多大的架构变动都发生在2004和2005年早期——用户数在当时从几十万迅速攀升到了几百万。

在每个里程碑，站点负担都会超过底层系统部分组件的最大载荷，特别是数据库和存储系统。接着，功能出现问题，用户失声尖叫。最后，技术团队必须为此修订系统策略。
虽然自2005年早期，站点账户数超过7百万后，系统架构到目前为止保持了相对稳定，但MySpace仍然在为SQL Server支持的同时连接数等方面继续攻坚，Benedetto说，“我们已经尽可能把事情做到最好”。

里程碑一：50万账户
按Benedetto 的说法，MySpace最初的系统很小，只有两台Web服务器和一个数据库服务器。那时使用的是Dell双CPU、4G内存的系统。
单个数据库就意味着所有数据都存储在一个地方，再由两台Web服务器分担处理用户请求的工作量。但就像MySpace后来的几次底层系统修订时的情况一样，三服务器架构很快不堪重负。此后一个时期内，MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。
但到在2004年早期，MySpace用户数增长到50万后，数据库服务器也已开始汗流浃背。
但和Web服务器不同，增加数据库可没那么简单。如果一个站点由多个数据库支持，设计者必须考虑的是，如何在保证数据一致性的前提下，让多个数据库分担压力。
在 第二代架构中，MySpace运行在3个SQL Server数据库服务器上——一个为主，所有的新数据都向它提交，然后由它复制到其他两个；另两个全力向用户供给数据，用以在博客和个人资料栏显示。这 种方式在一段时间内效果很好——只要增加数据库服务器，加大硬盘，就可以应对用户数和访问量的增加。

里程碑二：1-2百万账户
MySpace注册数到达1百万至2百万区间后，数据库服务器开始受制于I/O容量——即它们存取数据的速度。 而当时才是2004年中，距离上次数据库系统调整不过数月。用户的提交请求被阻塞，就像千人乐迷要挤进只能容纳几百人的夜总会，站点开始遭遇“主要矛 盾”，Benedetto说，这意味着MySpace永远都会轻度落后于用户需求。
“有人花5分钟都无法完成留言，因此用户总是抱怨说网站已经完蛋了。”他补充道。
这一次的数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能，如登录、用户资料和博客。于是，站点的扩展性问题看似又可以告一段落了，可以歇一阵子。
垂 直分割策略利于多个数据库分担访问压力，当用户要求增加新功能时，MySpace将投入新的数据库予以支持它。账户到达2百万后，MySpace还从存储 设备与数据库服务器直接交互的方式切换到SAN（Storage Area Network，存储区域网络）——用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施极大提升了系统性能、正常运 行时间和可靠性，Benedetto说。

里程碑三：3百万账户
当用户继续增加到3百万后，垂直分割策略也开始难以为继。尽管站点的各个应用被设计得高度独立，但有些信息必须共 享。在这个架构里，每个数据库必须有各自的用户表副本——MySpace授权用户的电子花名册。这就意味着一个用户注册时，该条账户记录必须在9个不同数 据库上分别创建。但在个别情况下，如果其中某台数据库服务器临时不可到达，对应事务就会失败，从而造成账户非完全创建，最终导致此用户的该项服务无效。
另外一个问题是，个别应用如博客增长太快，那么专门为它服务的数据库就有巨大压力。
2004 年中，MySpace面临Web开发者称之为“向上扩展”对“向外扩展”（译者注：Scale Up和Scale Out，也称硬件扩展和软件扩展）的抉择——要么扩展到更大更强、也更昂贵的服务器上，要么部署大量相对便宜的服务器来分担数据库压力。一般来说，大型站 点倾向于向外扩展，因为这将让它们得以保留通过增加服务器以提升系统能力的后路。
但成功地向外扩展架构必须解决复杂的分布式计算问题，大型站点如Google、Yahoo和Amazon.com，都必须自行研发大量相关技术。以Google为例，它构建了自己的分布式文件系统。
另外，向外扩展策略还需要大量重写原来软件，以保证系统能在分布式服务器上运行。“搞不好，开发人员的所有工作都将白费”，Benedetto说。
因此，MySpace首先将重点放在了向上扩展上，花费了大约1个半月时间研究升级到32CPU服务器以管理更大数据库的问题。Benedetto说，“那时候，这个方案看似可能解决一切问题。”如稳定性，更棒的是对现有软件几乎没有改动要求。
糟糕的是，高端服务器极其昂贵，是购置同样处理能力和内存速度的多台服务器总和的很多倍。而且，站点架构师预测，从长期来看，即便是巨型数据库，最后也会不堪重负，Benedetto说，“换句话讲，只要增长趋势存在，我们最后无论如何都要走上向外扩展的道路。”
因 此，MySpace最终将目光移到分布式计算架构——它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来说，就不能再像过去那样将应 用拆分，再以不同数据库分别支持，而必须将整个站点看作一个应用。现在，数据库模型里只有一个用户表，支持博客、个人资料和其他核心功能的数据都存储在相 同数据库。
既然所有的核心数据逻辑上都组织到一个数据库，那么MySpace必须找到新的办法以分担负荷——显然，运行在普通硬件上的单个数据 库服务器是无能为力的。这次，不再按站点功能和应用分割数据库，MySpace开始将它的用户按每百万一组分割，然后将各组的全部数据分别存入独立的 SQL Server实例。目前，MySpace的每台数据库服务器实际运行两个SQL Server实例，也就是说每台服务器服务大约2百万用户。Benedetto指出，以后还可以按照这种模式以更小粒度划分架构，从而优化负荷分担。
当然，还是有一个特殊数据库保存了所有账户的名称和密码。用户登录后，保存了他们其他数据的数据库再接管服务。特殊数据库的用户表虽然庞大，但它只负责用户登录，功能单一，所以负荷还是比较容易控制的。

里程碑四：9百万到1千7百万账户
2005年早期，账户达到9百万后，MySpace开始用Microsoft的C#编写ASP.NET 程序。C#是C语言的最新派生语言，吸收了C++和Java的优点，依托于Microsoft .NET框架（Microsoft为软件组件化和分布式计算而设计的模型架构）。ASP.NET则由编写Web站点脚本的ASP技术演化而来，是 Microsoft目前主推的Web站点编程环境。
可以说是立竿见影，MySpace马上就发现ASP.NET程序运行更有效率，与 ColdFusion相比，完成同样任务需消耗的处理器能力更小。据技术总监Whitcomb说，新代码需要150台服务器完成的工作，如果用 ColdFusion则需要246台。Benedetto还指出，性能上升的另一个原因可能是在变换软件平台，并用新语言重写代码的过程中，程序员复审并 优化了一些功能流程。

最终，MySpace开始大规模迁移到ASP.NET。即便剩余的少部分ColdFusion代码，也从Cold-Fusion服务器搬到了 ASP.NET，因为他们得到了BlueDragon.NET（乔治亚州阿尔法利塔New Atlanta Communications公司的产品，它能将ColdFusion代码自动重新编译到Microsoft平台）的帮助。
账户达到1千万时，MySpace再次遭遇存储瓶颈问题。SAN的引入解决了早期一些性能问题，但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。
原因之一是每数据库1百万账户的分割策略，通常情况下的确可以将压力均分到各台服务器，但现实并非一成不变。比如第七台账户数据库上线后，仅仅7天就被塞满了，主要原因是佛罗里达一个乐队的歌迷疯狂注册。
某个数据库可能因为任何原因，在任何时候遭遇主要负荷，这时，SAN中绑定到该数据库的磁盘存储设备簇就可能过载。“SAN让磁盘I/O能力大幅提升了，但将它们绑定到特定数据库的做法是错误的。”Benedetto说。
最初，MySpace通过定期重新分配SAN中数据，以让其更为均衡的方法基本解决了这个问题，但这是一个人工过程，“大概需要两个人全职工作。”Benedetto说。
长期解决方案是迁移到虚拟存储体系上，这样，整个SAN被当作一个巨型存储池，不再要求每个磁盘为特定应用服务。MySpace目前采用了一种新型SAN设备——来自加利福尼亚州弗里蒙特的3PARdata。
在 3PAR的系统里，仍能在逻辑上按容量划分数据存储，但它不再被绑定到特定磁盘或磁盘簇，而是散布于大量磁盘。这就使均分数据访问负荷成为可能。当数据库 需要写入一组数据时，任何空闲磁盘都可以马上完成这项工作，而不再像以前那样阻塞在可能已经过载的磁盘阵列处。而且，因为多个磁盘都有数据副本，读取数据 时，也不会使SAN的任何组件过载。
当2005年春天账户数达到1千7百万时，MySpace又启用了新的策略以减轻存储系统压力，即增加数据 缓存层——位于Web服务器和数据库服务器之间，其唯一职能是在内存中建立被频繁请求数据对象的副本，如此一来，不访问数据库也可以向Web应用供给数 据。换句话说，100个用户请求同一份资料，以前需要查询数据库100次，而现在只需1次，其余都可从缓存数据中获得。当然如果页面变化，缓存的数据必须 从内存擦除，然后重新从数据库获取——但在此之前，数据库的压力已经大大减轻，整个站点的性能得到提升。
缓存区还为那些不需要记入数据库的数据提供了驿站，比如为跟踪用户会话而创建的临时文件——Benedetto坦言他需要在这方面补课，“我是数据库存储狂热分子，因此我总是想着将万事万物都存到数据库。”但将像会话跟踪这类的数据也存到数据库，站点将陷入泥沼。
增加缓存服务器是“一开始就应该做的事情，但我们成长太快，以致于没有时间坐下来好好研究这件事情。”Benedetto补充道。

里程碑五：2千6百万账户
2005年中期，服务账户数达到2千6百万时，MySpace切换到了还处于beta测试的SQL Server 2005。转换何太急？主流看法是2005版支持64位处理器。但Benedetto说，“这不是主要原因，尽管这也很重要；主要还是因为我们对内存的渴 求。”支持64位的数据库可以管理更多内存。
更多内存就意味着更高的性能和更大的容量。原来运行32位版本的SQL Server服务器，能同时使用的内存最多只有4G。切换到64位，就好像加粗了输水管的直径。升级到SQL Server 2005和64位Windows Server 2003后，MySpace每台服务器配备了32G内存，后于2006年再次将配置标准提升到64G。

意外错误
如果没有对系统架构的历次修改与升级，MySpace根本不可能走到今天。但是，为什么系统还经常吃撑着了？很多用户抱怨的“意外错误”是怎么引起的呢？
原 因之一是MySpace对Microsoft的Web技术的应用已经进入连Microsoft自己也才刚刚开始探索的领域。比如11月，超出SQL Server最大同时连接数，MySpace系统崩溃。Benedetto说，这类可能引发系统崩溃的情况大概三天才会出现一次，但仍然过于频繁了，以致 惹人恼怒。一旦数据库**，“无论这种情况什么时候发生，未缓存的数据都不能从SQL Server获得，那么你就必然看到一个‘意外错误’提示。”他解释说。
去年夏天，MySpace的Windows 2003多次自动停止服务。后来发现是操作系统一个内置功能惹的祸——预防分布式拒绝服务攻击（黑客使用很多客户机向服务器发起大量连接请求，以致服务器 瘫痪）。MySpace和其他很多顶级大站点一样，肯定会经常遭受攻击，但它应该从网络级而不是依靠Windows本身的功能来解决问题——否则，大量 MySpace合法用户连接时也会引起服务器反击。
“我们花了大约一个月时间寻找Windows 2003服务器自动停止的原因。”Benedetto说。最后，通过Microsoft的帮助，他们才知道该怎么通知服务器：“别开枪，是友军。”
紧 接着是在去年7月某个周日晚上，MySpace总部所在地洛杉矶停电，造成整个系统停运12小时。大型Web站点通常要在地理上分布配置多个数据中心以预 防单点故障。本来，MySpace还有其他两个数据中心以应对突发事件，但Web服务器都依赖于部署在洛杉矶的SAN。没有洛杉矶的SAN，Web服务器 除了恳求你耐心等待，不能提供任何服务。
Benedetto说，主数据中心的可靠性通过下列措施保证：可接入两张不同电网，另有后备电源和一台储备有30天燃料的发电机。但在这次事故中，不仅两张电网失效，而且在切换到备份电源的过程中，操作员烧掉了主动力线路。
2007年中，MySpace在另两个后备站点上也建设了SAN。这对分担负荷大有帮助——正常情况下，每个SAN都能负担三分之一的数据访问量。而在紧急情况下，任何一个站点都可以独立支撑整个服务，Benedetto说。
MySpace仍然在为提高稳定性奋斗，虽然很多用户表示了足够信任且能原谅偶现的错误页面。
“作 为开发人员，我憎恶Bug，它太气人了。”Dan Tanner这个31岁的德克萨斯软件工程师说，他通过MySpace重新联系到了高中和大学同学。“不过，MySpace对我们的用处很大，因此我们可 以原谅偶发的故障和错误。” Tanner说，如果站点某天出现故障甚至崩溃，恢复以后他还是会继续使用。
这就是为什么Drew在论坛里咆哮 时，大部分用户都告诉他应该保持平静，如果等几分钟，问题就会解决的原因。Drew无法平静，他写道，“我已经两次给MySpace发邮件，而它说一小时 前还是正常的，现在出了点问题……完全是一堆废话。”另一个用户回复说，“毕竟它是免费的。”Benedetto坦承100%的可靠性不是他的目标。“它 不是银行，而是一个免费的服务。”他说。
换句话说，MySpace的偶发故障可能造成某人最后更新的个人资料丢失，但并不意味着网站弄丢了用户 的钱财。“关键是要认识到，与保证站点性能相比，丢失少许数据的故障是可接受的。”Benedetto说。所以，MySpace甘冒丢失2分钟到2小时内 任意点数据的危险，在SQL Server配置里延长了“checkpoint”操作——它将待更新数据永久记录到磁盘——的间隔时间，因为这样做可以加快数据库的运行。
Benedetto 说，同样，开发人员还经常在几个小时内就完成构思、编码、测试和发布全过程。这有引入Bug的风险，但这样做可以更快实现新功能。而且，因为进行大规模真 实测试不具可行性，他们的测试通常是在仅以部分活跃用户为对象，且用户对软件新功能和改进不知就里的情况下进行的。因为事实上不可能做真实的加载测试，他 们做的测试通常都是针对站点。
“我们犯过大量错误，”Benedetto说，“但到头来，我认为我们做对的还是比做错的多。”

 

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1536222

? eBay 的数据量
作者：Fenng | English Version 【可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明】
网址：http://www.dbanotes.net/database/ebay_storage.html
作为电子商务领头羊的 eBay 公司，数据量究竟有多大? 很多朋友可能都会对这个很感兴趣。在这一篇
Web 2.0: How High-Volume eBay Manages Its Storage(从+1 GB/1 min得到的线索) 报道中，eBay 的存储主管 Paul Strong 对数据量做了一些介绍，管中窥豹，这些数据也给我们一个参考。
站点处理能力
? 平均每天的 PV 超过 10 亿 ;
? 每秒钟交易大约 1700 美元的商品 ;
? 每分钟卖出一辆车A ;
? 每秒钟卖出一件汽车饰品或者配件 ;
? 每两分钟卖出一件钻石首饰 ;
? 6 亿商品，2 亿多注册用户; 超过 130 万人把在 eBay 上做生意看作是生活的一部分。
在这样高的压力下，可靠性达到了 99.94%，也就是说每年 5 个小时多一点的服务不可用。从业界消息来看，核心业务的可用性要比这个高。
数据存储工程组控制着 eBay 的 2PB (1Petabyte=1000Terabytes) 可用空间。这是一个什么概念，对比一下 Google 的存储就知道了。每周就要分配 10T 数据出去，稍微算一下，一分钟大约使用 1G 的数据空间。
计算能力
eBay 使用一套传统的网格计算系统。该系统的一些特征数据：
? 170 台 Win2000/Win2003 服务器；
? 170 台 Linux (RHES3) 服务器；
? 三个 Solaris 服务器: 为 QA 构建与部署 eBay.com; 编译优化 Java / C++ 以及其他 Web 元素 ;
? Build 整个站点的时间：过去是 10 个小时，现在是 30 分钟;
? 在过去的2年半, 有 200 万次 Build，很可怕的数字。
存储硬件
每个供货商都必须通过严格的测试才有被选中的可能，这些厂家或产品如下：
? 交换机: Brocade
? 网管软件：IBM Tivoli
? NAS： Netapp (占总数据量的 5%，2P*0.05, 大约 100 T)
? 阵列存储：HDS (95%，这一份投资可不小，HDS 不便宜, EMC 在 eBay 是出局者) 负载均衡与 Failover: Resonate ;

搜索功能： Thunderstone indexing system ;
数据库软件：Oracle 。大多数 DB 都有 4 份拷贝。数据库使用的服务器 Sun E10000。另外据我所知, eBay 购买了 Quest SharePlex 全球 Licence 用于数据复制.
应用服务器

应用服务器有哪些特点呢?
? 使用单一的两层架构(这一点有点疑问，看来是自己写的应用服务器)
? 330 万行的 C++ ISAPI DLL (二进制文件有 150M)
? 数百名工程师进行开发
? 每个类的方法已经接近编译器的限制
非常有意思，根据eWeek 的该篇文档，昨天还有上面这段划掉的内容，今天上去发现已经修改了:
架构
? 高分布式
? 拍卖站点是基于 Java 的，搜索的架构是用 C++ 写的
? 数百名工程师进行开发，所有的工作都在同样的代码环境下进行
可能是被采访者看到 eWeek 这篇报道，联系了采访者进行了更正。我还有点奇怪原来"两层"架构的说法。
其他信息
? 集中化存储应用程序日志;
? 全局计费：实时的与第三方应用集成(就是eBay 自己的 PayPal 吧?)
? 业务事件流：使用统一的高效可靠消息队列. 并且使用 Cookie-cutter 模式用于优化用户体验(这似乎是大型电子商务站点普遍使用的用于提高用户体验的手法)。
后记
零散作了一点流水帐。作为一个 DBA, 或许有一天也有机会面对这样的数据量。到那一天，再回头看这一篇电子垃圾。
更新：更详细信息请参考：Web 2.0: How High-Volume eBay Manages Its Storage。可能处于 Cache 的问题，好几个人看到的原文内容有差异
--EOF—

? eBay 的应用服务器规模
作者：Fenng | English Version 【可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明】
网址：http://www.dbanotes.net/web/ebay_application_server.html
前面我在《eBay 的数据量》中介绍了一些道听途说来的关于互联网巨头 eBay 服务器架构的信息，不过还缺了一点关键数据。
在 Oracle 站点上的一篇题为 The eBay Global Platform and Oracle 10g JDBC 的白皮书，有能看到一些数据。
在 2004 年的时候，eBay 的应用服务器采用了 IBM WebSphere，部署在 WinNT 上，硬件是 Intel 双 CPU 奔腾服务器。服务器数量是 2400 台。在《eBay 的数据量》中我们知道，eBay 的是集中式处理 Log 的，每天会有 2T 的 Log 数据产生，现在只会更多。这些应用服务器分成不同的组，通过一个统一的 DAL(database access layer) 逻辑层访问 135 个数据库节点。
这篇白皮书已经发布了两年，相信在这两年的时间里，服务器规模又会扩大了许多。
eBay 的 SOA 架构 V3 示意图如下：

这个图来自这里
以前我写的《这些大网站都用什么操作系统与 Web 服务器 ?》，还有网友质疑 eBay 的服务器不是 WinNT，现在倒是间接证明了 Web 服务器的确是 Windows 。

? eBay 的数据库分布扩展架构
作者：Fenng | English Version 【可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明】
网址：http://www.dbanotes.net/database/ebay_database_scale_out.html
在 过去的 Blog 中, 我(插一嘴：这里的"我" 如果替换成 "Fenng" 似乎有些自恋, 也不是我喜欢的行文语气, 可发现转贴不留名的行为太多了,他大爷的)曾经介绍过 《eBay 的应用服务器规模》 , 也介绍过 《eBay 的数据量》，在这篇文章中提到过 "eBay 购买了 Quest Share Plex 全球 Licence 用于数据复制"，这个地方其实没有说开来。
对于 eBay 这样超大规模的站点来说，瓶颈往往最容易在数据库服务器上产生，必定有一部分数据(比如交易记录这样不容易水平分割的数据)容易带来大量的读操作，而不管 用什么存储，能承担的 IO 能力是有限的。所以，如果有效的分散 IO 的承载能力就是一个很有意义的事情。
经过互联网考古学不断挖掘，路路续续又现了一些蛛丝马迹能够多少说明一些问题。客观事实加上主观想象，简单的描述一下。见下图：

通过 Quest 公司的 Share Plex 近乎实时的复制数据到其他数据库节点，F5 通过特定的模块检查数据库状态，并进行负载均衡，IO 成功的做到了分布，读写分离，而且极大的提高了可用性。F5 真是一家很有创新性的公司，虽然从这个案例来说，技术并无高深之处，但方法巧妙，整个方案浑然一体。
F5公司专门为Oracle 9i 数据库开发了专用的健康检查模块，通过调用F5专有的扩展应用校验(EAV)进程，F5能够随时得到Oracle 9i数据库的应用层服务能力而不是其他的负载均衡设备所采用的 ICMP/TCP 层进行健康检查。
这个图来自一篇《F5助力eBay数据库服务器负载均衡》的软文，真是一篇很好的软文，国外恐怕不会出现这样"含金量"极高的东西。
当然，这个技术架构可不算便宜。Quest 的 Share Plex License 很贵，而且，对于每个结点来说，都需要数据库 License 与硬件费用。但优点也很多：节省了维护成本; 数据库层面的访问也能做到 SOA; 高可用性。
国内的一些厂商比较喜欢给客户推存储级别的解决方案。通过存储底层复制来解决数据分布以及灾备问题。这个思路似乎太传统了，对于互联网企业来说多少有点过时。
? 从LiveJournal后台发展看大规模网站性能优化方法
于敦德 2006-3-16
一、LiveJournal发展历程
LiveJournal是99年始于校园中的项目，几个人出于爱好做了这样一个应用，以实现以下功能：
? 博客，论坛
? 社会性网络，找到朋友
? 聚合，把朋友的文章聚合在一起
LiveJournal采用了大量的开源软件，甚至它本身也是一个开源软件。
在上线后，LiveJournal实现了非常快速的增长：
? 2004年4月份：280万注册用户。
? 2005年4月份：680万注册用户。
? 2005年8月份：790万注册用户。
? 达到了每秒钟上千次的页面请求及处理。
? 使用了大量MySQL服务器。
? 使用了大量通用组件。
二、LiveJournal架构现状概况

三、从LiveJournal发展中学习
LiveJournal从1台服务器发展到100台服务器，这其中经历了无数的伤痛，但同时也摸索出了解决这些问题的方法，通过对LiveJournal的学习，可以让我们避免LJ曾经犯过的错误，并且从一开始就对系统进行良好的设计，以避免后期的痛苦。
下面我们一步一步看LJ发展的脚步。
1、一台服务器
一 台别人捐助的服务器，LJ最初就跑在上面，就像Google开始时候用的破服务器一样，值得我们尊敬。这个阶段，LJ的人以惊人的速度熟悉的Unix的操 作管理，服务器性能出现过问题，不过还好，可以通过一些小修小改应付过去。在这个阶段里LJ把CGI升级到了FastCGI。
最终问题出现了，网站越来越慢，已经无法通过优过化来解决的地步，需要更多的服务器，这时LJ开始提供付费服务，可能是想通过这些钱来购买新的服务器，以解决当时的困境。
毫无疑问，当时LJ存在巨大的单点问题，所有的东西都在那台服务器的铁皮盒子里装着。

2、两台服务器
用付费服务赚来的钱LJ买了两台服务器：一台叫做Kenny的Dell 6U机器用于提供Web服务，一台叫做Cartman的Dell 6U服务器用于提供数据库服务。

LJ有了更大的磁盘，更多的计算资源。但同时网络结构还是非常简单，每台机器两块网卡，Cartman通过内网为Kenny提供MySQL数据库服务。

暂时解决了负载的问题，新的问题又出现了：
? 原来的一个单点变成了两个单点。
? 没有冷备份或热备份。
? 网站速度慢的问题又开始出现了，没办法，增长太快了。
? Web服务器上CPU达到上限，需要更多的Web服务器。
3、四台服务器
又买了两台，Kyle和Stan，这次都是1U的，都用于提供Web服务。目前LJ一共有3台Web服务器和一台数据库服务器。这时需要在3台Web服务器上进行负载均横。

LJ把Kenny用于外部的网关，使用mod_backhand进行负载均横。
然后问题又出现了：
? 单点故障。数据库和用于做网关的Web服务器都是单点，一旦任何一台机器出现问题将导致所有服务不可用。虽然用于做网关的Web服务器可以通过保持心跳同步迅速切换，但还是无法解决数据库的单点，LJ当时也没做这个。
? 网站又变慢了，这次是因为IO和数据库的问题，问题是怎么往应用里面添加数据库呢？
4、五台服务器
又买了一台数据库服务器。在两台数据库服务器上使用了数据库同步(Mysql支持的Master-Slave模式)，写操作全部针对主数据库（通过Binlog，主服务器上的写操作可以迅速同步到从服务器上），读操作在两个数据库上同时进行(也算是负载均横的一种吧)。

实现同步时要注意几个事项：
? 读操作数据库选择算法处理，要选一个当前负载轻一点的数据库。
? 在从数据库服务器上只能进行读操作
? 准备好应对同步过程中的延迟，处理不好可能会导致数据库同步的中断。只需要对写操作进行判断即可，读操作不存在同步问题。
5、更多服务器
有钱了，当然要多买些服务器。部署后快了没多久，又开始慢了。这次有更多的Web服务器，更多的数据库服务器，存在 IO与CPU争用。于是采用了BIG-IP作为负载均衡解决方案。

6、现在我们在哪里：

现在服务器基本上够了，但性能还是有问题，原因出在架构上。
数据库的架构是最大的问题。由于增加的数据库都是以Slave模式添加到应用内，这样唯一的好处就是将读操作分布到了多台机器，但这样带来的后果就是写操作被大量分发，每台机器都要执行，服务器越多，浪费就越大，随着写操作的增加，用于服务读操作的资源越来越少。

由一台分布到两台

最终效果
现在我们发现，我们并不需要把这些数据在如此多的服务器上都保留一份。服务器上已经做了RAID，数据库也进行了备份，这么多的备份完全是对资源的浪费，属于冗余极端过度。那为什么不把数据分布存储呢？
问题发现了，开始考虑如何解决。现在要做的就是把不同用户的数据分布到不同的服务器上进行存储，以实现数据的分布式存储，让每台机器只为相对固定的用户服务，以实现平行的架构和良好的可扩展性。
为 了实现用户分组，我们需要为每一个用户分配一个组标记，用于标记此用户的数据存放在哪一组数据库服务器中。每组数据库由一个master及几个slave 组成，并且slave的数量在2-3台，以实现系统资源的最合理分配，既保证数据读操作分布，又避免数据过度冗余以及同步操作对系统资源的过度消耗。

由一台（一组）中心服务器提供用户分组控制。所有用户的分组信息都存储在这台机器上，所有针对用户的操作需要先查询这台机器得到用户的组号，然后再到相应的数据库组中获取数据。
这样的用户架构与目前LJ的架构已经很相像了。
在具体的实现时需要注意几个问题：
? 在数据库组内不要使用自增ID，以便于以后在数据库组之间迁移用户，以实现更合理的I/O，磁盘空间及负载分布。
? 将userid，postid存储在全局服务器上，可以使用自增，数据库组中的相应值必须以全局服务器上的值为准。全局服务器上使用事务型数据库InnoDB。
? 在数据库组之间迁移用户时要万分小心，当迁移时用户不能有写操作。
7、现在我们在哪里

问题：
? 一个全局主服务器，挂掉的话所有用户注册及写操作就挂掉。
? 每个数据库组一个主服务器，挂掉的话这组用户的写操作就挂掉。
? 数据库组从服务器挂掉的话会导致其它服务器负载过大。
对于Master-Slave模式的单点问题，LJ采取了Master-Master模式来解决。所谓Master-Master实际上是人工实现的，并不是由MySQL直接提供的，实际上也就是两台机器同时是Master，也同时是Slave，互相同步。
Master-Master实现时需要注意：
? 一个Master出错后恢复同步，最好由服务器自动完成。
? 数字分配，由于同时在两台机器上写，有些ID可能会冲突。
解决方案：
? 奇偶数分配ID，一台机器上写奇数，一台机器上写偶数
? 通过全局服务器进行分配(LJ采用的做法)。
Master-Master模式还有一种用法，这种方法与前一种相比，仍然保持两台机器的同步，但只有一台机器提供服务（读和写），在每天晚上的时候进行轮换，或者出现问题的时候进行切换。
8、现在我们在哪里

现在插播一条广告，MyISAM VS InnoDB。
使用InnoDB：
? 支持事务
? 需要做更多的配置，不过值得，可以更安全的存储数据，以及得到更快的速度。
使用MyISAM：
? 记录日志（LJ用它来记网络访问日志）
? 存储只读静态数据，足够快。
? 并发性很差，无法同时读写数据（添加数据可以）
? MySQL非正常关闭或死机时会导致索引错误，需要使用myisamchk修复，而且当访问量大时出现非常频繁。
9、缓存
去年我写过一篇文章介绍memcached，它就是由LJ的团队开发的一款缓存工具，以key-value的方式将数据存储到分布的内存中。LJ缓存的数据：
? 12***立服务器（不是捐赠的）
? 28个实例
? 30GB总容量
? 90-93%的命中率（用过squid的人可能知道，squid内存加磁盘的命中率大概在70-80%）
如何建立缓存策略？
想缓存所有的东西？那是不可能的，我们只需要缓存已经或者可能导致系统瓶颈的地方，最大程度的提交系统运行效率。通过对MySQL的日志的分析我们可以找到缓存的对象。
缓存的缺点？
? 没有完美的事物，缓存也有缺点：
? 增大开发量，需要针对缓存处理编写特殊的代码。
? 管理难度增加，需要更多人参与系统维护。
? 当然大内存也需要钱。
10、Web访问负载均衡
在数据包级别使用BIG-IP，但BIG-IP并不知道我们内部的处理机制，无法判断由哪台服务器对这些请求进行处理。反向代理并不能很好的起到作用，不是已经够快了，就是达不到我们想要的效果。
所以，LJ又开发了Perlbal。特点：
? 快，小，可管理的http web 服务器/代理
? 可以在内部进行转发
? 使用Perl开发
? 单线程，异步，基于事件，使用epoll , kqueue
? 支持Console管理与http远程管理，支持动态配置加载
? 多种模式：web服务器，反向代理，插件
? 支持插件：GIF/PNG互换？
11、MogileFS
LJ使用开源的MogileFS作为分布式文件存储系统。MogileFS使用非常简单，它的主要设计思想是：
? 文件属于类（类是最小的复制单位）
? 跟踪文件存储位置
? 在不同主机上存储
? 使用MySQL集群统一存储分布信息
? 大容易廉价磁盘
到目前为止就这么多了，更多文档可以在http://www.danga.com/words/找 到。Danga.com和LiveJournal.com的同学们拿这个文档参加了两次MySQL Con，两次OS Con，以及众多的其它会议，无私的把他们的经验分享出来，值得我们学习。在web2.0时代快速开发得到大家越来越多的重视，但良好的设计仍是每一个应 用的基础，希望web2.0们在成长为Top500网站的路上，不要因为架构阻碍了网站的发展。
参考资料：http://www.danga.com/words/2005_oscon/oscon-2005.pdf
? Craigslist 的数据库架构
作者：Fenng | English Version 【可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明】
网址：http://www.dbanotes.net/database/craigslist_database_arch.html
(插播一则新闻：竞拍这本《Don’t Make Me Think》，我出价 RMB 85，留言的不算--不会有恶意竞拍的吧? 要 Ping 过去才可以，失败一次，再来)
Craigslist 绝对是互联网的一个传奇公司。根据以前的一则报道：
每月超过 1000 万人使用该站服务，月浏览量超过 30 亿次，(Craigslist每月新增的帖子近 10 亿条??)网站的网页数量在以每年近百倍的速度增长。Craigslist 至今却只有 18 名员工(现在可能会多一些了)。
Tim O'reilly 采访了 Craigslist 的 Eric Scheide ，于是通过这篇 Database War Stories #5: craigslist 我们能了解一下 Craigslist 的数据库架构以及数据量信息。
数据库软件使用 MySQL 。为充分发挥 MySQL 的能力，数据库都使用 64 位 Linux 服务器, 14 块 本地磁盘(72*14=1T ?), 16G 内存。
不同的服务使用不同方式的数据库集群。
论坛
1 主(master) 1 从(slave)。Slave 大多用于备份. myIsam 表. 索引达到 17G。最大的表接近 4200 万行。
分类信息
1 主 12 从。 Slave 各有个的用途. 当前数据包括索引有 114 G , 最大表有 5600 万行(该表数据会定期归档)。 使用 myIsam。分类信息量有多大? "Craigslist每月新增的帖子近 10 亿条"，这句话似乎似乎有些夸张，Eric Scheide 说昨日就超过 330000 条数据，如果这样估计的话，每个月的新帖子信息大约在 1 亿多一些。
归档数据库
1 主 1 从. 放置所有超过 3 个月的帖子。与分类信息库结构相似但是更大， 数据有 238G， 最大表有 9600 万行。大量使用 Merge 表，便于管理。
搜索数据库
4 个 集群用了 16 台服务器。活动的帖子根据 地区/种类划分，并使用 myIsam 全文索引，每个只包含一个子集数据。该索引方案目前还能撑住，未来几年恐怕就不成了。
Authdb
1 主 1 从，很小。
目前 Craigslist 在 Alexa 上的排名是 30，上面的数据只是反映采访当时(April 28, 2006)的情况，毕竟，Craigslist 数据量还在每年 200% 的速度增长。
Craigslist 采用的数据解决方案从软硬件上来看还是低成本的。优秀的 MySQL 数据库管理员对于 Web 2.0 项目是一个关键因素。
--EOF--
? Second Life 的数据拾零
作者：Fenng | English Version 【可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明】
网址：http://www.dbanotes.net/review/second_life.html
Matrix 似乎提前来到我们身边。从 06 年开始，陆续看到多次关于 Second Life(SL) 的报道。因为自己的笔记本跑不起来 SL 的客户端，所以一直没有能体会这个虚拟世界的魅力。今天花了一点时间，读了几篇相关的文档。
RealNetworks 前 CTO Philip Rosedale 通过 Linden 实验室创建了 Second Life，2002 年这个项目开始 Alpha 版测试，当时叫做 LindenWorld。
2007 年 2 月 24 日号称已经达到 400 万用户(用户在游戏中被称为 "Residents"，居民)。 2001 年 2 月 1 日，并发用户达到 3 万。并发用户每月的增长是 20%。这个 20%现在看起来有些保守了，随着媒体的关注，增长的会有明显的变化。系统的设计目标是 10 万并发用户，系统的复杂度不小，但 Linden 实验室对SL 的可扩展能力信心满满。
目前在旧金山与达拉斯共有 2000 多台(现在恐怕3000也不止了吧) Intel/AMD 服务器来支撑整个虚拟世界(refer here)。64 位的 AMD 服务器居多。操作系统选用的 Debian Linux， 数据库是 MySQL。通过 Tim O'relly 的这篇 Web 2.0 and Databases Part 1: Second Life ，可以了解到一点关于 SL 数据库建设的信息。在 Second Life 中每个地理区域都是运行在服务器软件单一实例上的，叫做"模拟器"或者简称是 "sim"，每个 Sim 负责 16 英亩的虚拟土地。当用户在相邻的 Sim 间移动，实际上是从一个处理器(或是服务器)移动到另一个。根据这篇访谈，用户当前所在 Sim 的信息，以及用户本身的账户信息是存储在一个中心数据库上的。

SL 的客户端软件的下载使用了 Amazon 的 S3 服务。
一点感想：MySQL 真是这波 Web 2.0 大潮中最大赢家之一啊
--EOF--
? eBay架构的思想金矿
英文来源：http://www.manageability.org/blog/stuff/about-ebays-architecture
杨争 /译

了解一件事情是怎么做的一个正确的方式是看看它在现实中是怎么做的。软件工业一直以来都在为"很多idea仅仅在理论上说说"所困惑。与此同时，软件厂商不断地把这些idea作为最佳实践推销给大家。
很 少的软件开发者亲眼目睹过大规模可扩展的架构这一领域。幸运的是，有时我们可以看到和听到关于这方面公开发表的资料。我读过一些好的资料关于google 的硬件基础设施的设计以及yahoo的页面渲染专利。现在，另一个互连网的巨人，eBay，给我们提供了其架构的一些资料（译者注：指的是"一天十亿次的 访问－采用Core J2EE Pattern架构的J2EE 系统"这篇文章）。
这篇文章提供了很多信息。然而，我们将只对那些独特的和我感兴趣的那部分进行评论。
给我留下深刻印象是eBay站点的99.92%的可用性和380M page的页面数据。除此之外，每周近3万行代码的改动，清楚明白地告诉我们ebay的java代码的高度扩展性。
eBay使用J2EE技术是如何做到这些的。eBay可扩展性的部分如下：

Judicious use of server-side state
No server affinity
Functional server pools
Horizontal and vertical database partitioning
eBay 取得数据访问的线性扩展的做法是非常让人感兴趣的。他们提到使用"定制的O-R mapping" 来支持本地Cache和全局Cache、lazy loading, fetch sets (deep and shallow)以及读取和提交更新的子集。 而且，他们只使用bean管理的事务以及使用数据库的自动提交和O-R mapping来route不同的数据源.
有几个事情是非常令人吃惊 的。第一，完全不使用Entity Beans,只使用他自己的O-R mapping工具(Hibernate anyone?)。 第二、基于Use-Case的应用服务器划分。第三、数据库的划分也是基于Use-Case。最后是系统的无状态本性以及明显不使用集群技术。
下面是关于服务器状态的引用：
基本上我们没有真正地使用server-side state。我们可能使用它，但现在我们并没有找到使用它的理由。....。如果需要状态化的话，我们把状态放到数据库中;需要的时候我们再从数据库中取。我们不必使用集群。也就不用为集群做任何工作。
总之，你自己不必为架构一台有状态的服务器所困扰，更进一步，忘掉集群，你不需要它。现在看看功能划分：

我们有一组或者一批机器，上面运行的应用是某个具体的use case，比如搜索功能有他们自己的服务器群，我们可以采用不同的调优策略，原因是浏览商品这个基本上是只读的用例和卖一件商品这个读写的用例在执行的时 候是不同。在过去四五年我们一直采用水平数据库划分达到我们需要的可用性和线性扩展性。
总之，不要把你的应用和数据库放在一个giant machine，仅仅使用servers pools，每个pools对应一个Use Case. 听起来是否类似Google的策略。
下面是关于水平划分的一些介绍：
基 于内容的路由可以实现系统的水平线性扩展。所以，想象一下，如果eBay某天拥有6000万种商品，我们不必把这些数据存储到一台超级Sun服务器 上。.....也许我们可以把这些数据库放到许多台Sun服务器,但是我们怎么取到我们需要的数据呢？eBay提出了基于内容路由的方法. 这种方法通过一定的规则，从20台物理服务器中找到我需要的数据。更cool的事情是这里还定义了failover的策略。
最后，下面一句话描述了未来采用更加松散耦合的架构：

使用消息系统来耦合不同的Use Case是我们研究的内容。
是不是觉得很奇怪，最初这篇文章是介绍J2EE设计模式的？关键的线性扩展 的思想几乎和Patterns无关。是的，eBay采用设计模式组织他们的代码。然而过分强调设计模式将失去对整体的把握。eBay架构关键的思想是无状 态的设计，使用灵活的，高度优化的 OR-mapping 层以及服务器基于use cases划分。设计模式是好的，然而不能期望它使应用具有线性扩展性。
总之，eBay和Google的例子表明以Use-Case为基础组成的服务器pools的架构比几个大型计算机证明是具有更好线性扩展性的和可用性。当然，厂商害怕听到这样的结论。然而，部署这么多服务器的最大麻烦是如何管理好他们。-)

我的总结：
eBay采用设计模式达到eBay架构的分层，各层（表示层、商业逻辑层、数据访问层）之间松散耦合，职责明确，分层提高了代码的扩展性和程序开发的效率。
eBay采用无状态的设计，灵活的、高度优化的 OR-mapping 层以及服务器基于use cases划分，达到应用之间的松散耦合，提高系统的线性扩展性。
为什么要求系统具有可线性扩展，目的就是当网站的访问量上升的时候，我们可以不用改动系统的任何代码，仅仅通过增加服务器就可以提高整个网站的支撑量。

? 一天十亿次的访问－eBay架构（一）
版权声明：如有转载请求，请注明出处：http://blog.csdn.net/yzhz
本文来自于2003JavaOne（http://java.sun.com/javaone/）上的一篇文章。我把它翻译成中文，有些不重要的部分我已略去。虽然是2003年的文章，但其中的J2EE设计方案还是值得我们去学习的，而且这个架构本身就是面向未来的。
eBay 作为全球最大的网络交易市场赢得了市场的尊重，作为技术人员我们对其后台架构如何能够支撑起这个庞然大物都会感兴趣。每天十亿次访问量，6900万注册会 员，1600万商品这些天文般的数字意味着它每天承受着巨大的并发访问量，而且eBay上大量页面都不是静态页面。
这篇介绍eBay架构的文章一定能对我们的项目设计和开发起到很好的指导作用。
eBay的架构是eBay的工程师和Sun的工程师共同设计完成的。
下面文章中斜体字是我的注释或者感想，其他的都是原文翻译。

作者：Deepak Alur、Arnold Goldberg、Raj Krishnamurthy
翻译：杨争

一天十亿次的访问
采用Core J2EE Pattern架构的J2EE 系统

详细了解Core J2EE Pattern可以查看此链接http://java.sun.com/blueprints/corej2eepatterns/Patterns/

目标：
通过本文，学习如何采用Core J2EE Patterns架构具有高度扩展性多层的J2EE应用。

作者：
Deepak Alur
- Senior Software Architect, SunPS program
- Co-author of Core J2EE Patterns
- Sun-eBay V3 Architecture—Team leader

Arnold Goldberg
- Lead Architect—eBay.com Platform
- Led V3 architecture, design and implementation

Raj Krishnamurthy
- Software Architect, SunPS program
- Sun-eBay V3 Architecture team—Key member

议程：
入门和Core J2EE Patterns
eBay.com三层架构的目标
关键架构和技术决策
eBay.com如何应用Core J2EE Patterns
结论

一、入门和Core J2EE Patterns
1、目标：
- eBay.com网站的架构
- 架构中模式的地位
- 使用 Core J2EE Patterns的好处

2、eBay介绍
（1）使命
1、全球交易平台
2、拍卖、定价、B2C、B2B

（2）统计数据
- 6900万注册会员
- 28000个分类，1600万商品
- 2002年营业额：148亿7千万美元
-全球社区
-每天十亿次访问量
- 1200多个URL

3、eBay旧的二层架构及其存在的问题
（1）ebay旧的二层架构
-集成在一起的两层架构（架构中各组件之间的耦合度高）
- 330万行C++ ISAPI DLL
-面向功能的设计
- Not for systemic qualities

（2）二层架构存在的问题
-阻碍商业创新（可扩展性不够）
-随着访问量增大，系统线性扩展性面临着挑战（无法通过仅仅增加硬件投入，扩充系统的支撑量）
-高额的维护成本
-不便于“重构”（代码很难通过重构来改善）
- Architects in constant Fire-Fighting Mode
4、2000年底开始三层架构改造

系统向分层、松散耦合、模块化、基于标准的架构过渡

一天十亿次的访问－eBay架构（二）
版权声明：如有转载请求，请注明出处：http://blog.csdn.net/yzhz

5、eBay架构的改造是基于下面这本书介绍的模式
core J2EE Pattern 最佳实践和设计策略第二版，sun官方网站也提供core J2EE Pattern，见
http://java.sun.com/blueprints/corej2eepatterns/Patterns/

该书介绍了21 种J2EE设计模式，我们可以把他们归类到三层中。
（1）、表示层的设计模式：
- Intercepting Filter (X)
- Front Controller (X)
- Application Controller (X)
- Context Object (X)
- View Helper
- Composite View
- Service To Worker (X)
- Dispatcher View
带(X)表示这些设计模式在eBay.com的架构中采用了。

（2）、商业逻辑层的设计模式:
- Business Delegate
- Service Locator (X)
- Session Facade
- Application Service (X)
- Business Object (X)
- Composite Entity
- Transfer Object (X)
- Transfer Object Assembler (X)
- Value List Handler (X)
带(X)表示这些设计模式在eBay.com的架构中采用了。

3、集成层（也称为数据访问层） 设计模式:
- Data Access Object (X)
- Service Activator
- Domain Store (X)
- Web Service Broker (X)
带(X)表示这些设计模式在eBay.com的架构中采用了。

二、ebay三层架构的目标
1、目标
高可用性、高可靠性、可线性扩展，建立实现系统的无缝增长。
高开发效率，支持新功能的快速交付。
可适应未来的架构，应变将来商业的更新需求。
ebay的系统可用性2002年已到了99.92%.(令人叹服)，每季度网站新增十五个重大功能，
每个星期将近3万行代码在修改，3个星期内可以提供一个国际化版本。

2、为了可适应未来的架构，ebay采用了下面的做法
采用J2EE模式
Only adopt Technology when required
Create new Technology as needed
大量的性能测试
大量的容量计划
大量关键点的调优
Highly redundant operational infrastructure and the technology to leverage it

3、为了实现可线性扩展，ebay采用了下面的做法：
（1） 合理地使用server state
（2） No server affinity
（3） Functional server pools。
（4） Horizontal and vertical database partitioning。

ebay架构采用了服务器分块化的概念，每台服务器上的应用与它的use case有关，即server pool中的一部分服务器专门用于登陆，一部分服务器专门用于显示商品信息。毕竟不同use case访问数据库的方式不同，比如“显示商品信息”use case只是只读操作。而且由于是只读操作，数据库的压力会比较低，我可以只采用几台服务器来承担这部分操作，而更多的服务器用于读写操作多的use case，这样合理地使用服务器资源。
由于不同的应用放在不同的服务器上，这里就涉及到用户状态的复制问题。这就是第一条ebay要求合理地使用server state的原因，就我所知，ebay的用户状态只有很少保存在session中，ebay把用户的状态放到了数据库和cookie中。

4、为了使得数据访问可线性扩展
（1） 建模我们的数据访问层
（2） 支持Support well-defined data access patterns
Relationships and traversals
本地cache和全局cache
（3） 定制的O-R mapping—域存储模式
（4） Code generation of persistent objects
（5） 支持lazy loading
（6） 支持fetch sets (shallow/deep fetches)
（7） 支持retrieval and submit (Read/Write sets)

5、为了使数据存储可线性扩展，eBay采用了下列做法
（1）商业逻辑层的事务控制
只采用Bean管理的事务
Judicious use of XA
数据库的自动提交
（2）基于内容的路由
运行期间采用 O-R Mapping ，找到正确的数据源
支持数据库的水平线性扩展
Failover hosts can be defined
（3）数据源管理
动态的
Overt and heuristic control of availability
如果数据库宕机，应用可以为其他请求服务。

6、应变未来采用的技术
（1）消息系统
子系统之间、数据库之间松散耦合
J2EE的Message Driven Beans
（2）SOAP
对于外部开发者和合作伙伴，通过可用的工具和最佳实践来平衡我们的平台
采用SOAP 来标准化不同eBay应用之间进程内部的通信
采用SOAP满足我们的QoS需求

 

四、将J2EE的设计模式应用到eBay中
介绍了三个Use cases例子，“查看账号”，“查看商品”，“eBayAPI”，介绍了这三个use case 如何采用J2EE的设计模式实现其设计。（略去）
一天十亿次的访问－eBay架构（三）
版权声明：如有转载请求，请注明出处：http://blog.csdn.net/yzhz
五、结论
1、表示层架构

 

2、商业逻辑层架构

3、eBay整体架构

4、总结
（1）eBay.com的架构采用了J2EE核心模式
-使你不用重新发明轮子，提高系统重用性
-经过实践证明的解决方案和策略
-J2EE核心模式可以成为Developer和Architect 的词汇
-更快的开发效率
（2）在你开发项目中学习和采用这些设计模式
（3）参与到模式的社区中。

5、看了这么多，如果你能记得些什么的话，希望是下面这段话：
模式在开发和设计中是非常有用的。模式能帮助你达到设计的重用、加快开发进度、降低维护成本，提高系统和代码的可理解性。
我的体会：
1、ebay架构的主体是采用J2EE的核心设计模式设计的，我们在实际项目中可根据我们应用的需求采用适合我们应用的设计模式。毕竟我们看到eBay的架构也不是用了J2EE核心设计模式中提到的所有模式，而是根据项目的实际情况采用了部分适合其本身的模式。
2、需要澄清的是：这些设计模式是J2EE的设计模式，而不是EJB的设计模式。如果你的架构没有采用EJB，你仍然可以使用这些设计模式。
3、本文中除了介绍如何采用J2EE核心模式架构eBay网站，还介绍了eBay架构为了支持线性扩展而采用的一些做法，我觉得这些做法很有特点，不仅可以大大提高系统的线性扩展性，而且也能大大提高网站的性能。这些我会有另外一篇文章介绍给大家。

? 七种缓存使用武器 为网站应用和访问加速发布时间:
Web应用中缓存的七种武器：
1 数据库的缓存
通常数据库都支持对查询结果的缓存，并且有复杂的机制保证缓存的有效性。对于MySQL,Oracle这样的数据库，通过合理配置缓存对系统性能带来的提升是相当显著的。

2 数据连接驱动的缓存。
诸如PHP的ADODB，J2EE的连接驱动，甚至如果把HIbernate等ORM也看成连接器的话。这里的缓存有效机制就不是那么强了，使用此步的方法实现缓存的一个最好的优点就是我们取数据的方式可以保持不变。例如，我调用
$db->CacheGetAll("select * from table"); 的语句不需要改变，可以透明实现缓存。这主要应用于一些变化不大的数据上，例如一些数据字典是不经常变化的。

3 系统级的缓存
可以在系统内通过Cache库，自行对需要的数据进行缓存，例如一个树桩菜单生成十分消耗资源，那可以将这个生成的树缓 存起来。这样做的缺点是，当这颗树的某些地方被更新时，你需要手动更新缓存内的东西。使用的缓存库都可以有不同的缓存方法，有的把内容放在硬盘上，有的放 在内存里面，如果你把内容模拟成硬盘来缓存，速度当然也能提升不少。
4 页面级的缓存
这个在内容管理系统里面用的最多。也就是生成静态页面。这里面缓存控制机制最为复杂，一般也没有什么包治百病的方法，只有具体情况具体分析。通常生成的静态叶面你需要有一个机制去删除过时的，或访问很少的叶面，以保证检索静态叶面的速度。
5 使用预编译叶面和加载为FastCGI的办法
对于PHP，可以使用zend等编译引擎，对于JSP本身就是预编译。而FastCGI的原理就是将脚本预先加载起来，不用每次执行都去读，这和JSP预编成Servlet，然后加载的道理是一样的。
6 前置缓存
可以使用Squid作为Web服务器的前置缓存。
7 做集群
对数据库作集群，对web服务器作集群，对Squild前置机做集群
对于新手来说，如果你的程序要是恰死，首先你要检查代码是否有错误，是否存在内存泄漏，如果都没有，那么通常问题出在数据库连接上面。
综合应用上面的缓存方法，开发高负载的Web应用成就很容易了。
? 可缓存的CMS系统设计
2007-06-03 13:41:16 作者: chedong　来源: http://www.chedong.com/ 　标签:cms cache 设计 (English)
文章转载自互联网，如果您觉得我们侵权了，请联系管理员，我们会立刻处理。
对 于一个日访问量达到百万级的网站来说，速度很快就成为一个瓶颈。除了优化内容发布系统的应用本身外，如果能把不需要实时更新的动态页面的输出结果转化成静 态网页来发布，速度上的提升效果将是显著的，因为一个动态页面的速度往往会比静态页面慢2－10倍，而静态网页的内容如果能被缓存在内存里，访问速度甚至 会比原有动态网页有2－3个数量级的提高。
? 动态缓存和静态缓存的比较
? 基于反向代理加速的站点规划
? 基于apache mod_proxy的反向代理加速实现
? 基于squid的反向代理加速实现
? 面向缓存的页面设计
? 应用的缓存兼容性设计：
HTTP_HOST/SERVER_NAME和REMOTE_ADDR/REMOTE_HOST需要用 HTTP_X_FORWARDED_HOST/HTTP_X_FORWARDED_SERVER代替
后台的内容管理系统的页面输出遵守可缓存的设计，这样就可以把性能问题交给前台的缓存服务器来解决了，从而大大简化CMS系统本身的复杂程度。
静态缓存和动态缓存的比较
静态页面的缓存可能有2种形式：其实主要区别就是CMS是否自己负责关联内容的缓存更新管理。
1. 静态缓存：是在新内容发布的同时就立刻生成相应内容的静态页面，比如：2003年3月22日，管理员通过后台内容管理界面录入一篇文章后，就立刻生成http://www.chedong.com/tech/2003/03/22/001.html这个静态页面，并同步更新相关索引页上的链接。
2. 动态缓存：是在新内容发布以后，并不预先生成相应的静态页面，直到对相应内容发出请求时，如果前台缓存服务器找不到相应缓存，就向后台内容管理服务器发出请求，后台系统会生成相应内容的静态页面，用户第一次访问页面时可能会慢一点，但是以后就是直接访问缓存了。

如果去ZDNet等国外网站会发现他们使用的基于Vignette内容管理系统都有这样的页面名称：0,22342566,300458.html。其实这里的0,22342566,300458就是用逗号分割开的多个参数：
第一次访问找不到页面后，相当于会在服务器端产生一个doc_type= 0&doc_id=22342566&doc_template=300458的查询，
而查询结果会生成的缓存的静态页面： 0,22342566,300458.html
静态缓存的缺点：
? 复杂的触发更新机制：这两种机制在内容管理系统比较简单的时候都是非常适用的。但对于一个关系比较复杂的网站来说，页面之间的逻辑引用关系就成为一个非常 非常复杂的问题。最典型的例子就是一条新闻要同时出现在新闻首页和相关的3个新闻专题中，在静态缓存模式中，每发一篇新文章，除了这篇新闻内容本身的页面 外，还需要系统通过触发器生成多个新的相关静态页面，这些相关逻辑的触发也往往就会成为内容管理系统中最复杂的部分之一。
? 旧内容的批量更新： 通过静态缓存发布的内容，对于以前生成的静态页面的内容很难修改，这样用户访问旧页面时，新的模板根本无法生效。
在动态缓存模式中，每个动态页面只需要关心，而相关的其他页面能自动更新，从而大大减少了设计相关页面更新触发器的需要。
以 前做小型应用的时候也用过类似方式：应用首次访问以后将数据库的查询结果在本地存成一个文件，下次请求时先检查本地缓存目录中是否有缓存文件，从而减少对 后台数据库的访问。虽然这样做也能承载比较大的负载，但这样的内容管理和缓存管理一体的系统是很难分离的，而且数据完整性也不是很好保存，内容更新时，应 用需要把相应内容的的缓存文件删除。但是这样的设计在缓存文件很多的时候往往还需要将缓存目录做一定的分布，否则一个目录下的文件节点超过3000，rm *都会出错。
这时候，系统需要再次分工，把复杂的内容管理系统分解成：内容输入和缓存这2个相对简单的系统实现。
? 后台：内容管理系统，专心的将内容发布做好，比如：复杂的工作流管理，复杂的模板规则等……
? 前台：页面的缓存管理则可以使用缓存系统实现
______________________ ___________________
|Squid Software cache| |F5 Hardware cache|
---------------------- -------------------
\ /
\ ________________ /
|ASP |JSP |PHP |
Content Manage System
----------------
所以分工后：内容管理和缓存管理2者，无论哪一方面可选的余地都是非常大的：软件（比如前台80端口使用SQUID对后台8080的内容发布管理系统进行缓存），缓存硬件，甚至交给akamai这样的专业服务商。
面向缓存的站点规划
一个利用SQUID对多个站点进行做WEB加速http acceleration方案：
原先一个站点的规划可能是这样的：
200.200.200.207 http://www.chedong.com/
200.200.200.208 news.chedong.com
200.200.200.209 bbs.chedong.com
200.200.200.205 images.chedong.com
面向缓存服务器的设计中：所有站点都通过外部DNS指向到同一个IP：200.200.200.200/201这2台缓存服务器上（使用2台是为了冗余备份）
_____________________ ________
http://www.chedong.com/ 请求 \ | cache box | | | / 192.168.0.4 http://www.chedong.com/
news.chedong.com 请求 -| 200.200.200.200/201 |-|firewall| - 192.168.0.4 news.chedong.com
bbs.chedong.com 请求 / | /etc/hosts | | box | \ 192.168.0.3 bbs.chedong.com
--------------------- --------
工作原理：
外部请求过来时，设置缓存根据配置文件进行转向解析。这样，服务器请求就可以转发到我们指定的内部地址上。
在处理多虚拟主机转向方面：mod_proxy比squid要简单一些：可以把不同服务转向后后台多个IP的不同端口上。
而squid只能通过禁用DNS解析，然后根据本地的/etc/hosts文件根据请求的域名进行地址转发，后台多个服务器必须使用相同的端口。
使用反向代理加速，我们不仅可以得到性能上的提升，而且还能获得额外的安全性和配置的灵活度：
? 配置灵活性提高：可以自己在内部服务器上控制后台服务器的DNS解析，当需要在服务器之间做迁移调整时，就不用大量修改外部DNS配置了，只需要修改内部DNS实现服务的调整。
? 数据安全性增加：所有后台服务器可以很方便的被保护在防火墙内。
? 后台应用设计复杂程度降低：原先为了效率常常需要建立专门的图片服务器images.chedong.com和负载比较高的应用服务器 bbs.chedong.com分离，在反向代理加速模式中，所有前台请求都通过缓存服务器：实际上就都是静态页面，这样，应用设计时就不用考虑图片和应 用本身分离了，也大大降低了后台内容发布系统设计的复杂程度，由于数据和应用都存放在一起，也方便了文件系统的维护和管理。
基于Apache mod_proxy的反向代理缓存加速实现
Apache包含了mod_proxy模块，可以用来实现代理服务器，针对后台服务器的反向加速
安装apache 1.3.x 编译时：
--enable-shared=max --enable-module=most
注：Apache 2.x中mod_proxy已经被分离成mod_proxy和mod_cache：同时mod_cache有基于文件和基于内存的不同实现
创建/var/www/proxy，设置apache服务所用户可写
mod_proxy配置样例：反相代理缓存＋缓存
架设前台的http://www.example.com/反向代理后台的http://www.backend.com/的8080端口服务。
修改：httpd.conf
<VirtualHost *>
ServerName http://www.example.com/
ServerAdmin admin@example.com
# reverse proxy setting
ProxyPass / http://www.backend.com:8080/
ProxyPassReverse / http://www.backend.com:8080/
# cache dir root
CacheRoot "/var/www/proxy"
# max cache storage
CacheSize 50000000
# hour: every 4 hour
CacheGcInterval 4
# max page expire time: hour
CacheMaxExpire 240
# Expire time = (now - last_modified) * CacheLastModifiedFactor
CacheLastModifiedFactor 0.1
# defalt expire tag: hour
CacheDefaultExpire 1
# force complete after precent of content retrived: 60-90%
CacheForceCompletion 80
CustomLog /usr/local/apache/logs/dev_access_log combined
</VirtualHost>
基于Squid的反向代理加速实现
Squid是一个更专用的代理服务器，性能和效率会比Apache的mod_proxy高很多。
如果需要combined格式日志补丁：
http://www.squid-cache.org/mail-archive/squid-dev/200301/0164.html
squid的编译：
./configure --enable-useragent-log --enable-referer-log --enable-default-err-language=Simplify_Chinese \ --enable-err-languages="Simplify_Chinese English" --disable-internal-dns
make
#make install
#cd /usr/local/squid
make dir cache
chown squid.squid *
vi /usr/local/squid/etc/squid.conf
在/etc/hosts中：加入内部的DNS解析，比如：
192.168.0.4 http://www.chedong.com/
192.168.0.4 news.chedong.com
192.168.0.3 bbs.chedong.com
---------------------cut here----------------------------------
# visible name
visible_hostname cache.example.com
# cache config: space use 1G and memory use 256M
cache_dir ufs /usr/local/squid/cache 1024 16 256
cache_mem 256 MB
cache_effective_user squid
cache_effective_group squid

http_port 80
httpd_accel_host virtual
httpd_accel_single_host off
httpd_accel_port 80
httpd_accel_uses_host_header on
httpd_accel_with_proxy on
# accelerater my domain only
acl acceleratedHostA dstdomain .example1.com
acl acceleratedHostB dstdomain .example2.com
acl acceleratedHostC dstdomain .example3.com
# accelerater http protocol on port 80
acl acceleratedProtocol protocol HTTP
acl acceleratedPort port 80
# access arc
acl all src 0.0.0.0/0.0.0.0
# Allow requests when they are to the accelerated machine AND to the
# right port with right protocol
http_access allow acceleratedProtocol acceleratedPort acceleratedHostA
http_access allow acceleratedProtocol acceleratedPort acceleratedHostB
http_access allow acceleratedProtocol acceleratedPort acceleratedHostC
# logging
emulate_httpd_log on
cache_store_log none
# manager
acl manager proto cache_object
http_access allow manager all
cachemgr_passwd pass all

----------------------cut here---------------------------------
创建缓存目录：
/usr/local/squid/sbin/squid -z
启动squid
/usr/local/squid/sbin/squid
停止squid：
/usr/local/squid/sbin/squid -k shutdown
启用新配置：
/usr/local/squid/sbin/squid -k reconfig
通过crontab每天0点截断/轮循日志：
0 0 * * * (/usr/local/squid/sbin/squid -k rotate)
可缓存的动态页面设计
什么样的页面能够比较好的被缓存服务器缓存呢？如果返回内容的HTTP HEADER中有"Last-Modified"和"Expires"相关声明，比如：
Last-Modified: Wed, 14 May 2003 13:06:17 GMT
Expires: Fri, 16 Jun 2003 13:06:17 GMT
前端缓存服务器在期间会将生成的页面缓存在本地：硬盘或者内存中，直至上述页面过期。
因此，一个可缓存的页面：
? 页面必须包含Last-Modified: 标记
一般纯静态页面本身都会有Last-Modified信息，动态页面需要通过函数强制加上，比如在PHP中：
// always modified now
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
? 必须有Expires或Cache-Control: max-age标记设置页面的过期时间：
对于静态页面，通过apache的mod_expires根据页面的MIME类型设置缓存周期：比如图片缺省是1个月，HTML页面缺省是2天等。
<IfModule mod_expires.c>
ExpiresActive on
ExpiresByType image/gif "access plus 1 month"
ExpiresByType text/css "now plus 2 day"
ExpiresDefault "now plus 1 day"
</IfModule>

对于动态页面，则可以直接通过写入HTTP返回的头信息，比如对于新闻首页index.php可以是20分钟，而对于具体的一条新闻页面可能是1天后过期。比如：在php中加入了1个月后过期：
// Expires one month later
header("Expires: " .gmdate ("D, d M Y H:i:s", time() + 3600 * 24 * 30). " GMT");
? 如果服务器端有基于HTTP的认证，必须有Cache-Control: public标记，允许前台
ASP应用的缓存改造 首先在公用的包含文件中(比如include.asp)加入以下公用函数：
<%
' Set Expires Header in minutes
Function SetExpiresHeader(ByVal minutes)
' set Page Last-Modified Header:
' Converts date (19991022 11:08:38) to http form (Fri, 22 Oct 1999 12:08:38 GMT)
Response.AddHeader "Last-Modified", DateToHTTPDate(Now())

' The Page Expires in Minutes
Response.Expires = minutes

' Set cache control to externel applications
Response.CacheControl = "public"
End Function
' Converts date (19991022 11:08:38) to http form (Fri, 22 Oct 1999 12:08:38 GMT)
Function DateToHTTPDate(ByVal OleDATE)
Const GMTdiff = #08:00:00#
OleDATE = OleDATE - GMTdiff
DateToHTTPDate = engWeekDayName(OleDATE) & _
", " & Right("0" & Day(OleDATE),2) & " " & engMonthName(OleDATE) & _
" " & Year(OleDATE) & " " & Right("0" & Hour(OleDATE),2) & _
":" & Right("0" & Minute(OleDATE),2) & ":" & Right("0" & Second(OleDATE),2) & " GMT"
End Function
Function engWeekDayName(dt)
Dim Out
Select Case WeekDay(dt,1)
Case 1:Out="Sun"
Case 2:Out="Mon"
Case 3:Out="Tue"
Case 4:Out="Wed"
Case 5:Out="Thu"
Case 6:Out="Fri"
Case 7:Out="Sat"
End Select
engWeekDayName = Out
End Function
Function engMonthName(dt)
Dim Out
Select Case Month(dt)
Case 1:Out="Jan"
Case 2:Out="Feb"
Case 3:Out="Mar"
Case 4:Out="Apr"
Case 5:Out="May"
Case 6:Out="Jun"
Case 7:Out="Jul"
Case 8:Out="Aug"
Case 9:Out="Sep"
Case 10:Out="Oct"
Case 11:Out="Nov"
Case 12:Out="Dec"
End Select
engMonthName = Out
End Function
%>
然后在具体的页面中，比如index.asp和news.asp的“最上面”加入以下代码：HTTP Header
<!--#include file="../include.asp"-->
<%
'页面将被设置20分钟后过期
SetExpiresHeader(20)
%>
应用的缓存兼容性设计

经过代理以后，由于在客户端和服务之间增加了中间层，因此服务器无法直接拿到客户端的IP，服务器端应用也无法直接通过转发请求的地址返回给客户 端。但是在转发请求的HTTD头信息中，增加了HTTP_X_FORWARDED_????信息。用以跟踪原有的客户端IP地址和原来客户端请求的服务器 地址：
下面是2个例子，用于说明缓存兼容性应用的设计原则：
'对于一个需要服务器名的地址的ASP应用：不要直接引用HTTP_HOST/SERVER_NAME，判断一下是否有HTTP_X_FORWARDED_SERVER
function getHostName ()
dim hostName as String = ""
hostName = Request.ServerVariables("HTTP_HOST")
if not isDBNull(Request.ServerVariables("HTTP_X_FORWARDED_HOST")) then
if len(trim(Request.ServerVariables("HTTP_X_FORWARDED_HOST"))) > 0 then
hostName = Request.ServerVariables("HTTP_X_FORWARDED_HOST")
end if
end if
return hostNmae
end function

//对于一个需要记录客户端IP的PHP应用：不要直接引用REMOTE_ADDR，而是要使用HTTP_X_FORWARDED_FOR，
function getUserIP (){
$user_ip = $_SERVER["REMOTE_ADDR"];
if ($_SERVER["HTTP_X_FORWARDED_FOR"]) {
$user_ip = $_SERVER["HTTP_X_FORWARDED_FOR"];
}
}

注意：HTTP_X_FORWARDED_FOR如果经过了多个中间代理服务器，有何能是逗号分割的多个地址，
比如：200.28.7.155,200.10.225.77 unknown,219.101.137.3
因此在很多旧的数据库设计中（比如BBS）往往用来记录客户端地址的字段被设置成20个字节就显得过小了。
经常见到类似以下的错误信息：
Microsoft JET Database Engine 错误 '80040e57'
字段太小而不能接受所要添加的数据的数量。试着插入或粘贴较少的数据。
/inc/char.asp，行236
原因就是在设计客户端访问地址时，相关用户IP字段大小最好要设计到50个字节以上，当然经过3层以上代理的几率也非常小。
如何检查目前站点页面的可缓存性（Cacheablility）呢？可以参考以下2个站点上的工具：
http://www.ircache.net/cgi-bin/cacheability.py
附：SQUID性能测试试验

phpMan.php是一个基于php的man page server，每个man
page需要调用后台的man命令和很多页面格式化工具，系统负载比较高，提供了Cache
Friendly的URL，以下是针对同样的页面的性能测试资料：
测试环境：Redhat 8 on Cyrix 266 / 192M Mem
测试程序：使用apache的ab(apache benchmark)：
测试条件：请求50次，并发50个连接
测试项目：直接通过apache 1.3 (80端口) vs squid 2.5(8000端口：加速80端口)

测试1：无CACHE的80端口动态输出：
ab -n 100 -c 10 http://www.chedong.com:81/phpMan.php/man/kill/1
This is ApacheBench, Version 1.3d <$Revision: 1.2 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2001 The Apache Group, http://www.apache.org/

Benchmarking localhost (be patient).....done
Server Software:
Apache/1.3.23
Server Hostname: localhost
Server
Port:
80

Document Path:
/phpMan.php/man/kill/1
Document Length: 4655 bytes

Concurrency Level: 5
Time taken for tests: 63.164 seconds
Complete requests: 50
Failed requests: 0
Broken pipe errors: 0
Total transferred: 245900 bytes
HTML transferred: 232750 bytes
Requests per second: 0.79 [#/sec] (mean)
Time per request: 6316.40 [ms]
(mean)
Time per request: 1263.28 [ms]
(mean, across all concurrent requests)
Transfer rate:
3.89 [Kbytes/sec] received

Connnection Times (ms)

min mean[+/-sd] median max
Connect: 0
29 106.1 0 553
Processing: 2942 6016
1845.4 6227 10796

Waiting:
2941 5999 1850.7 6226 10795

Total:
2942 6045 1825.9 6227 10796

Percentage of the requests served within a certain time (ms)
50% 6227
66% 7069
75% 7190
80% 7474
90% 8195
95% 8898
98% 9721
99% 10796
100% 10796 (last request)

测试2：SQUID缓存输出
/home/apache/bin/ab -n50 -c5
"http://localhost:8000/phpMan.php/man/kill/1"
This is ApacheBench, Version 1.3d <$Revision: 1.2 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/
Copyright (c) 1998-2001 The Apache Group, http://www.apache.org/

Benchmarking localhost (be patient).....done
Server Software:
Apache/1.3.23
Server Hostname: localhost
Server
Port:
8000

Document Path:
/phpMan.php/man/kill/1
Document Length: 4655 bytes

Concurrency Level: 5
Time taken for tests: 4.265 seconds
Complete requests: 50
Failed requests: 0
Broken pipe errors: 0
Total transferred: 248043 bytes
HTML transferred: 232750 bytes
Requests per second: 11.72 [#/sec] (mean)
Time per request: 426.50 [ms] (mean)
Time per request: 85.30 [ms] (mean,
across all concurrent requests)
Transfer rate:
58.16 [Kbytes/sec] received

Connnection Times (ms)

min mean[+/-sd] median max
Connect:
0 1
9.5 0 68
Processing:
7 83 537.4
7 3808

Waiting:
5 81 529.1
6 3748

Total:
7 84 547.0
7 3876

Percentage of the requests served within a certain time (ms)
50% 7
66% 7
75% 7
80% 7
90% 7
95% 7
98% 8
99% 3876
100% 3876 (last request)

结论：No Cache / Cache = 6045 / 84 = 70
结论：对于可能被缓存请求的页面，服务器速度可以有2个数量级的提高，因为SQUID是把缓存页面放在内存里的（因此几乎没有硬盘I/O操作）。

小节：

? 大访问量的网站应尽可能将动态网页生成静态页面作为缓存发布，甚至对于搜索引擎这样的动态应用来说，缓存机制也是非常非常重要的。
? 在动态页面中利用HTTP Header定义缓存更新策略。
? 利用缓存服务器获得额外的配置和安全性
? 日志非常重要：SQUID日志缺省不支持COMBINED日志，但对于需要REFERER日志的这个补丁非常重要：http://www.squid-cache.org/mail-archive/squid-dev/200301/0164.html

参考资料：
HTTP代理缓存
http://vancouver-webpages.com/proxy.html

可缓存的页面设计
http://linux.oreillynet.com/pub/a/linux/2002/02/28/cachefriendly.html
运用ASP.NET的输出缓冲来存储动态页面 - 开发者 - ZDNet China
http://www.zdnet.com.cn/developer/tech/story/0,2000081602,39110239-2,00.htm
相关RFC文档：

? RFC
2616:

o section
13 (Caching)
o section
14.9 (Cache-Control header)
o section
14.21 (Expires header)
o section
14.32 (Pragma: no-cache) is important if you are interacting with
HTTP/1.0 caches
o section
14.29 (Last-Modified) is the most common validation method
o section
3.11 (Entity Tags) covers the extra validation method

可缓存性检查
http://www.web-caching.com/cacheability.html
缓存设计要素
http://vancouver-webpages.com/CacheNow/detail.html

ZOPE上的几篇使用APACHE MOD_PROXY MOD_GZIP加速的文档
http://www.zope.org/Members/anser/apache_zserver/
http://www.zope.org/Members/softsign/ZServer_and_Apache_mod_gzip
http://www.zope.org/Members/rbeer/caching
? 开发大型高负载类网站应用的几个要点[nightsailer]
大 | 中 | 小
2007/05/17 14:12 772 huzhangyou2002 信仰的服务器设计
作者：nightsailer
来源：http://www.phpchina.com/bbs/thread-15484-1-1.html

看了一些人的所谓大型项目的方法,我感觉都是没有说到点子上，有点难受。
我也说说自己的看法.我个人认为,很难衡量所谓项目是否大型,
即便很简单的应用在高负载和高增长情况下都是一个挑战.因此,按照我的想法,姑且说是高负载
高并发或者高增长情况下,需要考虑的问题.这些问题,很多是和程序开发无关,而是和整个系统的
架构密切相关的.

数据库

没错,首先是数据库,这是大多数应用所面临的首个SPOF。尤其是Web2.0的应用，数据库的响应是首先要解决的。
一般来说MySQL是最常用的，可能最初是一个mysql主机，当数据增加到100万以上，
那么，MySQL的效能急剧下降。常用的优化措施是M-S（主-从）方式进行同步复制，将查询和操作和分别在不同的
服务器上进行操作。我推荐的是M-M-Slaves方式，2个主Mysql，多个Slaves，需要注意的是，虽然有2个Master，
但是同时只有1个是Active，我们可以在一定时候切换。之所以用2个M，是保证M不会又成为系统的SPOF。
Slaves可以进一步负载均衡，可以结合LVS,从而将select操作适当的平衡到不同的slaves上。

以上架构可以抗衡到一定量的负载，但是随着用户进一步增加，你的用户表数据超过1千万，这时那个M变成了
SPOF。你不能任意扩充Slaves，否则复制同步的开销将直线上升，怎么办？我的方法是表分区，
从业务层面上进行分区。最简单的，以用户数据为例。根据一定的切分方式，比如id，切分到不同的数据库集群去。
全局数据库用于meta数据的查询。缺点是每次查询，会增加一次，比如你要查一个用户nightsailer,你首先要到全局数据库群找到nightsailer对应的cluster id，然后再到指定的cluster找到nightsailer的实际数据。
每个cluster可以用m-m方式，或者m-m-slaves方式。
这是一个可以扩展的结构，随着负载的增加，你可以简单的增加新的mysql cluster进去。

需要注意的是：
1、禁用全部auto_increment的字段
2、id需要采用通用的算法集中分配
3、要具有比较好的方法来监控mysql主机的负载和服务的运行状态。如果你有30台以上的mysql数据库在跑就明白我的意思了。
4、不要使用持久性链接（不要用pconnect）,相反，使用sqlrelay这种第三方的数据库链接池，或者干脆自己做，因为php4中mysql的
链接池经常出问题。

缓存

缓存是另一个大问题，我一般用memcached来做缓存集群，一般来说部署10台左右就差不多（10g内存池）。需要注意一点，千万不能用使用swap，最好关闭linux的swap。

负载均衡/加速

可能上面说缓存的时候，有人第一想的是页面静态化，所谓的静态html，我认为这是常识，不属于要点了。页面的静态化随之带来的是静态服务的
负载均衡和加速。我认为Lighttped+Squid是最好的方式了。
LVS <------->lighttped====>squid(s) ====lighttpd

上面是我经常用的。注意，我没有用apache，除非特定的需求，否则我不部署apache，因为我一般用php-fastcgi配合lighttpd,
性能比apache+mod_php要强很多。

squid的使用可以解决文件的同步等等问题，但是需要注意，你要很好的监控缓存的命中率，尽可能的提高的90%以上。
squid和lighttped也有很多的话题要讨论，这里不赘述。
存储
存储也是一个大问题，一种是小文件的存储，比如图片这类。另一种是大文件的存储，比如搜索引擎的索引，一般单文件都超过2g以上。小文件的存储最简单的方法是结合lighttpd来进行分布。或者干脆使用Redhat的GFS，优点是应用透明，缺点是费用较高。我是指
你购买盘阵的问题。我的项目中，存储量是2-10Tb，我采用了分布式存储。这里要解决文件的复制和冗余。
这样每个文件有不同的冗余，这方面可以参考google的gfs的论文。
大文件的存储，可以参考nutch的方案，现在已经独立为hadoop子项目。(你可以google it)

其他：
此外，passport等也是考虑的，不过都属于比较简单的了。

吃饭了，不写了，抛砖引玉而已。

【回复】

9tmd :
说了关键的几个部分，还有一些比如squid群、LVS或者VIP（四层交换）之类的必须考虑，数据库逻辑分表不需要master里面查id，可以定期缓存或者程序逻辑上进行控制。
跟大家分享一下我的经验： http://www.toplee.com/blog/archives/337.html （欢迎讨论）
nightsailer：
楼上说的很好.
我 再说一下关于为何要在主表查询，最主要的因素是考虑到复制和维护的问题。假设按照程序逻辑，用户nightsailer应该在s1集群，但是由于种种原 因，我须要将nightsailer的数据从s1集群转移到s5集群或者某些时候，我需要将某几个集群的数据合并，此时，我维护的时候只需要更新一下主数 据库中nightsailer的cluster id从1变成5,，维护的工作可以独立进行，无需考虑更新应用程序的逻辑。也许程序的id分配逻辑可以考虑到这种情况，但是这样一来，你的这个逻辑会发散 到各个应用中，产生的代码的耦合是很高的。相反，采用查表这种方式，只需要在最初的时候进行初始分配，那么其他的应用是无需考虑这些算法和逻辑的。
当然，我最初提到的增加这次查询并不是说每次查询都需要找主数据库，缓存策略是必定要考虑的。

至于说为什么要禁用auto_increment,我想也清楚了，数据的合并和分隔，肯定是不能用auto_increment的。
nightsailer：
在闲扯一下，PHP的优化可以有很多，主要的措施：
1、使用FCGI方式，配合lighttpd,Zeus.
我个人比较喜欢Zeus，简单可靠。不过，需要￥￥￥。
lighty也不错，配置文件也很简单，比较清爽。最新的1.5,虽然不稳定，但是配合linux的aio,性能的提升
非常明显。即便现在的稳定版，使用2.6的epoll可以得到的性能是非常高。当然，lighty比zeus缺点是对于smp
的支持很有限，所以可以采用多服务器负载,或者干脆起不同的进程服务监听不同的端口。
2、专门的PHP FCGI服务器。
好处多多，在这个服务器上，就跑php的fcgi服务，你可以把一些缓存加上，比如xcache，我个人喜欢这个。
还有别的，套用大腕的话，把能装的都装上，呵呵。
另外，最主要的是，你可以只维护一个php的环境，这个环境能够被apache,zeus,lighttpd同时share，
前提是这些都使用php的fcgi模式，而且，xcache可以充分发挥！
3、apache+mod_fastcgi
apache并非无用，有时候也需要。比如我用php做了一个web_dav的服务器，在其他有问题，只能跑apache.
那么，apache安装一下mod_fastcgi，通过使用externl server，使用2配置的php fastcgi。
4、优化编译
ICC是我的首选，就是intel的编译器啦，用icc重新编译php,mysql,lighty,能编的都编，会有不小的收获的。尤其是你用
intel的cpu的话。
5、php4的64位需要patch
好像没有人在linux x86_64上编译过php4吧，我曾经googleit
,别说国内了，连老外都很少用。
这里就做个提醒把，如果用php官方下载的(包括最新的php-4.4.4)，统统无法编译通过。问题是出在autoconf上，需要
手工修改config.m4，一般是在mysql,gd,ldap等一些关键的extension上，还有phpize的脚本。把/usr/lib64加入到
config.m4中相关搜索的path中。
不过我估计很少人像我这样死用php4不防，呵呵。php5就没有问题。
我也考虑正在迁移到php5.2，写代码太方便了，一直忍着呢。
nightsailer：
QUOTE:
原帖由 wuexp 于 2007-1-3 17:01 发表
分表会使操作数据(更改,删除,查询)边的很复杂,特别是遇到排序的时候就更麻烦了.
曾经考虑根据用户id哈希一下,插入到相应的分表里

明白你的意思。

不过我们可能讨论的不完全一样，呵呵。
我所说的分表要依据不同的业务情况来划分的，

1、可以是垂直划分，
比如依据业务实体切分，比如用户a的blog贴子，用户的tag，用户的评论都在a数据库u，甚者是完整的一套数据结构(这种情况下应该说是分数据库）

2、也可以水平划分，
一个表的数据分在不同的数据库上。
比如message表，你可能分为daily_message,history_message，
dialy_meesage可能是hot对象，week_message是warm，2个月以前的帖子
可能属于cold对象了。这些对象依据访问频度不同会划分到不同的数据库群上。

3、二者结合

不过，不论如何，更改、删除并不复杂，和未分区的表没有区别。

至于查询和排序，不可能仅仅是通过select，order吧？
而是应该产生类似摘要表，索引表，参考表。。。
另外，要根据业务具体分析减少垃圾数据，有些时候，只需要最初的1万条记录，那么所有表
数据的排序就不需要了。很多传统的业务，比如零售，流水表很大，但是报表的数据
并非实时生成的，扎报表应该不陌生。

也可以参考很多网站的做法，比如technorati啊,flickr之类的。

所谓的麻烦是你设计系统的结构的时候要考虑到，在设计数据库的时候更要注意，
因此只要项目的framework最初设计比较完备，那么可以说大部分对开发人员是透明的。
前提是，你一定要设计好，而不是让程序员边写代码边设计，那会是噩梦。

我写这么多废话，并非仅仅是对程序员来说，也许对设计者更有用。

9tmd ：
程序逻辑上控制表拆分只需要维护一个数据库访问的配置文件即可，对于开发来说，完全透明，可以不用关心访问的是哪里，而只需要调用通用的接口即可，曾经做过的系统里面，这样的应用经常遇到，尤其在全网passport、社区帖子等方面的处理上应用最多。

原来在yahoo工作和后来mop工作都使用了这样的架构，整体感觉来说还是值得信赖的，单表毕竟存在面对极限数据量的风险。

9tmd ：
前面老是有人问auto_increment的问题，其实这是MySQL官方专门针对M/S的 Replication做过的说明，因为MySQL的同步是依靠同步MySQL的SQL日志来实现的，事实上单向的Master->Slave使用 auto_increment是没有问题的，而双向的M/M模式就会存在问题了，稍微一思考就知道怎么回事了。官方文档：
http://dev.mysql.com/tech-resour ... ql-replication.html
http://dev.mysql.com/doc/refman/ ... auto-increment.html

另外，在使用MySQL的同步时，需要注意在自己的代码里面，写SQL的时候不要使用MySQL自己提供的类似 NOW()之类的函数，而应该使用php程序里面计算的时间带入SQL语句里面，否则同步的时候也可能导致值不相等，这个道理可以牵涉出另外一些类似的问 题，大家可以考虑一下。

 

参考文章：
http://blog.csdn.net/heiyeshuwu/archive/2007/01/04/1473941.aspx
http://www.phpchina.com/bbs/thread-15484-1-1.html
http://www.toplee.com/blog/archives/337.html
? Memcached和Lucene笔记
By Michael
　 　前段时间完成的项目使用了大量的Memcached，整个架构在性能上的确提高了很多，的确不是一点点的提高，面向大负载访问的时候，MySQL数据库 仍然可以做到轻量级的负载，效果不错，建议有条件的朋友一定要把项目改造到Memcached上，著名的Vbb论坛当前的版本就已经开始支持使用 Memcached进行论坛数据缓存。我原来在MOP的时候，我们也大量的采用这个东西。
　　在使用Memcached方面，谈不上什么经验，反正极端的性能最大化就是使用永久的缓存，通过你的程序逻辑去控制和维护MC里面的缓存数据，我做的项目就是这样处理的，程序的逻辑的确增加了复杂度，但是对于商业项目来说，这种付出是非常值得的。
　 　Memcached唯一可能需要注意的是，他对key的操作不是原子级别的，所以在高并发处理的时候，对同一个key的写操作可能会导致覆盖，这个需要 自己从程序逻辑上进行处理，这个理论我并没有深入研究，不过JH看了源代码给了我这样的结论，按照JH的实力和人品，我认为有80％以上的可信度:)
　 　对于Lucene，大部分人都不陌生，相关的技术也不用太多讲解，网上到处都是相关的文档。我最近想通过PHP来找到一个最佳的整合Lucene的方 法，并且应用到正规的商业应用中，目前知道的可选方案是Pecl的Clucene模块和Zend Framework的 Zend_Search_Lucene 模块，这两个东西目前我使用的感觉都不算太好，另外还有一种是使用 PHP的 Java扩展支持（有两种，一种是php_java扩展，一种是php_java的 bradge方式），这个感觉也比较怪异，最后还有一种知道的办法就是使用系统调用 java 命令执行Lucene功能。 这个没有试过，不知性能可以达到什么程度。
在这里做个记号，等有了进一步的收获补进来。
? 使用开源软件，设计高性能可扩展网站
2006-6-17 于敦德
上次我们以LiveJournal为例详细分析了一个小网站在一步一步的发展成为大规模的网站中性能优化的方案，以解决在发展中由于负载增长而引起的性能问题，同时在设计网站架构的时候就从根本上避免或者解决这些问题。
今天我们来看一下在网站的设计上一些通常使用的解决大规模访问，高负载的方法。我们将主要涉及到以下几方面：
1、 前端负载
2、 业务逻辑层
3、 数据层
在 LJ性能优化文章中我们提到对服务器分组是解决负载问题，实现无限扩展的解决方案。通常中我们会采用类似LDAP的方案来解决，这在邮件的服务器以及个人 网站，博客的应用中都有使用，在Windows下面有类似的Active Directory解决方案。有的应用（例如博客或者个人网页）会要求在二级域名解析的时候就将用户定位到所属的服务器群组，这个时候请求还没到应用上 面，我们需要在DNS里解决这个问题。这个时候可以用到一款软件bind dlz，这是bind的一个插件，用于取代bind的文本解析配置文件。它支持包括LDAP，BDB在内的多种数据存储方式，可以比较好的解决这个问题。
另外一种涉及到DNS的问题就是目前普遍存在的南北互联互通的问题，通过bind9内置的视图功能可以根据不同的IP来源解析出不同的结果，从 而将南方的用户解析到南方的服务器，北方的用户解析到北方的服务器。这个过程中会碰到两个问题，一是取得南北IP的分布列表，二是保证南北服务器之间的通 讯顺畅。第一个问题有个笨办法解决，从日志里取出所有的访问者IP，写一个脚本，从南北的服务器分别ping回去，然后分析结果，可以得到一个大致准确的 列表，当然最好的办法还是直到从运营商那里拿到这份列表。后一个问题解决办法比较多，最好的办法就是租用双线机房，同一台机器，双IP，南北同时接入，差 一些的办法就是南北各自找机房，通过大量的测试找出中间通讯顺畅的两个机房，后一种通常来说成本较低，但效果较差，维护不便。
另外DNS负载均衡也是广泛使用的一种负载均衡方法，通过并列的多条A记录将访问随即的分布到多台前端服务器上，这种通常使用在静态页面居多的应用上，几大门户内容部分的前端很多都是用的这种方法。
用户被定位到正确的服务器群组后，应用程序就接手用户的请求，并开始沿着定义好的业务逻辑进行处理。这些请求主要包括两类静态文件(图片，js脚本,css等)，动态请求。
静 态请求一般使用squid进行缓存处理，可以根据应用的规模采用不同的缓存配置方案，可以是一级缓存，也可以是多级缓存，一般情况下cache的命中率可 以达到70%左右，能够比较有效的提升服务器处理能力。Apache的deflate模块可以压缩传输数据，提高速度，2.0版本以后的cache模块也 内置实现磁盘和内存的缓存，而不必要一定做反向代理。
动态请求目前一般有两种处理方式，一种是静态化，在页面发生变化时重新静态页面，现在大量的CMS，BBS都采用这种方案，加上cache，可以提供较快的访问速度。这种通常是写操作较少的应用比较适合的解决方案。
另 一种解决办法是动态缓存，所有的访问都仍然通过应用处理，只是应用处理的时候会更多的使用内存，而不是数据库。通常访问数据库的操作是极慢的，而访问内存 的操作很快，至少是一个数量级的差距，使用memcached可以实现这一解决方案，做的好的memcache甚至可以达到90%以上的缓存命中率。10 年前我用的还是2M的内存，那时的一本杂事上曾经风趣的描述一对父子的对话：
儿子：爸爸，我想要1G的内存。
爸爸：儿子，不行，即使是你过生日也不行。
时 至今日，大内存的成本已经完全可以承受。Google使用了大量的PC机建立集群用于数据处理，而我一直觉得，使用大内存PC可以很低成本的解决前端甚至 中间的负载问题。由于PC硬盘寿命比较短，速度比较慢，CPU也稍慢，用于做web前端既便宜，又能充分发挥大内存的优势，而且坏了的话只需要替换即可， 不存在数据的迁移问题。
下面就是应用的设计。应用在设计的时候应当尽量的设计成支持可扩展的数据库设计，数据库可以动态的添加，同时支持内存缓 存，这样的成本是最低的。另外一种应用设计的方法是采用中间件，例如ICE。这种方案的优点是前端应用可以设计的相对简单，数据层对于前端应用透明，由 ICE提供，数据库分布式的设计在后端实现，使用ICE封装后给前端应用使用，这路设计对每一部分设计的要求较低，将业务更好的分层，但由于引入了中间 件，分了更多层，实现起来成本也相对较高。
在数据库的设计上一方面可以使用集群，一方面进行分组。同时在细节上将数据库优化的原则尽量应用，数 据库结构和数据层应用在设计上尽量避免临时表的创建、死锁的产生。数据库优化的原则在网上比较常见，多google一下就能解决问题。在数据库的选择上可 以根据自己的习惯选择，Oracle，MySQL等，并非Oracle就够解决所有的问题，也并非MySQL就代表小应用，合适的就是最好的。
前面讲的都是基于软件的性能设计方案，实际上硬件的良好搭配使用也可以有效的降低时间成本，以及开发维护成本，只是在这里我们不再展开。
网 站架构的设计是一个整体的工程，在设计的时候需要考虑到性能，可括展性，硬件成本，时间成本等等，如何根据业务的定位，资金，时间，人员的条件设计合适的 方案是件比较困难的事情，但多想多实践，终究会建立一套适合自己的网站设计理念，用于指导网站的设计工作，为网站的发展奠定良好的基础。

? 面向高负载的架构Lighttpd+PHP(FastCGI)+Memcached+Squid
By Michael
　　因新项目，开始从Apache上转移到Lighttpd上，同时还有Memcached的大量使用，借此机会把toplee.com的服务器环境也进行一些改造，顺便整理一份文档留存！
　　更多大型架构的经验，可以看我之前的一篇blog：http://www.toplee.com/blog/archives/71.html
12.31 截至今天完成以下内容：
　　　　1. 完成lighttpd的安装配置，并且做了大量的优化；
　　　　2. 几乎全部看完了http://trac.lighttpd.net/trac/wiki上的文档；
　　　　3. 配置了lighttpd和php的fastcgi支持；
　　　　4. 增加了php对XCache的支持；
　　　　5. 设置了部分域名在lighttpd上的解析；
　　　　6. 完成了Apache通过mod_rewrite和mod_proxy将部分域名以及全部的php访问转到lighttpd上；
　　　　7.完成Memcached的环境搭建，并且修改了部分数据库操作缓存到MC上；

　　效果：
　　　　1. 系统负载变低了不少，响应速度得到提升；
　　　　2. MC的效果非常理想，数据库压力得到很大减轻。
　　TODO：
　　　　（下面的事情等我买了第二台服务器后进行，目前仅在帮朋友的项目上这么干了）
　　　　-. 配置MySQL的Master/Slave模式，把对数据库的Write和Read进行分开
　　　　-. 加入squid群进行缓存加速
　　　　-. 其他（比如DNS负载均衡加LVS的四层交换…）
To be continued…
注册┆登录┆发表文章
? 思考高并发高负载网站的系统架构

2007-04-13　10:38:10

大中小
下面是我10月中旬的想法，经过和小黑的讨论，现在想法有些变化。

如今百家@*店的网站架构已经在超负荷工作了。服务器经常达到100%的使用率。主要是数据库占用了大量的CPU资源。这样的系统，根本无法跟上网站的发展。
所以，我针对我们网站，考虑了一些关于网站流量分流的方法。
1， 看了一下别人的文章，大部分都说，现在的网站瓶颈在于数据库。所以，我们这里放在第一条。我们设计的网站要求用户数量要达到1亿。（目前淘宝用户近 2000万，腾讯用户近10亿，活跃用户1亿多）。当然，我们的设计要多考虑一些，所以，就定位在淘宝的用户数和腾讯的用户数之间。
用户名列表 单独建立数据库，以便随时将此数据库独立出去单独建服务器。用户登录的时候，数据库要从1亿记录中查找数据，即使使用主索引，也要将近1秒时间（在 SQLSERVER中，使用like查找20万条数据，就需要大约2秒种，这里是按照精确匹配以及主索引联合的方式查找）。所以，我们要将用户表分表。以 26个字母为分表顺序，中文开头的用户名一张表，数字开头的用户名一张表。这样就有28张表，平均下来，一张表300万数据，最多的一张表估计大约 1000万数据。然后，以用户名为主索引，SQLSERVER数据库应该可以应付过来了。
除了用户表单独建立数据库以外，还要准备大城市大约需 要100万左右的商品数据，500万左右的帖子（目前杭州网论坛有超过30万主题贴，600万回复贴），所以，现将商品数据存放在一个独立的数据库中，论 坛帖子也存放在一个独立的数据库中，商品数据按城市分表，论坛帖子也安城市分，分别是主题贴一张表，回复贴一张表。
商店数量（淘宝目前有约60万活跃商店）我们网站应为不释放商店，所以需要更多的表存储该数据，目前无法确定，约为1000万家商店。保险期间，也独立建一个数据库，到时候可以和其他小数据库同用一个服务器。
商店对应的商店分类，以及友情链接，由于数量要预定至少10倍于商店数量，所以也要分别单独建立数据库，并按照用户名分表。
网站总设置，以及城市列表，版主信息等，这些可以生成静态内容的单独建立一个数据库。城市内商品分类需要单独建立一个数据库。并按照城市分表。
其他内容同理。到这里为止，理论上解决了数据库的瓶颈问题。
2， 尽可能生成静态HTML页面。首页生成HTML页面，城市首页生成HTML页面，所有商品页面生成HTML页面，帖子第一页（前10篇）也生成HTML页 面。如果一个主题贴超过1页，可以点击“更多”查看。这样可以节省服务器资源。生成页面的时候，服务器会占用大量CPU资源。所以，此功能要单独放置在一 个独立的服务器中，并在该服务器上建立一个缓存队列数据库，用户在提交表单的时候，将数据保存在缓存队列数据库中，等待服务器的处理。服务器按照发表时间 顺序（主索引）处理这些内容。将生成的HTML商品页面放在一个文件夹内（可随时增设服务器），上传图片和处理图片，存放图片在另一个文件夹内（图片最消 耗IIS资源，以后一定要增设图片服务器）。并将处理好的内容存入主数据库中，并在缓存队列数据库中删除处理好的记录。这2块是占用CPU的大头，要随时 准备移除主WEB服务器。
3，使用缓存。有些网页，像首页，可以学习百度首页，缓存24小时。
4，读取和写入数据库分开。用2个完全一样的数据库，一个专门用来写入，一个用来读取，隔断时间将新加入的数据从写入数据库拷贝到读取数据库，这样可以减少数据库的符合。这个方法听说很多网站都采用的。
5，在北方，教育网等特殊网络做镜像服务器；
6，使用负载均衡技术。由特殊的服务商提供方案。

? "我在SOHU这几年做的一些门户级别的程序系统(C/C++开发)"
Bserv:
用于高负载，高读写速度的单点和集合数 据。 内核为BerkeleyDB，外壳为UDP线程池。 接口为读写单点数据或者集合数据。单点数据就是Key->Value数据。 集合数据就是有索引的数据，List->Keys->Values。 比如一个班级所有成员，一个主贴所有回帖等等。 DBDS性能很高，每秒读取>800个每秒，写>300个每秒（志强xeon:2G*2，72Gscsi，Ram:2G） 配合java接口，目前应用在ChinaRen所有项目中（ChinaRen校内，校友录，社区等等）。是整个ChinaRen的核心数据服务，大概配备 了50台服务器。 特点：高速，高请求量。用于各种数据的低成本存储，解决数据库无法实现超高速读写的问题。门户级别的高速数据服务。 OnlineServer:
ChinaRen/SOHU小纸条系统核心 核心为3个小server系统：online2(在线系统业务逻辑)，userv(用户资料系统)，cserv(LRU缓存) 这三个子系统都是UDP+线程池结构，单进程+多线程。配备java接口，apache_mod的json和xml接口。 online2包括了大部分业务逻辑，包括，上线，好友系统，纸条系统。 userv包括设置用户各种属性，信息。 cserv是个大的lru缓存，用于减小磁盘IO。可以放各种信息块，包括用户信息，好友，留言等。 目前配备4台服务器（DL380，xeon:3G*2，SCSI:146G raid，Ram:2G），用户分布到4台服务器上，相互交互。服务器可以由1台到2台，到4台，到8台。 底层存储为文件存储（无数据库），用reiserfs。 配套系统： mod_online，两个版本，apache和lighttpd版本，用于页面上显示蜡烛人。请求量巨大，目前用lighttpd版本的 mod_online。 放在sohu的squid前端机器上，运行在8080，大概8台，每台请求量大概500-800个每秒。蜡烛人在所有ChinaRen页面有ID的地方 显示用户是否在线。 目前这套在线系统，作为SOHUIM的内核原型。准备开发WEBIM系统，用户所有SOHU矩阵用户的联络。
apache_mod系列:
基于apache2的服务有很多，用于高请求量，快速显示的地方。 1.mod_gen_verifyimg2：
用于显示验证码，使用GD2，freetype。直接在apache端返回gif流，显示随机的字体，角度，颜色等等。用于ChinaRen各个需要验证码的页面，请求量很大。 2.mod_ip2loc
用 于apache端的IP->物理地址转换，高速，高效。 读取数据文件到内部数据树，高速检索，获得客户端ip的物理地址。用于需要IP自动定位的产品，还有就是数据统计等。比如ChinaRen校内， 每个客户端请求都能获得物理地址，用于应用的逻辑处理。 3.mod_pvserver2
ChinaRen社区帖子点击的记录和显示。 根据URL，得到帖子ID，通过UDP数据包，统计到bserv系统。并且把结果通过Cookie返回到客户端。html直接用javascript显示 点击数在帖子上。 解决了点击数量高效记录，高效读取和非动态页面程序显示的问题。 4.mod_online
用于ChinaRen页面上的蜡 烛人显示。和onlineserver通讯，得到用户在线状态和其他状态信息。请求量很大，每台前端大概500-800个请求。 5.其他mod 还有一些认证的，访问统计的，特种url过虑跳转的，页面key生成的，还有若干。 特点：高速，密集超高请求量。前端分担应用服务器压力，高效。
cserv:
高 速LRU缓存系统。 内核是UDP+线程池+LRU结构（hash+PQueue）。 用于存放各种数据块，Key->Value结构。通过LRU方式提供给应用，可减小文件IO，磁盘IO等慢速操作。目前用于ChinaRen在线系 统的用户资料缓存。 特点：高速读写，低成本。
ddap:
UDP+线程池，单进程，多线程的服务端程序原型，大部分程序由这个结构开始。 性能为8000-10000个请求每秒。
eserv:
访 问统计系统 用于用户访问的次数和最后上线时间的存储和读写。 用于ChinaRen校友录每个班级的访问记录。存储为文件存储，并有同时写入后备的bserv，用于备份和检索。 目前性能，每台机器每秒50个记录，100个读每秒。能满足校友录巨大的用户登录记录的需要。 特点：无数据库，纯文件存储，高速读写。低成本
logserver:
用于各种事件的日志记录 核心为ddap，UDP+线程池 功能是分模块记录各种日志。ChinaRen所有用户服务，系统日志，都记录在logserver中。用于统计，查询。 写入性能很好，每秒100个单台机器。 特点：高速高效，低成本，海量。
SessionServ:
session 系统 核心为ddap，UDP+线程池 用于在内存中存储临时数据。有get/put/del/inc等操作。广泛的用于固定时间窗口的小数据存储。比如过期，数据有效性检测，应用 同步等等。由于是全内存操作，所以速度很快，存取速度应该>1000个每秒。 目前广泛用与ChinaRen社区，校内，校友录等业务当中。 特点：高速高效，低成本，应用广泛。
其他server:
MO_dispatcher： 用于短信上行接口的的数据转发，使用TCP。能高速大流量根据业务号码分发到各个应用服务中。目前用于SOHU短信到ChinaRen各短信服务的转发。 sync： 用于静态前端同步，分客户端和服务端程序。客户端通过TCP链接和服务端获取需要同步的文件列表，并且通过TCP高速更新本地文件。 此同步程序用于多客户端，单服务端。比如一台服务器生成静态文件，同步这些文件到若干客户前端去。 特点：门户级静态内容服务器间同步，高效，高速，大流量。目前用于ChinaRen社区的静态帖子。
总结一下:
门户的核心服务，要求是高效率，高密度存取，海量数据，最好还是低成本。不要用数据库，不要用java，不要用mswin。用C，用内存，用文件，用linux就对了。
? 中国顶级门户网站架构分析1

首先声明，下面的内容都是我个人根据一些工具形成的猜想。并不保证和现实中各大门户网站所用的架构一摸一样，不过我认为八九不离十了^_^ 。
整篇文章我想分2个部分来讲：第一部分是分析国内2大顶级门户网站首页和频道的初步的基本构架。第二部分我将自己做的实验文档记录下来。希望每个SA心里都能有这样的架构。
新 浪和搜狐在国内的知名度可谓无人不知无人不晓。他们每天的点击率都在千万以上。这样大的访问量对于新浪和搜狐来说怎样利用有限的资源让网民获得最快的速度 成为首要的前提，毕竟现在网络公司已经离开了烧钱的阶段，开始了良性发展，每一笔钱砸下去都需要一定回响才行的。另一方面，技术人员要绞尽脑汁，不能让用 户老是无法访问、或者访问速度极慢。这样就算有再好的编辑、再好的销售，他们也很难将广告位卖出去，等待他们的将是关门。当然这些情况都没有发生，因为他 们的技术人员都充分的利用了现有资源并将他们发挥到了极至。说到底就是用squid做web cache server，而apache在squid的后面提供真正的web服务。当然使用这样的架构必须要保证主页上大部分都是静态页面。这就需要程序员的配合将 页面在反馈给客户端之前将页面全部转换成静态页面。好了基本架构就这样，下面说说我怎么猜到的以及具体的架构：
法宝之一：nslookup
实战：
nslookup http://www.sina.com.cn/
Server: ns-px.online.sh.cn
Address: 202.96.209.5
Non-authoritative answer:
Name: taurus.sina.com.cn
Addresses: 61.172.201.230, 61.172.201.231, 61.172.201.232, 61.172.201.233
61.172.201.221, 61.172.201.222, 61.172.201.223, 61.172.201.224, 61.172.201.225
61.172.201.226, 61.172.201.227, 61.172.201.228, 61.172.201.229
Aliases: http://www.sina.com.cn/, jupiter.sina.com.cn
这里可以看到新浪在首页上用到了那么多IP，开始有人会想果然新浪财大气粗啊。其实不然，继续往下看：
nslookup news.sina.com.cn
Server: ns-px.online.sh.cn
Address: 202.96.209.5
Non-authoritative answer:
Name: taurus.sina.com.cn
Addresses: 61.172.201.228, 61.172.201.229, 61.172.201.230, 61.172.201.231
61.172.201.232, 61.172.201.233, 61.172.201.221, 61.172.201.222, 61.172.201.223
61.172.201.224, 61.172.201.225, 61.172.201.226, 61.172.201.227
Aliases: news.sina.com.cn, jupiter.sina.com.cn
细 心的人可以发现了news这个频道的ip数和首页上一样，而且IP也完全一样。也就是这些IP在sina的DNS上的名字都叫 taurus.sina.com.cn，那些IP都是这个域的A记录。而news,sports,jczs.news。。。都是CNAME记录。用DNS 来做自动轮询。还不信，再来一个，就体育频道好了：
nslookup sports.sina.com.cn
Server: ns-px.online.sh.cn
Address: 202.96.209.5
Non-authoritative answer:
Name: taurus.sina.com.cn
Addresses: 61.172.201.222, 61.172.201.223, 61.172.201.224, 61.172.201.225
61.172.201.226, 61.172.201.227, 61.172.201.228, 61.172.201.229, 61.172.201.230
61.172.201.231, 61.172.201.232, 61.172.201.233, 61.172.201.221
Aliases: sports.sina.com.cn, jupiter.sina.com.cn
其他的可以自己试。好了再来看看sohu的情况：
nslookup http://www.sohu.com/
Server: ns-px.online.sh.cn
Address: 202.96.209.5
Non-authoritative answer:
Name: pagegrp1.sohu.com
Addresses: 61.135.132.172, 61.135.132.173, 61.135.132.176, 61.135.133.109
61.135.145.47, 61.135.150.65, 61.135.150.67, 61.135.150.69, 61.135.150.74
61.135.150.75, 61.135.150.145, 61.135.131.73, 61.135.131.91, 61.135.131.180
61.135.131.182, 61.135.131.183, 61.135.132.65, 61.135.132.80
Aliases: http://www.sohu.com/
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
nslookup news.sohu.com
Server: ns-px.online.sh.cn
Address: 202.96.209.5
Non-authoritative answer:
Name: pagegrp1.sohu.com
Addresses: 61.135.150.145, 61.135.131.73, 61.135.131.91, 61.135.131.180
61.135.131.182, 61.135.131.183, 61.135.132.65, 61.135.132.80, 61.135.132.172
61.135.132.173, 61.135.132.176, 61.135.133.109, 61.135.145.47, 61.135.150.65
61.135.150.67, 61.135.150.69, 61.135.150.74, 61.135.150.75
Aliases: news.sohu.com
情况和sina一样，只是从表面来看sohu的IP数要多于sina的IP数，那么sohu上各个频道用的服务器就要多于sina了？当然不能这么说，因为一台服务器可以绑定多个IP，因此不能从IP数的多少来判断用了多少服务器。
从 上面这些实验可以基本看出sina和sohu对于频道等栏目都用了相同的技术，即squid来监听这些IP的80端口，而真正的web server来监听另外一个端口。从用户的感觉上来说不会有任何的区别，而相对于将web server直接和客户端连在一起的方式，这样的方式明显的节省的带宽和服务器。用户访问的速度感觉也会更快。
先说那么多了，要去睡觉了，明天还有很多工作要做～有不明白的记得给我留言！！！
? 中国顶级门户网站架构分析 2
中国顶级门户网站架构分析1
前天讲了最基本的推测方法，今天稍微深入一些：）
1. 难道就根据几个域名的ip相同就可以证明他们是使用squid的嘛？
当然不是，前面都只是推测。下面才是真正的证实我上面的猜测。先nslookup一把sina的体育频道。
nslookup sports.sina.com.cn
Server: ns1.china.com
Address: 61.151.243.136
Non-authoritative answer:
Name: taurus.sina.com.cn
Addresses:61.172.201.231, 61.172.201.232, 61.172.201.233, 61.172.201.9
61.172.201.10, 61.172.201.11, 61.172.201.12, 61.172.201.13, 61.172.201.14
61.172.201.15, 61.172.201.16, 61.172.201.17, 61.172.201.227, 61.172.201.228
61.172.201.229, 61.172.201.230
Aliases: sports.sina.com.cn, jupiter.sina.com.cn
然后直接访问这些ip中的任意一个ip试试看，访问下来的结果应该是如下图所示：

由此可以证明sina是在dns中设置了很多ip来指向域名sqsh-19.sina.com.cn，而其他各种相同性质的频道都只是sqsh- 19.sina.com.cn一个别名，用CNAME指定。dns的设置应该是这样的，然后server方面，通过squid 2.5.STABLE5（最新的稳定版为STABLE6）来侦听80端口。上面这些是根据一些信息分析而出的，应该基本正确的。下面一些就是我的个人的猜 想：
它的真正的web server也同样是侦听80端口，因为在squid配置文件中有一项是：
httpd_accel_port 80
如果你设成其他端口号（比如88）的话，那上图的错误信息就会变成
While trying to retrieve the URL: http://61.172.201.19:88/
工具2：nmap扫描程序：可以用来检查服务器开了什么端口。
我现在用nmap来扫描sina的一个ip：61.172.201.19来进行分析
bash-2.05$ nmap 61.172.201.19
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-07-30 13:31 GMT
Interesting ports on 61.172.201.19:
(The 1657 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
Nmap run completed -- 1 IP address (1 host up) scanned in 73.191 seconds
可以看到他对外只开了2个端口，80端口就是刚才我们说的squid打开的，这点刚才已经验证过了。而22端口是用来ssh远程连接的，主要是sa用来远程操作服务器用的安全性非常高的方法。
工具3：lynx或者其他可以读取http头文件的工具及小程序：直接看例子比较好理解：）
HTTP/1.0 200 OK
Date: Fri, 30 Jul 2004 05:49:47 GMT
Server: Apache/2.0.49 (Unix)
Last-Modified: Fri, 30 Jul 2004 05:48:16 GMT
Accept-Ranges: bytes
Vary: Accept-Encoding
Cache-Control: max-age=60
Expires: Fri, 30 Jul 2004 05:50:47 GMT
Content-Length: 180747
Content-Type: text/html
Age: 37
X-Cache: HIT from sqsh-230.sina.com.cn
Connection: close
上 面是sina的http头的反馈信息。里面有很多有价值的东东哦：）譬如，它后面的apache是用2.0.49，还设了过期时间为2分钟。最后修改时 间。这些都是要在编译apache的时候载入的，特别是Last-Modified还需要小小的改一把源码--至少我是这样做的。
综上所述
sina 的架构应该是前面squid，按照现在的服务器2u，2g内存一般每台服务器至少可以跑4个squid2.5stable5. 这样它16个ip就用了4台服务器。后面一层是apache2.0.49应该会用2台。这2台可能用的全是私有ip，通过前面的squid服务器在 hosts文件中指定。具体的实现方法我会下次整理出我做实验的文档：）而apache的htdocs可能是有一个或2个磁盘阵列作nfs。apache mount nfs server的时候应该是只读的，然后另外还有服务器转门用来做编辑器服务器，用来编辑人员更新文章。这台服务器应该对nfs server是具有可写的权限。
----这就一套完整的sina所运用的方案，当然很多是靠猜测的，我没有和sina的技术人员有过任何沟通（因为一个也不认识），否则我也就不会写出来了。其他sohu，163应该也有这样的架构。
最后声明：这只是一些静态页面组成频道的一个架构，sina还有很多其他服务器，什么下载，在线更新等不在这个架构中。
? 服务器的大用户量的承载方案
http://blog.chinaunix.net/u/243/showart_299315.html
一、前言
二、编译安装
三、 安装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（做反向代理的同时提供专业缓存功能）

 

? YouTube Scalability Talk
Cuong Do of YouTube / Google recently gave a Google Tech Talk on scalability.
I found it interesting in light of my own comments on YouTube’s 45 TB a while back.
Here are my notes from his talk, a mix of what he said and my commentary:
In the summer of 2006, they grew from 30 million pages per day to 100 million pages per day, in a 4 month period. (Wow! In most organizations, it takes nearly 4 months to pick out, order, install, and set up a few servers.)
YouTube uses Apache for FastCGI serving. (I wonder if things would have been easier for them had they chosen nginx, which is apparently wonderful for FastCGI and less problematic than Lighttpd)
YouTube is coded mostly in Python. Why? “Development speed critical”.
They use psyco, Python -> C compiler, and also C extensions, for performance critical work.
They use Lighttpd for serving the video itself, for a big improvement over Apache.
Each video hosted by a “mini cluster”, which is a set of machine with the same content. This is a simple way to provide headroom (slack), so that a machine can be taken down for maintenance (or can fail) without affecting users. It also provides a form of backup.
The most popular videos are on a CDN (Content Distribution Network) - they use external CDNs and well as Google’s CDN. Requests to their own machines are therefore tail-heavy (in the “Long Tail” sense), because the head codes to the CDN instead.
Because of the tail-heavy load, random disks seeks are especially important (perhaps more important than caching?).
YouTube uses simple, cheap, commodity Hardware. The more expensive the hardware, the more expensive everything else gets (support, etc.). Maintenance is mostly done with rsync, SSH, other simple, common tools.
The fun is not over: Cuong showed a recent email titled “3 days of video storage left”. There is constant work to keep up with the growth.
Thumbnails turn out to be surprisingly hard to serve efficiently. Because there, on average, 4 thumbnails per video and many thumbnails per pages, the overall number of thumbnails per second is enormous. They use a separate group of machines to serve thumbnails, with extensive caching and OS tuning specific to this load.
YouTube was bit by a “too many files in one dir” limit: at one point they could accept no more uploads (!!) because of this. The first fix was the usual one: split the files across many directories, and switch to another file system better suited for many small files.
Cuong joked about “The Windows approach of scaling: restart everything”
Lighttpd turned out to be poor for serving the thumbnails, because its main loop is a bottleneck to load files from disk; they addressed this by modifying Lighttpd to add worker threads to read from disk. This was good but still not good enough, with one thumbnail per file, because the enormous number of files was terribly slow to work with (imagine tarring up many million files).
Their new solution for thumbnails is to use Google’s BigTable, which provides high performance for a large number of rows, fault tolerance, caching, etc. This is a nice (and rare?) example of actual synergy in an acquisition.
YouTube uses MySQL to store metadata. Early on they hit a Linux kernel issue which prioritized the page cache higher than app data, it swapped out the app data, totally overwhelming the system. They recovered from this by removing the swap partition (while live!). This worked.
YouTube uses Memcached.
To scale out the database, they first used MySQL replication. Like everyone else that goes down this path, they eventually reach a point where replicating the writes to all the DBs, uses up all the capacity of the slaves. They also hit a issue with threading and replication, which they worked around with a very clever “cache primer thread” working a second or so ahead of the replication thread, prefetching the data it would need.
As the replicate-one-DB approach faltered, they resorted to various desperate measures, such as splitting the video watching in to a separate set of replicas, intentionally allowing the non-video-serving parts of YouTube to perform badly so as to focus on serving videos.
Their initial MySQL DB server configuration had 10 disks in a RAID10. This does not work very well, because the DB/OS can’t take advantage of the multiple disks in parallel. They moved to a set of RAID1s, appended together. In my experience, this is better, but still not great. An approach that usually works even better is to intentionally split different data on to different RAIDs: for example, a RAID for the OS / application, a RAID for the DB logs, one or more RAIDs for the DB table (uses “tablespaces” to get your #1 busiest table on separate spindles from your #2 busiest table), one or more RAID for index, etc. Big-iron Oracle installation sometimes take this approach to extremes; the same thing can be done with free DBs on free OSs also.
In spite of all these effort, they reached a point where replication of one large DB was no longer able to keep up. Like everyone else, they figured out that the solution database partitioning in to “shards”. This spread reads and writes in to many different databases (on different servers) that are not all running each other’s writes. The result is a large performance boost, better cache locality, etc. YouTube reduced their total DB hardware by 30% in the process.
It is important to divide users across shards by a controllable lookup mechanism, not only by a hash of the username/ID/whatever, so that you can rebalance shards incrementally.
An interesting DMCA issue: YouTube complies with takedown requests; but sometimes the videos are cached way out on the “edge” of the network (their caches, and other people’s caches), so its hard to get a video to disappear globally right away. This sometimes angers content owners.
Early on, YouTube leased their hardware.
? High Performance Web Sites by Nate Koechley
One dozen rules for faster pages
1. Share results of our research in t Yahoo is firml committed to openness
Why talk about performance?
In the last 2 years, we do a lot more with web pages. Steve Souders - High Performance Two Performance Flavors: Response Time and System Efficiency The importance of front end performance!!! 95% is front end. Back0end vs. Front-end Until now we haveon 1 Perception - How fast does it feel to the users? Perceived response time It's in the eye of the beholder 2 80% of consequences Yahoo Interface Blog yuiblog.com 3 Cache Sadly the cache doesn't work as well as it should 40-60% of users still have an empty cache Therefore optimize for no-cache and with cache 4 Cookies Set scope correctly Keep sizes low, 80ms delay with cookies Total cookie size - Amazon 60 bytes - good example. 1. Eliminate unnecessary cookies 2. Keep cookie sizes low 3. 5 Parallel Downloads
One Dozen Rules
Rule 1 - Make fewer HTTP requests css sprites alistapart.com