Apache的HTTP压缩GZIP优化配置 HTTP压缩对于纯文本内容可压缩至原大小的40％一下，从而提供60％以上的数据传输节约，虽然WEB服务器会因为压缩导致CPU占用的略微上升，但是 可以节约大量用于传输的网络IO。对于数据压缩带来的用户浏览速度提升（让页面符合8秒定律），这点总体负载5%-10%上升是非常值得的。毕竟通过数据 压缩会比通过不规范的HTML代码优化要方便得多。mod_gzip的安装：修改Makefile中的 apxs路径：然后make make install配置：mod_gzip+mod_phpLoadModule gzip_module modules/mod_gzip.so…AddModule mod_gzip.c…<IfModule mod_gzip.c>mod_gzip_on Yesmod_gzip_minimum_file_size 1000mod_gzip_maximum_file_size 300000mod_gzip_item_include file \.htm$mod_gzip_item_include file \.html$mod_gzip_item_include file \.php$mod_gzip_item_include file \.php3$mod_gzip_item_include mime text/.*mod_gzip_item_include mime httpd/unix-directory# mod_gzip的临时工作目录: mkdir /tmp/mod_gzip; chmod -R 777 mod_gzipmod_gzip_temp_dir /tmp/mod_gzipmod_gzip_dechunk Yesmod_gzip_keep_workfiles No</IfModule> mod_gzip和mod_php的配合：不要让mod_gzip和mod_php使用同一个临时目录，php_session存放目录可以通过 php.ini设置到session.save_path = /tmp/php_sessmod_gzip和Resin配合：从resin的邮件列表上查到的：要让mod_gzip在mod_caucho后加载，否则mod_gzip不起作用…othr modulesAddModule mod_so.cAddModule mod_caucho.c#notice: mod_gzip must load after mod_cauchoAddModule mod_gzip.cAddModule mod_expires.c…配置：mod_gzip + resin<IFModule mod_gzip.c>mod_gzip_on Yesmod_gzip_dechunk yesmod_gzip_keep_workfiles Nomod_gzip_minimum_file_size 3000mod_gzip_maximum_file_size 300000mod_gzip_item_include file \.html$mod_gzip_item_include mime text/.*mod_gzip_item_include mime httpd/unix-directorymod_gzip_item_include handler caucho-request</IFModule>配置：mod_gzip + mod_proxy 反相代理加速并压缩 IIS注意要增加缺省的文件编码属性映射。AddType text/html .aspAddType text/html .aspx<IFModule mod_gzip.c>AddType text/html .aspAddType text/html .aspxmod_gzip_on Yesmod_gzip_dechunk yesmod_gzip_keep_workfiles Nomod_gzip_minimum_file_size 3000mod_gzip_maximum_file_size 300000mod_gzip_item_include file \.html$mod_gzip_item_include file \.asp$mod_gzip_item_include file \.aspx$mod_gzip_item_include mime text/.*mod_gzip_item_include mime httpd/unix-directorymod_gzip_item_include handler proxy-server</IFModule>参考资料：mod_gzip的下载http://sourceforge.net/projects/mod-gzip/mod_gzip项目首页http://www.schroepl.net/projekte/mod_gzip/Apache2 中的mod_deflate：压缩率比mod_gzip略低http://httpd.apache.org/docs-2.0/mod/mod_deflate.html模块化安装Apachehttp://www.chedong.com/tech/apache_install.html作者：车东 发表于：http://www.chedong.com/tech/compress.html

.Net架构网站遇到大表的处理办法 最近做的web2.0网站本身遇到一个大表(2000万rows左右)，因为对于performance，web本身可用性的考虑，必须想办法boost perf.这种情况应该都用partition来搞定了，这也符合分治等算法的思想，想办法降低问题本身的复杂度，然后在一个一个解决。mysql中一般到100万操作就有点麻烦了，index要好好的做。这里还遇到了一个文本检索问题，MyIASM storage engine里面有个full-text index，但是不知道它对于中文支持如何，而且不清楚它是怎么分词的，不大清楚后台逻辑，Mysql这种index limitation很多，很难scalable，所以基本上直接考虑用search engine那一套。直接上了lucene+solr+solrsharp.小表like还可以忽悠忽悠，大点就慢的如老牛……Partition通过了解发现解决方案倒是不少，以前做过了解过这方面知识储备。对hivedb，hscale等都没想过要尝试，发现。net在使用open source很多都不是很舒服。最开始尝试了mysql partition，一开始听起来方法这种方案很Perfect!是mysql解决horizontal partioning的很好方案，等document看完了，发现5.1版本的partion limitation太多了，只能适合某些特性的场景，例如按照用户id做split;普通那种非unique key，primary key是很难搞定的，简单方法是给表本身不添加任何主键，自己来实现主键生成机制。这样仿佛可以了，但是通过explain partitions来做下analysis，发现结果定位具体parition不好，这就很难降低IO本身的高成本了。没有通过具体测试不知道可能是 explain partition本身不准确原因还是……mysql partition还有一个很大的弊病，就是很难跨机器，当然如何能够把Mysql存储做成分布式，也还好，但是这个技术代价都上了不少档次，risk过高了，只能算是下下策了，备用好了。这些不爽的地方导致偶们直接抛弃了这种方案，直接用手工切分来搞定这种问题，我想这也是大部分这种需求的常见 solution把。手工切分本身技术还比较简单，就是要考虑表的编码，管理等多个方面，以及如何快速定位到可能的partition，这些在设计方面都应该注意了。而且对于多partitions的结果，应该使用多线程等并发，同步技术来提高perf.这里的partition还做到支持对某一个partition做进一步切分，这样切分到每一个partition块尽量表中数据在50万以下，这样加上db index，速度应该能够满足一定的需求的，手工切分本身很容易scale out，可以把表放在不同的机器上等等load balance方法来scale.回想感觉最有意思还是表编码自身的考虑有点意思，我很大程度的灵感来源于IP地址的划分，因为这个表自身增长速度会很慢，所以采用unsigned int来搞定，43亿来表示2000万还是小意思嘛。我主要是通过前缀+长度来定义表的标识。1，2，3前缀可以让给数据比较密集的表，因为它们可以支持10位，其它就用9位来表示，可能有些不再切分范围内的就让他们从0开始增长把。这里partition list本身维护可以序列化到filesystem中，每次Load class时候deserialize一下，然后就是本身partition如何快速定位就需要用点复杂点的data stuctures了。出处:IT专家网论坛

