《大型WEB站点架构设计文档.docx》由会员分享，可在线阅读，更多相关《大型WEB站点架构设计文档.docx（11页珍藏版）》请在课桌文档上搜索。
1、1、HTML静态化其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS,像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说
2、，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进展实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像MOP的大杂没就是使用了这样的策略，网易社区等也是如此。同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比方论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进展后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这局部内容进展后台更新的时候进展静态化，这样防止了大量的数据库访问请求。2、图片服务舞别离大家知道，对于Web服务器来说，不管是APaC
3、he、HS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进展别离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用服务器和图片服务器上，可以进展不同的配置优化，比方叩ache在配置COntentTyPe的时候可以尽量少支持，尽可能少的LOadModule,保证更高的系统消耗和执行效率。3、数据库集群和库表散列大型网站都有更杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我
4、们需要使用数据库集群或者库表散列。在数据库集群方面，很多数据库都有自己的解决方案，Oracle.SybaSe等都有很好的方案，常用的MySQL提供的MaSter/Slave也是类似的方案，您使用了什么样的DB,就参考相应的解决方案来实施即可。上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进展别离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进展更小的数据库散列，比方用户表，按照用户ID进展表散列，这样就能够
5、低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进展数据库别离，然后对帖子、用户按照板块和ID进展散列数据库和表，最终可以在配置文件中进展简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。4、缓存缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。架构方面的缓存，对APaChe比较熟悉的人都能知道APaChe提供了自己的缓存模块，也可以使用外加的Squid模块进展缓存，这两种方式均可以有效的提高Apache的访问响应能力。网站程序开
6、发方面的缓存，LinUX上提供的MemOryCaChe是常用的缓存接口，可以在Web开发中使用，比方用JaVa开发的时候就可以调用MemoryCaChe对一些数据进展缓存和通讯共享，一些大型社区使用了这样的架构。另外，在使用Web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的CaChe模块，Java就更多了，.net不是很熟悉，相信也肯定有。5、镜像镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比方ChinaNet和EdUNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进展定时更新或者实时更
7、新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比方LinUX上的rsync等工具。6、负载均衡负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决方法。负载均衡技术开展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。7、硬件四层交换第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到适宜的应用服务器进展处理。第四层交换功能就象是虚IP,指向物理服务器。它传输的业务服从的协议多种多样，有、FTP、NFS、Telnet或其他协
8、议。这些业务在物理服务器根基上，需要更杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间那么由源端和终端IP地址、TCP和UDP端口共同决定。在硬件四层交换产品领域，有一些知名的产品可以选择，比方Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。YahOO中国当初接近2000台服务器使用了三四台Alteon就搞定了。8、软件四层交换大家知道了硬件四层交换机的原理后，基于OSl模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实
9、现方式其实更灵活，处理能力完全看你配置的熟悉能力。软件四层交换我们可以使用LinUX上常用的LVS来解决，LVS就是LinUXVirtualServer,他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的根基上搭建SqUid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。这样的架构我准备空了专门详细整理一下和大家探讨。对于大型网站来说
10、，前面提到的每个方法可能都会被同时使用到，我这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会，有时一个很小的SqUid参数或者apache参数设置，对于系统性能的影响就会很大，希望大家一起讨论，到达抛砖引玉之效。用SqUid做webcacheserver,而叩ache在squid的后面提供真正的Web服务。当然使用这样的架构必须要保证主页上大局部都是静态页面。这就需要程序员的配合将页面在反响给客户端之前将页面全部转换成静态页面O基本看出Sina和SOhu对于频道等栏目都用了一样的技术，即SqUid来监听这些IP的80端口，而真正的WebSerVer来监听另外一个端口。从用户的
11、感觉上来说不会有任何的区别，而相对于将WebSerVer宜接和客户端连在一起的方式，这样的方式明显的节省的带宽和服务器。用户访问的速度感觉也会更快。:带宽：4000M/S（参考）服务器数量：60台左右Web服务器：Ligd,Apache,nginx应用服务器：Tomcat其他：Python,Java,MogileFS、ImageMagick等关于Squid与TomcatSquid与TomCat似乎在Web2.0站点的架构中较少看到。我首先是对Squid有点疑问，对此阿华的解释是“目前暂时还没找到效率比Squid高的缓存系统，原来命中率确实很差，后来在Squid前又装了层Ligd,基于url做h
12、ash,同一个图片始终会到同一台squid去，所以命中率彻底提高了对于应用服务器层的TOmCat,现在Yupoo!技术人员也在逐渐用其他轻量级的东西替代，而YPWS/YPFS现在己经用Python进展开发了。名次解释：YPWS-YupooWebServerYPWS是用Python开发的一个小型Web服务器，提供基本的Web服务外，可以增加针对用户、图片、外链网站显示的逻辑判断，可以安装于任何有空闲资源的服务器中，遇到性能瓶颈时方便横向扩展。YPFS-YupooFileSystem与YPWS类似，YPFS也是基于这个Web服务器上开发的图片上传服务器。Updated:有网友留言质疑Python的
13、效率，Yupoo老大刘平阳在del.icio.us上写到YPWS用Python自己写的，每台机器每秒可以处理294个请求，现在压力几乎都在10%以下图片处理层接下来的ImageProcessServer负责处理用户上传的图片。使用的软件包也是ImageMagick,在上次存储升级的同时，对于锐化的比率也调整过了（我个人感觉，效果确实好了很多）。Magickdtt是图像处理的一个远程接口服务，可以安装在任何有空闲CPU资源的机器上，类似MemCaChed的服务方式。我们知道Flickr的缩略图功能原来是用ImageMagick软件包的，后来被雅虎收购后出于版权原因而丕用了（?）；EXIF与IPT
14、CFliCke是用Perl抽取的，我是非常建议Yupoo!针对EXIF做些文章，这也是潜在产生受益的一个重点。图片存储层原来Yupoo!的存储采用了磁盘阵列柜，基于NFS方式的，随着数据量的增大，Yupoo!开发部从07年6月份就开场着手研究一套大容量的、能满足Yupoo!今后开展需要的、安全可靠的存储系统“，看来Yupoo!系统比较有信心，也是满怀期待的，毕竟这要支撑以TB计算的海量图片的存储和管理。我们知道，一张图片除了原图外，还有不同尺寸的，这些图片统一存储在MogiIeFS中。对于其他局部，常见的Web2.0网站必须软件都能看到，如MySQLMemcachedLigd等。YUPOo!一
15、方面采用不少相比照拟成熟的开源软件，一方面也在自行开发定制适合自己的架构组件。这也是一个Web2.0公司所必需要走的一个途径。非常感谢一下Yupoo!阿华对于技术信息的分享，技术是共通的。下一个能爆料是哪家？-EOF-Iigd+squid这套缓存是放在另外一个机房作为Cdn的一个节点使用的，图中没描绘清楚，给大家带来不便了。SqUid前端用Iigd没用nginx,主要是用了这么久，没出啥大问题，所以就没想其他的了。URLHaSh的扩展性确实不好，能做的就是不轻易去增减服务器，我们目前是5台服务器做一组hash.我们现在用PythOn写的WebSerVer,在效率方面，我可以给个测试数据，根据目
16、前的访问日志模拟访问测试的结果是1台ypws,平均每秒处理294个请求（加载所有的逻辑判断）。在可靠性上，还不没具体的数据，目前运行1个多月还没有任何异常。IVS每个节点上都装nginx,主要是为了反向代理及处理静态内容，不过apache已显得不是那么必需，准备逐渐去掉。我们处理图片都是即时的，我们目前半数以上的服务器都装了magickd服务，用来分担图片处理请求。:/每天数以千万计的Blog内容中，实时的热点是什么？Tailrank这个Web2.0Startup致力于答复这个问题。专门爆料网站架构的TOddHOff对KeVinBUrton进展了采访。于是我们能了解一下TaiIrank架构的一
17、些信息。每小时索引2400万的Blog与Feed,内容处理能力为160-200MbPS,IO写入大约在10-15MBps每个月要处理52T之多的原始数据。Tailrank所用的爬虫现在已经成为一个独立产品：sinn3ro服务器硬件目前大约15台服务器，CPU是64位的OPteron。每台主机上挂两个SATA盘，做RAID0,据我所知，国内很多Web2.0公司也用的是类似的方式，SATA盘容量达，低廉价格，堪称不二之选。操作系统用的是DebianLinuxCWeb服务器用Apache2.0,Squid做反向代理服务器。数据库Tailrank用MySQL数据库，联邦数据库形式。存储引擎用InnoD
18、B,数据量500GBoKevinBurton也指出了MySQL5在修了一些多核模式下互斥锁的问题(国里?)。到数据库的JDBC驱动连接池用IbDOOl做负载均衡。MySQLSlave或者MaSter的复制用MySOLSlaVeSynC来轻松完成。不过即使这样，还要花费20%的时间来折腾DBo其他开放的软件任何一套系统都离不开适宜的Profiling工具，Tailrank也不利外，针对Java程序的Benchmark用BenChmark4iLog工具用LOg5i(不是Log4j)Tailrank所用的大局部工具都是开放的。Tailrank的一个比较大的竞争对手是Techmeme,虽然二者暂时看面
19、向内容的侧重点有所不同。其实，最大的对手还是自己，当需要挖掘的信息量越来越大，如果精准并及时的呈现给用户内容的成本会越来越高。从现在来看，Tailrank离预期目标还差的很远。期待罗马早日建成:hideto.iavaeyeblogl29726YoilTUbe架构学习关键字:YouTube原文:YOUTUbeArChiteCtiIreYOUTUbe开展迅速，每天超过1亿的视频点击量，但只有很少人在维护站点和确保伸缩性。平台ApachePython1.inux(SuSe)MySQLPSyC0,一个动态的Python到C的编译器Iigd代替Apache做视频查看状态支持每天超过1亿的视频点击量成立于
20、2005年2月于2006年3月到达每天3千万的视频点击量于2006年7月到达每天1亿的视频点击量2个系统管理员，2个伸缩性软件架构师2个软件开发工程师，2个网络工程师，IjDBA处理飞速增长的流量Java代码1.while(true)2(3. identify_and_fix_bottlenecks();4. drink();5. sleep();6. notice_new_bottleneck();7.每天运行该循环屡次Web服务器1,NetSCaIer用于负载均衡和静态内容缓存2,使用mod_fast_cgi运行Apache3,使用一个Python应用服务器来处理请求的路由4,应用服务器与
21、多个数据库和其他信息源交互来获取数据和格式化html页面5, 一般可以通过添加更多的机器来在Web层提高伸缩性6, Python的Web层代码通常不是性能瓶颈，大局部时间阻塞在RPC7, Python允许快速而灵活的开发和部署8,通常每个页面服务少于100亳秒的时间9,使用PSyCO（一个类似于JlT编译器的动态的Python到C的编译器）来优化内部循环10,对于像加密等密集型CPU活动，使用C扩展Ib对于一些开销昂贵的块使用预先生成并缓存的html12,数据库里使用行级缓存13,缓存完整的PythOn对象14,有些数据被计算出来并发送给各个程序，所以这些值缓存在本地内存中。这是个使用不当的策
22、略。应用服务器里最快的缓存将预先计算的值发送给所有服务器也花不了多少时间。只需弄一个代理来监听更改，预计算，然后发送。视频服务1,花费包括带宽，硬件和能源消耗2,每个视频由一个迷你集群来host,每个视频被超过一台机器持有3,使用一个集群意味着：-更多的硬盘来持有内容意味着更快的速度-failover.如果一台机器出故障了，另外的机器可以继续服务-在线备份4,使用Iigd作为Web服务器来提供视频服务：-Apache开销太大-使用epoll来等待多个fds-从单进程配置转变为多进程配置来处理更多的连接5,大局部流行的内容移到CDN：-CDN在多个地方备份内容，这样内容离用户更近的时机就会更高-
23、CDN机器经常内存缺乏，因为内容太流行以致很少有内容进出内存的颠簸6,不太流行的内容（每天1-20浏览次数）在许多Colo站点使用YouTube服务器-长尾效应。一个视频可以有多个播放，但是许多视频正在播放。随机硬盘块被访问-在这种情况下缓存不会很好，所以花钱在更多的缓存上可能没太大意义。-调节RAID控制并注意其他低级问题-调节每台机器上的内存，不要太多也不要太少视频服务关键点1,保持简单和廉价2,保持简单网络路径，在内容和用户间不要有太多设备3,使用常用硬件，昂贵的硬件很难找到帮助文档4,使用简单而常见的工具，使用构建在LinUX里或之上的大局部工具5,很好的处理随机查找(SATA,twe
24、aks)缩略图服务1.做到高效令人惊奇的难2,每个视频大概4张缩略图，所以缩略图比视频多很多3,缩略图仅仅host在几个机器上4,持有一些小东西所遇到的问题：-OS级别的大量的硬盘查找和inode和页面缓存问题-单目录文件限制，特别是Ext3,后来移到多分层的构造。内核2.6的最近改进可能让Ext3允许大目录，但在一个文件系统里存储大量文件不是个好主意-每秒大量的请求，因为Web页面可能在页面上显示60个缩略图-在这种高负载下Apache表现的非常糟糕-在APaChe前端使用SqUid,这种方式工作了一段时间，但是由于负载继续增加而以失败告终。它让每秒300个请求变为20个-尝试使用Iigd但
25、是由于使用单线程它陷于困境。遇到多进程的问题，因为它们各自保持自己单独的缓存- 如此多的图片以致一台新机器只能接收24小时- 重启机器需要6-10小时来缓存5,为了解决所有这些问题YOUTUbe开场使用GOOgIe的BigTabIe,一个分布式数据存储：- 防止小文件问题，因为它将文件收集到一起-快，错误容忍- 更低的延迟，因为它使用分布式多级缓存，该缓存与多个不同Colk)CatiOn站点工作-更多信息参考GoOgIeArcliitecture,GOOgleTaIkArChiteCtUre密IBigTabIC数据库1,早期-使用MySQL来存储元数据，如用户，tags和描述-使用一整个10硬
26、盘的RAID10来存储数据-依赖于信用卡所以YoUTUbe租用硬件-YouTube经过一个常见的革命：单服务器，然后单master和多readslaves,然后数据库分区，然后Sharding方式-痛苦与备份延迟。master数据库是多线程的并且运行在一个大机器上所以它可以处理许多工作，slaves是单线程的并且通常运行在小一些的服务器上并且备份是异步的，所以slaves会远远落后于master-更新引起缓存失效，硬盘的慢I/O导致慢备份-使用备份架构需要花费大量的money来获得增加的写性能-YouTube的一个解决方案是通过把数据分成两个集群来将传输分出优先次序：一个视频查看池和一个一般的
27、集群2,后期-数据库分区-分成shards,不同的用户指定到不同的shards-扩散读写-更好的缓存位置意味着更少的IO-导致硬件减少30%-备份延迟降低到O-现在可以任意提升数据库的伸缩性数据中心策略1,依赖于信用卡，所以最初只能使用受管主机提供商2,受管主机提供商不能提供伸缩性，不能控制硬件或使用良好的网络协议3,YouTube改为使用colocationarrangement现在YOUTUbe可以自定义所有东西并且协定自己的契约4,使用5到6个数据中心加CDN5,视频来自任意的数据中心，不是最近的匹配或其他什么。如果一个视频足够流行那么移到CDN6,依赖于视频带宽而不是真正的延迟。可以来
28、自任何COIO7,图片延迟很严重，特别是当一个页面有60张图片时8,使用BigTable将图片备份到不同的数据中心，代码查看谁是最近的学到的东西1, Stallfortimeo创造性和风险性的技巧让你在短期内解决问题而同时你会发现长期的解决方案2, Proioritizeo找出你的服务中核心的东西并对你的资源分出优先级别3, Pickyourbattleso别怕将你的核心服务分出去。YOUTUbe使用CDN来分布它们最流行的内容。创立自己的网络将花费太多时间和太多money4, Keepitsimple!简单允许你更快的重新架构来回应问题5, ShardoSharding帮助隔离存储，CPU,
29、内存和10,不仅仅是获得更多的写性能6, Constantiterationonbottlenecks：- 软件：DB,缓存- OS：硬盘I/O- 硬件：内存，RAID7, YOUSUCCeedaSateam。拥有一个跨越条律的了解整个系统并知道系统内部是什么样的团队，如安装打印机，安装机器，安装网络等等的人Withagoodteamallthingsarepossible,:/hidetoJavaeyeblog130815G。RIe架构学习关键字:Google原文：GoOgleArChiteCtUreGoogle是伸缩性的王者。Google一直的目标就是构建高性能高伸缩性的根基组织来支持它们
30、的产品。平台1.inux大量语言：Python,Java,C+状态在2006年大约有450,000台廉价服务器在2005年Google索引了80亿Web页面，现在没有人知道数目目前在GoOgle有超过200个GFS集群。一个集群可以有IOoo或者甚至5000台机器。成千上万的机器从运行着5000000000000000字节存储的GFS集群获取数据，集群总的读写吞吐量可以到达每秒40兆字节目前在Google有6000个MapReduce程序，而且每个月都写成百个新程序BigTable伸缩存储几十亿的URL,几百千千兆的卫星图片和几亿用户的参数选择堆栈Google形象化它们的根基组织为三层架构：1
31、,产品：搜索，广告，email,地图，视频，聊天，博客2,分布式系统根基组织：GFS,MaPRedUCe和BigTable3,计算平台：一群不同的数据中心里的机器4,确保公司里的人们部署起来开销很小5,花费更多的钱在防止丧失日志数据的硬件上，其他类型的数据那么花费较少可信赖的存储机制GFS(GoogleFileSystem)1,可信赖的伸缩性存储是任何程序的核心需求。GFS就是GOogIe的核心存储平台2,GoogleFileSystem-大型分布式构造化日志文件系统，GOOgle在里面扔了大量的数据3,为什么构建GFS而不是利用已有的东西因为可以自己控制一切并且这个平台与别的不一样，Goog
32、le需要：-跨数据中心的高可靠性-成千上万的网络节点的伸缩性-大读写带宽的需求-支持大块的数据，可能为上千兆字节-高效的跨节点操作分发来减少瓶颈4,系统有Master和Chunk服务器-MaSter服务器在不同的数据文件里保持元数据。数据以64MB为单位存储在文件系统中。客户端与Master服务器交流来在文件上做元数据操作并且找到包含用户需要数据的那些ChUnk服务器-Chunk服务器在硬盘上存储实际数据。每个Chunk服务器跨越3个不同的Chunk服务器备份以创立冗余来防止服务器崩溃。一旦被MaSter服务器指明，客户端程序就会直接从ChUnk服务器读取文件6,一个上线的新程序可以使用己有的
33、GFS集群或者可以制作自己的GFS集群7,关键点在于有足够的根基组织来让人们对自己的程序有所选择，GFS可以调整来适应个别程序的需求使用MapReduce来处理数据1,现在你已经有了一个很好的存储系统，你该怎样处理如此多的数据呢比方你有许多TB的数据存储在1000台机器上。数据库不能伸缩或者伸缩到这种级别花费极大，这就是MaPRedUCe出现的原因2,M叩RedUCe是一个处理和生成大量数据集的编程模型和相关实现。用户指定一个map方法来处理一个键/值对来生成一个中间的键/值对，还有一个reduce方法来合并所有关联到同样的中间键的中间值。许多真实世界的任务都可以使用这种模型来表现。以这种风格
34、来写的程序会自动并行的在一个大量机器的集群里运行。运行时系统照顾输入数据划分、程序在机器集之间执行的调度、机器失败处理和必需的内部机器交流等细节。这允许程序员没有多少并行和分布式系统的经历就可以很容易使用一个大型分布式系统资源3,为什么使用MapReduce-跨越大量机器分割任务的好方式-处理机器失败.可以与不同类型的程序工作，例如搜索和广告。几乎任何程序都有m叩和reduce类型的操作。你可以预先计算有用的数据、查询字数统计、对TB的数据排序等等4,MapReduce系统有三种不同类型的服务器-MaSter服务器分配用户任务到Map和Reduce服务器。它也跟踪任务的状态-Map服务器接收用
35、户输入并在其根基上处理map操作。结果写入中间文件-Reduce服务器接收Map服务器产生的中间文件并在其根基上处理reduce操作5,例如，你想在所有Web页面里的字数。你将存储在GFS里的所有页面抛入MaPRedUce。这将在成千上万台机器上同时进展并且所有的调整、工作调度、失败处理和数据传输将自动完成-步骤类似于：GFS-Map-Shuffle-Reduction-StoreResultsbackintoGFS-在M叩RedUCe里一个map操作将一些数据映射到另一个中，产生一个键值对，在我们的例子里就是字和字数-ShUffling操作聚集键类型-Reduction操作计算所有键值对的综
36、合并产生最终的结果6,Google索引操作管道有大约20个不同的map和reduction。7,程序可以非常小，如20到可行代码8,一个问题是落伍者。落伍者是一个比其他程序慢的计算，它阻塞了其他程序。落伍者可能因为缓慢的10或者临时的CPU不能使用而发生。解决方案是运行多个同样的计算并且当一个完成后杀死所有其他的9,数据在M叩和Reduce服务器之间传输时被压缩了。这可以节省带宽和I/O。在BigTabIe里存储构造化数据1, BigTabIe是一个大伸缩性、错误容忍、自管理的系统，它包含千千兆的内存和100oOOOOOOooOOoO的存储。它可以每秒钟处理百万的读写2, BigTabIe是一
37、个构建于GFS之上的分布式哈希机制。它不是关系型数据库。它不支持join或者SQL类型查询3,它提供查询机制来通过键访问构造化数据。GFS存储存储不透明的数据而许多程序需求有构造化数据4,商业数据库不能到达这种级别的伸缩性并且不能在成千上万台机器上工作5,通过控制它们自己的低级存储系统Google得到更多的控制权来改进它们的系统。例如，如果它们想让跨数据中心的操作更简单这个特性，它们可以内建它6,系统运行时机器可以自由的增删而整个系统保持工作7,每个数据条目存储在一个格子里，它可以通过一个行key和列key或者时间戳来访问8,每一行存储在一个或多个tablet中。一个tablet是一个64KB
38、块的数据序列并且格式为SSTable9,BigTabIe有三种类型的服务器：-Master服务器分配tablet服务器，它跟踪tablet在哪里并且如果需要那么重新分配任务-Tablet服务器为tablet处理读写请求。当tablet超过大小限制（通常是100MB-200MB）时它们拆开tableto当一个Tablet服务器失败时，那么100个Tablet服务器各自挑选一个新的tablet然后系统恢匏。-Lock服务器形成一个分布式锁服务。像翻开一个tablet来写、Master调整和访问控制检查等都需要互斥10,一个locality组可以用来在物理上将相关的数据存储在一起来得到更好的loca
39、lity选择11,tablet尽可能的缓存在RAM里硬件1,当你有很多机器时你怎样组织它们来使得使用和花费有效2,使用非常廉价的硬件3, A1,000-foldcomputerpowerincreasecanbehadfora33timeslowercostifyouyouuseafailure-proneinfrastructureratherthananinfrastructurebuiltonhighlyreliablecomponents.Youmustbuildreliabilityontopofunreliabilityforthisstrategytowork.4, 1.inux
40、,in-houserackdesign,PC主板，低端存储5, Priceperwattageonperformancebasisisntgettingbetter.Havehugepowerandcoolingissues6,使用一些collocation和Google自己的数据中心其他1,迅速更改而不是等待QA2,库是构建程序的卓越方式3, 一些程序作为服务提供4, 一个根基组织处理程序的版本，这样它们可以发布而不用害怕会破坏什么东西Google将来的方向1,支持地理位置分布的集群2,为所有数据创立一个单独的全局名字空间。当前的数据由集群别离3,更多和更好的自动化数据迁移和计算4,解决当使
41、用网络划分来做广阔区域的备份时的一致性问题（例如保持服务即使一个集群离线维护或由于一些损耗问题）学到的东西1,根基组织是有竞争性的优势。特别是对GoogIe而言。GOogIe可以很快很廉价的推出新服务，并且伸缩性其他人很难到达。许多公司采取完全不同的方式。许多公司认为根基组织开销太大,Google认为自己是一个系统工程公司，这是一个新的对待软件构建的方式2,跨越多个数据中心仍然是一个未解决的问题。大局部网站都是一个或者最多两个数据中心。我们不得不成认怎样在一些数据中心之间完整的分布网站是很需要技巧的3,如果你自己没有时间从零开场重新构建所有这些根基组织你可以看看旦也心。HadOoP是这里很多同
42、样的主意的一个开源实现4,平台的一个优点是初级开发人员可以在平台的根基上快速并且放心的创立健全的程序。如果每个工程都需要创造同样的分布式根基组织的轮子，那么你将陷入困境因为知道怎样完成这项工作的人相对较少5,协同工作不一直是掷骰子。通过让系统中的所有局部一起工作那么一个局部的改进将帮助所有的局部。改进文件系统那么每个人从中受益而且是透明的。如果每个工程使用不同的文件系统那么在整个堆栈中享受不到持续增加的改进6,构建自管理系统让你没必要让系统关机。这允许你更容易在服务器之间平衡资源、动态添加更大的容量、让机器离线和优雅的处理升级7,创立可进化的根基组织，并行的执行消耗时间的操作并采取较好的方案8
43、,不要忽略学院。学院有许多没有转变为产品的好主意。MostofwhatGooglehasdonehaspriorart,justnotpriorlargescaledeployment.9,考虑压缩。当你有许多CPU而10有限时压缩是一个好的选择。OZblogdaviesI1.igd+Squid+Apache搭建高效率Web服务器架构原理ADaChe通常是开源界的首选Web服务器,因为它的强大和可靠，已经具有了品牌效应，可以适用于绝大局部的应用场合。但是它的强大有时候却显得笨重，配置文件得让人望而生畏，高并发情况下效率不太高。而轻量级的Web服务器Ligd却是后起之秀,其静态文件的响应能力远高
44、于APaChe,据说是Apache的2-3倍。Ligd的高性能和易用性，足以打动我们，在它能够胜任的领域，尽量用它。Ligd对PHP的支持也很好，还可以通过FaStCgi方式支持其他的语言，比方Python。毕竟Ligd是轻量级的服务器，功能上不能跟APaChe比，某些应用无法胜任。比方Ligd还不支持缓存，而现在的绝大局部站点都是用程序生成动态内容，没有缓存的话即使程序的效率再高也很难满足大访问量的需求，而且让程序不停的去做同一件事情也实在没有意义。首先，Web程序是需要做缓存处理的，即把反复使用的数据做缓存。即使这样也还不够，单单是启动Web处理程序的代价就不少，缓存最后生成的静态页面是必
45、不可少的。而做这个是SaUid的强项,它本是做代理的，支持高效的缓存，可以用来给站点做反向代理加速。把Squid放在Apache或者Ligd的前端来缓存Web服务器生成的动态内容，而Web应用程序只需要适当地设置页面实效时间即可。即使是大局部内容动态生成的网站，仍免不了会有一些静态元素，比方图片、JS脚本、CSS等等，将Squid放在APaChe或者Lig前端后，反而会使性能下降，毕竟处理请求是Web服务器的强项。而且已经存在于文件系统中的静态内容再在Squid中缓存一下，浪费内存和硬盘空间。因此可以考虑将Ligd再放在SqUid的前面，构成Ligd+Squid+Apache的一条处理链，Ligd在最前面，专门用来处理静态内容的请求，把动态内容请求通过proxy模块转发给Squid,如果Squid中有该请求的内容且没有过期,那么直接返回给Ligd。新请求或者过期的页面请求交由Apache中Web程序来处理。经过Ligd和SqUid的两级过滤，APaChe需要处理的请求将大大减少，减少了Web应用程序的压力。同时这样的构架，便于把不同的处理分散到多台计算机上进展，由Ligd在前面统一把关。在这种架构下，每一级都是可以进展单独优化的，比方Ligd可以采用异步IO方式，SqUid可以启用内存来缓存，APaChe可以启用MPM等，并且每一级都可以使用多台机器来均衡负载，伸缩性很好。
