[转]高负载并发网站架构分析

由于自己正在做一个高性能大用户量的论坛程序，对高性能高并发服务器架构比较感兴趣，于是在网上收集了不少这方面的资料和大家分享。希望能和大家交流
msn: [email protected]
———————————————————————————————————————
? 初创网站与开源软件 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)的