YouTube架构分析 YouTube的成长速度惊人，目前每天视频访问量已达1亿，但站点维护人员很少。他们是如何管理，以实现如此强大供应能力的？被Google收购后，又在走什么样的发展道路呢？转载一些相关的文章，参考学习一下原文: YouTube ArchitectureYouTube发展迅速，每天超过1亿的视频点击量，但只有很少人在维护站点和确保伸缩性。平台ApachePythonLinux(SuSe)MySQLpsyco，一个动态的Python到C的编译器lighttpd代替Apache做视频查看状态支持每天超过1亿的视频点击量成立于2005年2月于2006年3月达到每天3千万的视频点击量于2006年7月达到每天1亿的视频点击量2个系统管理员，2个伸缩性软件架构师2个软件开发工程师，2个网络工程师，1个DBA处理飞速增长的流量Java代码  while (true)   {     identify_and_fix_bottlenecks();     drink();     sleep();     notice_new_bottleneck();   }   while (true) { identify_and_fix_bottlenecks(); drink(); sleep(); notice_new_bottleneck(); }每天运行该循环多次Web服务器1，NetScaler用于负载均衡和静态内容缓存2，使用mod_fast_cgi运行Apache3，使用一个Python应用服务器来处理请求的路由4，应用服务器与多个数据库和其他信息源交互来获取数据和格式化html页面5，一般可以通过添加更多的机器来在Web层提高伸缩性6，Python的Web层代码通常不是性能瓶颈，大部分时间阻塞在RPC7，Python允许快速而灵活的开发和部署8，通常每个页面服务少于100毫秒的时间9，使用psyco(一个类似于JIT编译器的动态的Python到C的编译器)来优化内部循环10，对于像加密等密集型CPU活动，使用C扩展11，对于一些开销昂贵的块使用预先生成并缓存的html12，数据库里使用行级缓存13，缓存完整的Python对象14，有些数据被计算出来并发送给各个程序，所以这些值缓存在本地内存中。这是个使用不当的策略。应用服务器里最快的缓存将预先计算的值发送给所有服务器也花不了多少时间。只需弄一个代理来监听更改，预计算，然后发送。视频服务1，花费包括带宽，硬件和能源消耗2，每个视频由一个迷你集群来host，每个视频被超过一台机器持有3，使用一个集群意味着：-更多的硬盘来持有内容意味着更快的速度-failover。如果一台机器出故障了，另外的机器可以继续服务-在线备份4，使用lighttpd作为Web服务器来提供视频服务：-Apache开销太大-使用epoll来等待多个fds-从单进程配置转变为多进程配置来处理更多的连接5，大部分流行的内容移到CDN：-CDN在多个地方备份内容，这样内容离用户更近的机会就会更高-CDN机器经常内存不足，因为内容太流行以致很少有内容进出内存的颠簸6，不太流行的内容(每天1-20浏览次数)在许多colo站点使用YouTube服务器-长尾效应。一个视频可以有多个播放，但是许多视频正在播放。随机硬盘块被访问-在这种情况下缓存不会很好，所以花钱在更多的缓存上可能没太大意义。-调节RAID控制并注意其他低级问题-调节每台机器上的内存，不要太多也不要太少视频服务关键点1，保持简单和廉价2，保持简单网络路径，在内容和用户间不要有太多设备3，使用常用硬件，昂贵的硬件很难找到帮助文档4，使用简单而常见的工具，使用构建在Linux里或之上的大部分工具5，很好的处理随机查找(SATA，tweaks)缩略图服务1，做到高效令人惊奇的难2，每个视频大概4张缩略图，所以缩略图比视频多很多3，缩略图仅仅host在几个机器上4，持有一些小东西所遇到的问题：-OS级别的大量的硬盘查找和inode和页面缓存问题-单目录文件限制，特别是Ext3，后来移到多分层的结构。内核2.6的最近改进可能让Ext3允许大目录，但在一个文件系统里存储大量文件不是个好主意-每秒大量的请求，因为Web页面可能在页面上显示60个缩略图-在这种高负载下Apache表现的非常糟糕-在Apache前端使用squid，这种方式工作了一段时间，但是由于负载继续增加而以失败告终。它让每秒300个请求变为20个-尝试使用lighttpd但是由于使用单线程它陷于困境。遇到多进程的问题，因为它们各自保持自己单独的缓存-如此多的图片以致一台新机器只能接管24小时-重启机器需要6-10小时来缓存5，为了解决所有这些问题YouTube开始使用Google的BigTable，一个分布式数据存储：-避免小文件问题，因为它将文件收集到一起-快，错误容忍-更低的延迟，因为它使用分布式多级缓存，该缓存与多个不同collocation站点工作-更多信息参考Google Architecture，GoogleTalk Architecture和BigTable还有从DBA Notes看到过的一些：一、系统主要用Python开发，用psyco提高性能看到这个我总算知道Google为什么要收购YouTube了，都喜欢用Python嘛，本 来就有缘。用Python开发的速度显然比用C/C++、 Java等高不少，这一点eBay就比较传统，用C++/Java来写，结果落得需要几百个工程师，编译一次很久。最感兴趣的是用了psyco这个东西，所说这玩意相当于Java中的JIT编译器，通常能将Python代码的执行速度提高4倍，对于算法集中的代码甚至能提高10到100倍。二、使用lighttpd给视频内容本身提供服务时用了lighttpd，不能Apache，据说性能提高不少，但有了说这个还不好，应该用nginx，俄罗斯人写的一玩意。三、最流行的内容自己不管，放在CDN上YouTube很会享受，最常访问的内容自己的系统不管，放在运营商和Google（估计是被Google收购之后吧？）的内容分发网络上。他们自己的服务器只要处理一些不常访问的漏网之鱼就可以了，负载大大减轻。四、缩略图是最大的问题，自己搞不定，最后用Google的BigTable搞定俗话说人小鬼大绝对是有道理的，那么大的视频没什么问题，小小的缩略图却是个大问题。原来YouTube的开发人员用lighttpd，发现效果不太好，就改了代码，但效果还是不行。最后被Google收购后用了BigTable才算搞定这个问题。五、MySQL swap问题，把swap关掉就行了YouTube用MySQL存元数据，结果在Linux上swap颠簸很厉害，解决的方法也简单，把swap关掉就好了。而且人家胆子大，服务还在那里跑，这边就把它关了。六、MySQLYouTube 用MySQL也是摸着石头过河，一开始只用一个主服务器和replication，显然过一阵子这个方法就不行了。后面他们尝试把视频和非视频业务分开处 理，但这个方法也顶不了多久。最终还是走到数据分区这条正道上来。对数据库服务器的磁盘系统的选择也很有意思，最早是用10块盘做RAID 1+0，但发现盘太多了也使不上劲，所以后来改后一堆RAID 1。

Facebook开源源代码下载 Facebook开源源代码下载   Facebook Open PlatformFacebook Open Platform is a snapshot of the infrastructure that runs Facebook Platform. It includes the API infrastructure, the FBML parser, the FQL parser, and FBJS, as well as implementations of many common methods and tags.Facebook的开放平台是一个快照的基础设施运行的Facebook的平台。它包括空气污染指数的基础设施， FBML分析器，分析器的FQL ，并FBJS ，以及实现许多共同的方法和标签。下载地址：http://developers.facebook.com/fbopen/download_fbopen.phpYou can also get the latest source code from the public svn repository.Release NotesBefore you begin, please download and read the full release notes.This release includes the API infrastructure, the FQL parser, the FBML parser, and FBJS, as well as implementations of many common methods and tags. We’ve included samples and some dummy data to help you get started fast.Facebook Open Platform also has extensibility points built in so you can add your own functionality, such as your own FBML tags, API methods, etc.A list of recommended operating systems and compilers for this installation process is on the Facebook Developers Wiki.If you find a bug, please submit it to the Facebook Open Platform product category at http://bugs.developers.facebook.com/We encourage you to give us feedback and to share your thoughts with other developers in the Facebook Platform Developer Forum at http://forum.developers.facebook.comHow Is This Licensed?Facebook Open Platform (except for the FBML parser) is licensed under a Common Public Attribution License (CPAL), which follows the Mozilla Public License (MPL) with two additions:1. That you include attribution to Facebook on any modifications.2. That network deployment, or making modifications available over the network, counts as distribution, which makes the license appropriate for Web services.You can find the CPAL here.The FBML parser is licensed under the MPL. You can find the MPL here.How Can I Contribute?大小: 2.66 K 尺寸: 210 x 79 浏览: 3 次 点击打开新窗口浏览全图If you’d like to contribute to Facebook Open Platform, please sign and return our Contribution Agreement. We’ll evaluate any submitted patches or features to decide whether they’d be strong inclusions into the overall Facebook Open Platform release. If we incorporate your changes, we’ll send you a t-shirt!What’s Included in the Package?The fb-open-platform.tar.gz archive contains the tools necessary to implement Facebook Open Platform — including the API, FBML (Facebook Markup Language), FBJS (Facebook JavaScript), and FQL (Facebook Query Language) — in your own environment. It also contains libfbml-1.2.0.tar.gz, which contains the essential libraries for parsing and rendering FBML.Think this sounds like a fun thing to work on? Join the team.

Google网站架构分析 Google是可伸缩性之王。每个人都知道Google是因为他们对大量，复杂信息的快速搜索，但是Google的技术并不只是在搜索领域闪闪发光。他们构建大型应用的平台方式能够让他们以惊人的竞争速度在网络规模应用上面大展拳脚。Google的目标一直是构建更高性能更高规模基础设施来支持他们的产品。他们怎么做到的呢？参考资料以及信息来源视频：在Google上构建大型系统 (Video: Building Large Systems at Google)Google实验室：Google文件系统 (Google Lab: The Google File System)Google实验室：MapReduce：在大规模集群上简化数据处理 (Google Lab: MapReduce: Simplified Data Processing on Large Clusters)Google实验室：BigTable: (Google Lab: BigTable.)视频：BigTable: 一个分布式的结构化存储系统 (Video: BigTable: A Distributed Structured Storage System.)Google实验室：松散耦合的分布式系统的 Chubby Lock服务 (Google Lab: The Chubby Lock Service for Loosely-Coupled Distributed Systems.)Google是如何工作的 作者 David Carr发表于Baseline杂志 (How Google Works by David Carr in Baseline Magazine.)Google实验室：翻译数据：使用Sawzall并行分析(Google Lab: Interpreting the Data: Parallel Analysis with Sawzall.)可伸缩性大会上Dare Obasonjo的笔记 (Dare Obasonjo’s Notes on the scalability conference.)平台• Linux• 多种不同的语言： Python, Java, C++数据揭秘目前的情形：• 2006年估计有450,000个价格便宜的商用服务器• 2005年Google索引了80亿的web页面。到现在为止有多少，已经无法统计出来了。• 目前Google有超过200GFS的集群。一个集群能有1000甚至5000个机器。成百上千的机器从运行大到5peta字节存储的GFS集群检索数据。通过集群的总的读写吞吐量达到每秒400亿字节。• 目前在Google有6000个 MapReduce应用，并且每个月有几百个新的应用正在出现。架构的层次Google把他们的基础设施架构描述为三个层次栈：• 产品：检索，广告，电子邮件，地图，视频，聊天，博客• 分布式系统基础设施：GFS, MapReduce, 以及BigTable。• 计算平台：很多不同数据中心的很多机器• 确保公司员工容易低成本配置。• 看看每个应用基线的价格性能数据。把更多的钱花在硬件上以期不丢失日志数据，但是在其他类型的数据上花少一点。既然这样处理，实际上他们就不会丢数据。使用GFS（Google文件系统）的可靠存储机制• 可靠的可伸缩存储是任何应用的一个核心需要。GFS就是他们的核心存储平台。• Google文件系统- 大的分布式日志结构化文件系统，里面有大量数据• 为什么不用其他的而非要构建一个文件系统呢？因为他们需要控制所有的事情，而正是这个平台把他们和其他任何一个区分开来。他们需要：- 通过数据中心的高可靠性- 对于几千个网络节点的可伸缩性- 大的读写带宽需求- 支持十亿字节大的数据块- 高效的通过节点减少瓶颈的分布式操作• 系统有主服务器和分块服务器（chunk servers）- 主服务器在各种数据文件上保存元数据。数据以64MB大的块存储在文件系统中。客户机和主服务器对话来操作文件里的元数据，定位包含了磁盘上他们需要的数据的分块服务器。• 一个新的应用可以使用一个已经存在的GFS集群或者他们自己制作。去理解他们使用的通过数据中心的这个供应过程将是非常有趣的。• 主键是足够的基础设施来确保人们对他们的应用有多种选择。可以调整GFS以适应个人应用需要。使用MapReduce对数据做一些事情• 既然你有了一个好的存储系统，你怎样使用如此多的数据呢？假如说你有很多TB的数据存储在1000台机器上。数据库不能扩展或者有效地扩展到这样的规模。这时就要用到MapReduce了。• MapReduce是一个编程模型和用来处理和产生大规模数据集。用户指定一个映射函数处理一个键/值对来产生中间的键/值对集合，还指定一个缩小函数来合并所有的与同一中间键相关的中间值。许多现实世界的任务在这个模型里被表示出来。用这个函数风格写的程序自动并行化并且在一大集群商务机器上执行。运行时系统关心分割输入数据的细节，通过一系列的机器安排程序的执行，处理机器事故，以及管理所需的机器内部通信。这使得没有任何并行和分布式系统经验的程序员能够容易地利用一个大的分布式系统的资源。• 为什么使用MapReduce呢？- 在大量机器上分割任务的极佳方式- 处理机器故障- 在不同类型的应用上工作，如搜索和广告。几乎每个应用都有映射简化类型之类的操作。你可以预计算有用的数据，统计字数，分类几TB的数据，等等。- 计算可以自动地更加靠近IO源。• MapReduce 系统有三个不同类型的服务器。- 主服务器分配用户任务以映射和减少服务器。它也跟踪任务的状态。- 映射服务器接收用户输入，在它们上面实行映射操作。结果写入中间文件。- 化简服务器接收由映射服务器产生的中间文件并在它们上面实行化简操作。• 例如，你想要统计所有网页中字符的个数。你可以把存储在GFS中的页面放入MapReduce。这些都将在1000秒内发生，包括机器同步和协调，任务安排，事故处理和数据传输将会自动完成。- 步骤如下：GFS -> Map -> Shuffle -> Reduction -> 把结果存回GFS- 在MapReduce 里，一个映射把一个视图映射到另一个，产生一个键值对，在我们的例子里是单词和数量。- Shuffling 聚合键的类型- 化简把所有的键值对加起来产生最后的结果。• Google索引管道有大概20个不同的映射化简。一个管道把数据看做记录的一个整体束和聚合键。第二个映射-化简进来把那个结果拿走做其他的一些事情。等等。• 程序可以很小。可以小到20到50行的代码。• 一个问题是stragglers。Stragglers是一种比其他都要慢的计算。Stragglers会发生是因为慢的IO（比如一个糟糕的控制器）或者从一个临时的CPU尖峰信号。解决办法是运行多个同样的计算，当一个完成时就销毁所有其他的计算。• 在映射和化简之间转换的数据被压缩。这样做是因为服务器不受CPU约束，花时间在数据的压缩和解压缩上还是有意义的，可以节省花在带宽和I/O上的时间。在BigTable中存储结构化数据• BigTable 是一个大型的容错和自我管理系统，包括太（万亿）字节的内存和皮字节的内存。它每秒能够处理几百万的读写。• BigTable是一个构建在GFS之上的分布式散列机制。它不是一个关系数据库。它不支持联结或者SQL类型查询。• 它提供查找机制，可以通过键来访问结构化的数据。GFS存储不透明数据和许多应用所需的结构化数据。• 商业化数据不能伸缩到这个层次，它们不在1000个机器上工作。• 通过控制它们自己的低层次存储系统，Google得到更多的控制和有力的工具来改进它们的系统。例如，如果它们想要使得分布数据操作更简单的特征，它们可以在里面构建。• 当系统运行的时候，机器可以增加和减少，而整个系统还会正常工作。• 每个数据条存储在一个可以使用行键，列键或者时间邮票访问的单元中。• 每行存储在一个或者更多个tablet中。一个tablet是数据形式的64KB块的序列叫做SSTable。• BigTable 有三个不同类型的服务器：- 主服务器分配tablet到tablet服务器中。它们跟踪的位置，当需要时还会重新分配任务。- Tablet 服务器处理tablet的读写请求。当tablet超过规模限制（通常是100MB – 200MB）时，它们将它分开。当一个tablet服务器出故障时，会有100个tablet服务器每个捡起一个新的tablet，所以系统就恢复了。• 一个位置组可以被用作与几比特的数据相关的物理存储，为了有一个更好的参考位置。• Tablets尽可能在RAM里被缓存。硬件• 当你有很多个机器时，你如何构建它们以使花费代价最小电能消耗最少呢？• 使用超便宜的商业硬件，拼命利用它们在上面构建软件。• 增加 1,000-fold 计算机电力，如果你使用容易出事故的基础设施而不是构建在高度可靠的部件之上的基础设施时，可以有33倍更低的花费。你必须使用这一策略在不可靠之上构建可靠。• Linux，内部的架构设计，PC类主机板，低端存储。• 性能基线中每瓦的价格没有越来越好。存在着很多的电力和其他问题。• 使用混合收集和它们自己的数据中心。杂类• 很快找出改变而不是等着提问和回答。• 库是构建程序的主要方式。• 一些是以服务的形式提供的应用，比如crawling。• 基础设施处理应用程序的版本，所以它们就能够发布，不用担心破坏事情。Google未来的方向• 支持地理位置分布的集群• 为所有的数据创建单一的全局名字空间。当前数据由集群分离开的。• 更多更好的数据和计算的自动化迁移。• 解决当你用网络分割耦合大范围的复制时产生的一致性问题（例如，即使一个集群已经因为维修或是其他一些临时停电等原因而下线时，还能继续提供服务）Goolge告诉我们的经验• 基础设施是一个很有竞争性的优势。它当然是属于Google的。它们能更快更便宜地提供和生产新的网络服务，这在一定程度上是无人能比的。许多公司采取了完全不同的方式。许多公司把基础设施看做一种花销。每个组将使用完全不同的技术，而且他们很少有计划如何更经济地构建系统。Google把他们自己看做一个系统工程公司，以一个非常新的方式来看待构建软件。• 跨越多个数据中心仍是一个未解决的问题。大多数网站是一个至多是两个数据中心。如何在大量数据中心上充分分配网站，我们说，非常复杂。• 看一看Hadoop (产品)如果你没有时间来从头开始构建所有这个基础设施的话。Hadoop 是一个这里讲的一些主意的开源实现。• 一个平台方式被忽略的优点是初级开发人员可以在平台上很快自信地构建健壮的应用。如果每个项目需要创建同样的分布式基础设施轮，你将会陷入困境，因为知道如何这样做的人员相对稀少。• 协同工作并不总是废话。通过使系统中所有部件一起工作，一个改进会有助于所有的改进。改善文件系统，每个人都会立刻明显受益。如果每个项目使用一个不同的文件系统，那么就没有整个展的持续的改进。• 构建不需要降低系统性能的自我管理系统。这可以让你更容易地平衡各服务器的资源，动态增加更多空间，允许机器下线，以及更从容地处理升级。• 创建一个进化式基础设施。花时间在并行处理上会有回报的。• 不要忽视了学院。学术界有很多好的创意并没有转入生产环境里。Google所做的大部分先于艺术，不只是先于大规模配置。• 考虑压缩。当你有大量CPU可以挥霍和IO限制时，压缩是一个很好的选择。

亿万用户网站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 logo    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说，“但到头来，我认为我们做对的还是比做错的多。”

优化页面网站提高转化率 原文：Make sense of your site: tips for webpage design发表于：2009年3月16日星期一，上午9:28在 以前，当您收到用户的反馈，需要改动您的网站的时候，您可能需要对网页进行重新设计。现在，您可以在您的网站上进行一系列实验，让用户来决定哪种版本最 好，而不是只是跟着感觉走了。这里，我将向您介绍网站实验——同时运行同一网页的多种测试版本来了解哪一种网页方案更奏效。在开始实验之前，请您先为要做实验的部分设计出几种方案。实验的部分可以是一些小的改变，比如换掉一张图片，或者是大的改变，比如大面积调整您网站的布局或颜色方案。然后，您可以使用谷歌提供的免费工具—— 网站优化工具(中 文版)，通过向访问者自动展示网站的不同版本来测试这些不同方案。网站优化工具通过跟踪记录哪一种网站变化最能帮助您实现预定目标，从而能使您了解访问者 最喜欢哪种方案版本。您可以把预定目标设为达成销售、吸引用户提交了一个表单或者点击了某个链接，或者其他与您网站的互动形式。事实上，这个过程就像一个 简单的实验，并不需要很多复杂的数据分析。网站实验的结果经常出人意料。比如，我们曾用网站优 化工具对Picasa首页进行过一次实验，结果就让我们大吃一惊。在版本A里，我们使用了“免费”这个词，采用了以行动为导向的标题，并且放上了非常漂亮 的产品图片。在版本B里，我们删除了图片，用按钮取代了链接，以这个产品能给用户带来的价值为主打理念。如果换作是您，您认为哪种版本能带来更多的 Picasa下载呢？版本A：版本B：我 们起初预测版本A显然会更胜一筹，因为A版本的图片会很吸引眼球，并且免费的字眼应该看上去很有吸引力。然而，实验数据却表明界面更简明的B版本却是带来 下载量更多的。实际上，版本B比版本A多带来30%的下载量！这个例子表明：在有关网站重要决策的时候，有时您是需要依赖数据的，不能凭想当然。现在，您 或许会问自己，“我的网站可能有很多地方需要做实验，我应该从哪里着手呢？” 这里向您提供四点小建议： 建议一：通过8秒测验。用户需要一眼就能理解您网站的主题和目的。访问者通常都很忙，无暇顾及很多细节，您一定不想他们刚来到您的网站上就点击后退按钮吧？ 建议二：告诉用户您的网站能给他们带来什么。突出显示您的网站能给用户带来的清晰的、触手可及的实惠（比如，“节省更多!” “收益更多!” “使用我们的产品会让您更好！”） 建议三：使用更有吸引力的图片。您要尽量采用产品的图片而不是一般的图片，使用图标而不是大块的文字，使用按钮而不是链接。请记住，使用低质量的、不相关的图片只会有损您网站的信誉。 建议四：果断地促成销售。帮助您的访问者尽快进行下一步，使这一步骤明确并容易到达，而不是让用户再去费力寻找。关于号召行动的词汇，“立即购买”要比“添加到购物车”更好。 一旦您决定要测试哪个细节（比如号召用户采取某种行动、颜色方案、标题，布局或者视频），您就可以使用网站优化工具， 进行一项实验。对第一次使用网站优化工具的用户来说，我们推荐A/B实验，这是测试某两种版本哪个更奏效。网站优化工具会帮您处理繁杂的数据，并且当它发 现某一数据能证明某一个方案明显优于另一个时，能及时向您展示。这些结果将在您每个实验的报告中展示，相应的滑动条将变成红色，黄色或绿色。当滑动条变成 绿色的时候，意味着您的两种方案中的某一种已经开始胜出，能够明显地更有助于您实现预先设定的目标：请记住，实验数据产生的最佳实践也不是完全普适的，他们并不一定是最适合您的网站和访问者的。在过去，人们都是凭主观想法和直觉来决定网站的设计。现在，有了这些有力的工具、数据和曲线，您就可以让您的访问者来告诉您哪种网站设计是最适合您的了。现在就试一下吧，希望能给您的网站带来更佳的效果！

大型web2.0互动网站设计方案 分析mixi.jp and Yeejee.com：用开源搭建的可扩展大型SNS网站总概关键点：1，Mysql 切分，采用Innodb运行2，动态Cache 服务器 –美国Facebok.com,中国Yeejee.com,日本mixi.jp均采用开源分布式缓存服务器Memcache3，图片缓存和加速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对内存要求也不是太高，所以可以和平共处，更有效的利用资源。图片的处理就显得相对简单的多了。对于mixi而言，图像主要有两部分：一部分是经常要使用到的，像用户头像，群组的头像等等，大概有100多GB，它们被Squid和CDN所缓存，命中率相对比较高；另一部分是用户上传的大量照片，它们的个体访问量相对而言比较小，命中率也比较低，使用Cache不划算，所以对于这些照片的策略是直接在用户上传的时候分发到到图片存储服务器上，在用户访问的时候直接进行访问，当然图片的位置需要在数据库中进行记录，不然找不到放在哪台服务器上就郁闷了。国内领先的SNS网站-采用类似的系统架构，在下面的文章会进行分析对比。这是稳定与典型的大型互动网站系统架构，web2.0的创业者，在设计网站时，可以参考参考，少走弯路。FROM:it168

Google的运营模式 虽然有那么多围绕着google的这样那样、令人眼花缭乱的传闻，Google依然需要解决那些常见的商业问题，例如报告财务情况，跟踪项目进度。但确实，Google经常使用一些非传统，同时高效率的方法去解决这些需求。Douglas Merrill 走上位于凤凰城的亚利桑那毕尔特摩尔度假酒店的一个演讲台时，他前额的发型依旧那么得有个性，就好像一位有那么点邋遢的大学教授。实际上，4月的这个早晨，他在这儿，是应当地的一个猎头公司（Phoenix Staffing）邀请，在一个早宴上，向一帮CIO们讲述他作为Google内部技术部门经理的工作。Google，这个带着那么些神秘色彩，却相当成功的，市价61亿美元的全球搜索引擎公司，绝对是全球公认数一数二的企业。可惜，Google总是选择性地讲述它那创新的信息管理架构（information management infrastructure），一个建立在可能是全球最大的分布式计算（网格计算）的系统之上的架构。Merrill即将带给他的听众们一个相当难得的机会，去窥视Google的未来。并且解释Google的运作方式和这背后的计算机系统。虽然有那么多围绕着Google的传闻，包括媒体宣称的允许带宠物上班的办公场所，Google的市值，市场占有率，令人眼花缭乱的Beta版（试运行版）的新品发布，甚至它那Microsoft终结者的身份，Google依然需要解决那些基本的问题，例如付账单，收集信息，报告财务收入，跟踪项目进度，雇佣承包商，雇人，评估员工，管理视频会议系统等等，说白了，Google一样要处理那些普通而琐碎的商业事务.“但这并不意味着Google一样采用传统的方式去解决这些问题”，Merrill这样解释道。“一件事以往一贯这么处理，我们也不认为它就一定是最佳的处理方式,” Merrill说.值得注意的是，这意味着Google往往不在标准的硬件上部署标准的商业应用。例如，Google可能会采用文本分析技术去驱动搜索引擎，从而从一封email中抽取应用软件需要的输入，而不是象传统的用户界面那样使用一个数据输入表单。Merrill可能不会把一个应用部署到传统的服务器上，而是部署到一个群集的服务器架构中，这个架构横跨了全球的多个数据中心。Google拥有好几十万的服务器，初步估计超过45万（本文成文大概是2006年7月），组成了数千个集群，并且分布在全球数十个数据中心。 Google在很多地方有数据中心，爱尔兰的都柏林，弗吉尼亚等等。加利福尼亚那个Google刚取得的占地百万平方英尺的数据中心已在租用中，而 Google最近又在俄勒冈州跨哥伦比亚河的一个叫达尔斯（Dalles）的小村庄修建2个足球场那么大的数据中心。依赖分布在不同地理位置上的数个服务器和数据中心，Google得以提供更快速的服务性能给它全球的用户们。因为Internet中任意两台电脑的连接速度本该像光速般快速，可惜它被那些网络中的交换机和路由器的延时大大拖慢了。虽然搜索依旧是Google的主要盈利渠道，那些服务器上同时还会运行 Google旗下的其它产品，例如Gmail, Blogger, 还最近那个基于Web的字处理软件(类似Word软件)和spreadsheets软件(类似Excel软件)。这也是为什么总盛传着Google是Microsoft（微软）的终结者，Google宣称要把一切带到互联网上，让微软的Windows操作系统滚一边去。无论你相不相信，Google和Microsoft已经在正面交火，恶狠狠地掐起来了。Microsoft今年计划投入15亿美元到服务器和数据架构中，而Google可能花费至少相同的钱去保持它的领先地位。而在去年（2005年），Google这方面的投资为8.38亿美元。在Google，大规模系统相关的技术是最重要的。2005年，Google索引了80亿个Web页面。同时，他的市场份额不断高涨。基于最近 ComScore Networks qSearch的一份报告，Google在4月已经占领了美国互联网用户43%的市场份额，而Yahoo仅拥有28%，微软的MSN仅拥有12.9%。而且Google的市场份额还在增长; 毕竟一年前，它只占了36.5%。相同的调查表明，美国人在4月份，进行了66亿次在线搜索，整整比上个月增加了4%。这其中，Google占去了其中29亿次的搜索，Yahoo占去了19亿次，而微软的MSN占了8.58亿次。这个成长得益于众多提高可伸缩能力的科技（scalable technology）。就像Google提交给美国证券交易委员会(SEC)的年报中所提到的：“我们的商业运营依赖于我们的软件和硬件架构，它们在低成本的情况下提供了基本的计算资源。我们整合使用那些现成的机器，并且自定义软件，让他们运行在商业计算机的集群上。我们之前把相当大的投资用在开发这样的架构，这已经为我们带来了不少重要利益。它使得存取和处理大量数据变得简单，使得部署和操作大规模的全球化软件和服务器变得轻松，并且使得大规模计算机集群的管理变得自动化”。Google购买，而不是租用设备，以便于最大化控制它的基础架构。Google的CEO，Eric Schmidt抵制了5月31日来自于财务分析师的策略建议，他说道“我们相信，通过彻底地构建我们自己的基础架构，我们将获得巨大的竞争力。”Google不是简单地购买PC级别的服务器，并把他们叠起来，Schmidt说道，“我们是真正地在建造我们内心设想的超级计算机”。因为Google操作运算着如此巨大规模的数据，它的确值得被研究，尤其当你的组织正在购买或评估网格计算策略（the grid computing strategy）时。也就是你正试图利用很多低成本的计算机协作计算，来处理那些高级别的计算任务。不管这种架构是否还是言过其实，Google拒绝他的设计师被采访，包括对Merrill的跟进采访。不过，Merrill在Phoenix演讲时，已经回答些问题，而Google销售搜索工具（Google Search Appliance ）的部门则帮我们回答了另外一些问题。一般来说，但Google被问到它的后台系统时，它有那么些人格分裂。对媒体，他总是说，“对不起，我们不讨论我们的架构”。然而，当google的工程师们面对着计算机科学听众时，却大门大开，比如面对着一屋子过来应聘的应届毕业生时。结果，这个故事的主要信息来源，主要来自于那些网站上的技术演讲资料，比如华盛顿大学（University of Washington）的官网，以及Google实验室发表那些的研究论文。FROM：译言

Facebook图片管理架构 Facebook 的照片分享很受欢迎，迄今，Facebook 用户已经上传了150亿张照片，加上缩略图，总容量超过1.5PB，而每周新增的照片为2亿2000万张，约25TB，高峰期，Facebook 每秒处理55万张照片，这些数字让如何管理这些数据成为一个巨大的挑战。本文由 Facebook 工程师撰写，讲述了他们是如何管理这些照片的。旧的 NFS 照片架构老的照片系统架构分以下几个层：# 上传层接收用户上传的照片并保存在 NFS 存储层。# 照片服务层接收 HTTP 请求并从 NFS 存储层输出照片。# NFS存储层建立在商业存储系统之上。因为每张照片都以文件形式单独存储，这样庞大的照片量导致非常庞大的元数据规模，超过了 NFS 存储层的缓存上限，导致每次招聘请求会上传都包含多次I/O操作。庞大的元数据成为整个照片架构的瓶颈。这就是为什么 Facebook 主要依赖 CDN 的原因。为了解决这些问题，他们做了两项优化：# Cachr: 一个缓存服务器，缓存 Facebook 的小尺寸用户资料照片。# NFS文件句柄缓存：部署在照片输出层，以降低 NFS 存储层的元数据开销。新的 Haystack 照片架构新的照片架构将输出层和存储层合并为一个物理层，建立在一个基于 HTTP 的照片服务器上，照片存储在一个叫做 haystack 的对象库，以消除照片读取操作中不必要的元数据开销。新架构中，I/O 操作只针对真正的照片数据（而不是文件系统元数据）。haystack 可以细分为以下几个功能层：# HTTP 服务器# 照片存储# Haystack 对象存储# 文件系统# 存储空间存储Haystack 部署在商业存储刀片服务器上，典型配置为一个2U的服务器，包含：# 两个4核CPU# 16GB – 32GB 内存# 硬件 RAID，含256-512M NVRAM 高速缓存# 超过12个1TB SATA 硬盘每个刀片服务器提供大约10TB的存储能力，使用了硬件 RAID-6, RAID 6在保持低成本的基础上实现了很好的性能和冗余。不佳的写性能可以通过高速缓存解决，硬盘缓存被禁用以防止断电损失。文件系统Haystack 对象库是建立在10TB容量的单一文件系统之上。文件系统中的每个文件都在一张区块表中对应具体的物理位置，目前使用的文件系统为 XFS。Haystack 对象库Haystack 是一个简单的日志结构，存储着其内部数据对象的指针。一个 Haystack 包括两个文件，包括指针和索引文件：Haystack 对象存储结构指针和索引文件结构Haystack 写操作Haystack 写操作同步将指针追加到 haystack 存储文件，当指针积累到一定程度，就会生成索引写到索引文件。为了降低硬件故障带来的损失，索引文件还会定期写道存储空间中。Haystack 读操作传到 haystack 读操作的参数包括指针的偏移量，key，代用Key,Cookie 以及数据尺寸。Haystack 于是根据数据尺寸从文件中读取整个指针。Haystack 删除操作删除比较简单，只是在 Haystack 存储的指针上设置一个已删除标志。已经删除的指针和索引的空间并不回收。照片存储服务器照片存储服务器负责接受 HTTP 请求，并转换成相应的 Haystack 操作。为了降低I/O操作，该服务器维护着全部 Haystack 中文件索引的缓存。服务器启动时，系统就会将这些索引读到缓存中。由于每个节点都有数百万张照片，必须保证索引的容量不会超过服务器的物理内存。对于用户上传的图片，系统分配一个64位的独立ID，照片接着被缩放成4种不同尺寸，每种尺寸的图拥有相同的随机 Cookie 和 ID，图片尺寸描述（大，中，小，缩略图）被存在代用key 中。接着上传服务器通知照片存储服务器将这些资料联通图片存储到 haystack 中。每张图片的索引缓存包含以下数据Haystack 使用 Google 的开源 sparse hash data 结构以保证内存中的索引缓存尽可能小。照片存储的写/修改操作写操作将照片数据写到 Haystack 存储并更新内存中的索引。如果索引中已经包含相同的 Key，说明是修改操作。照片存储的读操作传递到 Haystack 的参数包括 Haystack ID，照片的 Key, 尺寸以及 Cookie，服务器从缓存中查找并到 Haystack 中读取真正的数据。照片存储的删除操作通知 Haystack 执行删除操作之后，内存中的索引缓存会被更新，将便宜量设置为0，表示照片已被删除。重新捆扎重新捆扎会复制并建立新的 Haystack，期间，略过那些已经删除的照片的数据，并重新建立内存中的索引缓存。HTTP 服务器Http 框架使用的是简单的 evhttp 服务器。使用多线程，每个线程都可以单独处理一个 HTTP 请求。结束语Haystack 是一个基于 HTTP 的对象存储，包含指向实体数据的指针，该架构消除了文件系统元数据的开销，并实现将全部索引直接存储到缓存，以最小的 I/O 操作实现对照片的存储和读取。本文国际来源：http://www.facebook.com/FacebookEngineering#/note.php?note_id=76191543919&ref=mf中文翻译来源：COMSHARP CMS 官方网站