搜索
大型网站架构专题顾费勇(lieying0772@yahoo.com.cn)本次培训内容1.大型网站有何不同2.大型网站架构演变分析大型网站设计是门艺术一、大型网站有何不同大型网站特点：1.大量并发用户请求2.超大容量数据Flickr网站(最受欢迎的照片共享网站)。每天多达40亿次的查询请求。squid总计约有3500万张照片（硬盘+内存）。squid内存中约有200万张照片。总计有大约4亿7000万张照片，每张图片又生成不同尺寸大小的4－5份图片。每秒38，000次Memcached请求(Memcached总共存储了1200万对象)。超过2PB存储，其中数据库12TB。每天新增图片超过40万（周日峰值超过200万，约1.5TB)。超过8百50万注册用户。超过1千万的唯一标签（tags)1.如果这个网站要你设计你会怎么做？2.有哪些问题？3.应该怎么解决?需要考虑的问题1.服务器能撑住那么大请求量吗？2.如何存储照片3.如何快速读取出照片4.数据库能顶住压力吗？5.查询速度会不会太慢6.这么大量的请求IO吃得消吗？7.内存会不会出现问题。。。。我们学生现在的系统架构我们现在的系统架构比较简单：1.Tomcat/Weblogic+Mysql+Java代码2.所有东西都部署在一台机器上3.无论动态内容还是静态内容都由tomcat/weblogic来处理4.所有静态文件也都放在和tomcat/weblogic服务器同一台机器上现有框架存在的问题我们的系统架构是一般的小型网站都会这么采取的架构，结构简单资源也很省，开发方便。由于并发访问次数少，也不太有性能问题。但是一旦要做成一个大型网站，问题就接踵而来了。这样的框架最多能支持每秒几十个的请求，多点就可能会非常非常慢或者停止响应。显然与大型网站的要求还相差甚远。有人可能会问，性能不行买好的服务器有超强CPU、超大内存、超大硬盘，不就可以了吗？貌似可行，但是实际上不太可能这么做。第一点这样的机器非常非常贵，购买几十台普通服务器了。第二点性能提升也不明显。第三点，以后难以扩展，如果需求更多了是不是就要买更贵的服务器啊？Flckr系统架构图Flckr系统架构PairofServerIron's－LoadBalancerSquidCaches－反向代理，用于缓存静态的HTML和照片NetApp'－NetApp公司的Filer,NAS存储设备，用于存储照片PHPAppServers－运行REDHATLINUX,Apache上的PHP应用，Flickr网站的主体是大约6万行PHP代码－没有使用PHPsession,应用是stateless,便于扩展，并避免PHPServer故障所带来的Session失效。－每个页面有大约27～35个查询（不知道为什么这么设计，个人觉得没有必要）－另有专门的ApacheWebFarm服务于静态文件（HTML和照片）的访问Flckr系统架构StorageManager－运行私有的，适用于海量文件存储的FlickrFileSystemDualTreeCentralDatabase－MySQL数据库，存放用户表，记录的信息是用户主键以及此用户对以的数据库Shard区，从中心用户表中查出用户数据所在位置，然后直接从目标Shard中取出数据。－“DualTree架构是”Master－Master和“Master-Slave的有效结合，双Master避免了“单点故障”，Master－Slave又提高了读取速度，因为用户表的操作90％以上是读。Master-mastershards－MySQL数据库，存储实际的用户数据和照片的元数据（MetaData)，每个Shard大约40万个用户，120GB数据。每个用户的所有数据存放在同一个shard中。－Shard中的每一个server的负载只是其可最大负载的50％，这样在需要的时候可以Online停掉一半的server进行升级或维护而不影响系统性能。－为了避免跨Shard查询所带来的性能影响，一些数据有在不同的Shard有两份拷贝，比如用户对照片的评论，通过事务来保证其同步。Flckr系统架构MemcachedCluster－中间层缓存服务器，用于缓存数据库的SQL查询结果等。BigSearchEngine-复制部分Shard数据（Owner’ssingletag）到SearchEngineFarm以响应实时的全文检索。-其他全文检索请求利用Yahoo的搜索引擎处理（Flickr是Yahoo旗下的公司）服务器的硬件配置：-Intel或AMD64位CPU，16GBRAM-6-disk15KRPMRAID-10.-2Uboxes.服务器数量：(数据来源：April2008MySQLConference&Expo)166DBservers,244webservers(不知道是否包括squidserver？),14Memcachedservers二、大型网站架构演化没有任何一个网站一开始就是这么复杂的结构都是从简单结构一步步演化而来的包括Ebay,Facebook,Taobao等刚开始都没有考虑到他们能有今天的访问量以及数据量。他们是怎么演化过来的呢？我们一起来看一下大型网站的演化历程架构演变第一步假设现在有一个小网站就说aowin.com吧。他是一个门户网站。托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问。刚开始一切都很好，流量不大，系统响应也正常。但过了一段时间之后，由于网站运营地很不错，访问的人越来越多，你逐渐发现你的系统压力越来越高，响应越来越慢了。你经过分析发现，这个时候比较明显的是数据库和你的应用相互影响。应用出问题了，数据库也很容易受影响；当数据库出问题的时候，应用也很容易受影响。架构演变第一步：物理分离webserver和数据库既然发现了问题，接下来我们来解决它。于是进入了第一步演变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。这一步架构演变对技术上的知识体系基本没有要求。架构演变第二步好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了。查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连接又不能开太多，否则数据库机器压力会很高也就是说我们最好能够减少数据库访问的连接数，但又不能影响用户体验。怎么办呢？架构演变第二步：增加页面缓存于是想到了缓存考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够很好的减少对webserver的压力以及减少数据库连接资源的竞争，这一步涉及到了这些知识体系：前端页面缓存技术，例如squid，如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等K，于是开始采用squid来做相对静态的页面的缓存。架构演变第三步增加了squid做缓存后，整体系统的速度确实是提升了，webserver的压力也开始下降了，但随着访问量的增加，发现系统又开始变的有些慢了毕竟一个网站的静态页面还是有限，能够被缓存的请求数量也不够多，系统的绝大部分页面还是动态页面。能够被有效缓存的大部分是图片、js、css等静态内容。比如今天我页面上有一块地方是个人档案，这个内容基本两三个月才更新一次，缓存起来效果会很好。但是页面其他内容是动态从数据库中加载的，我们不能把整个页面交给squid来缓存。怎么办呢？架构演变第三步：增加页面片段缓存考虑采用类似ESI之类的页面片段缓存策略，OK，于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。这一步涉及到了这些知识体系：页面片段缓存技术，例如ESI等，想用好的话同样需要掌握ESI的实现方式等；ESI参考资料：架构演变第四步在采用ESI之类的技术再次提高了系统的缓存效果后，系统的压力确实进一步降低了。系统变快了，很高兴。但同好景不长，随着访问量的增加，系统又开始变慢。这回又是什么原因呢？经过查找，可能会发现系统中存在一些重复获取数据信息的地方，像获取用户信息等。比如一个用户登录系统后会有很多地方需要去加载这个用户的个人信息，一个用户在进入一个查询界面前可能加载了4-5次个人信息。这些在用户并发访问量小的时候是看不出来的，因为数据库读取速度很快，所以用户不太受影响。但访问量一大，数据库撑不住了，问题就来了。怎么解决这个问题呢？架构演变第四步：数据缓存这个时候开始考虑是不是可以将这些数据信息也缓存起来呢。于是将这些数据缓存到本地内存，改变完毕后，完全符合预期，系统的响应速度又恢复了，数据库的压力也再度降低了不少。架构演变第四步：数据缓存数据缓存是什么意思呢？简单来说就是就是当你要获取数据，譬如个人信息，首先你先从缓存读取，如果缓存中没有该数据或者数据已过期，你再从数据库中读取，读取后再更新到缓存。这一步涉及到了这些知识体系：缓存技术，包括像Map数据结构、缓存算法、所选用的框架本身的实现机制等。大家可以参考hibernate的缓存机制，原理基本上是类似的。架构演变第五步:增加webserver好景不长，发现随着系统访问量的再度增加，系统又慢了。查找原因吧。发现webserver机器的压力在高峰期会上升到比较高，也就是说单台webserver已经无法支持住目前的访问量了。这个时候开始考虑增加一台webserver，这也是为了同时解决可用性的问题，避免单台的webserverdown机的话就没法使用了，在做了这些考虑后，决定增加一台webserver架构演变第五步:增加webserver增加一台webserver时不是那么容易加台服务器就ok。它是一个比较大的工程，会碰到很多问题，典型的有：1、如何让访问分配到这两台机器上，这个时候通常会考虑的方案是Apache自带的负载均衡方案，或LVS这类的软件负载均衡方案；2、如何保持状态信息的同步，例如用户session等，这个时候会考虑的方案有写入数据库、写入存储、cookie或同步session信息等机制等；3、如何保持数据缓存信息的同步，例如之前缓存的用户数据等，这个时候通常会考虑的机制有缓存同步或分布式缓存；4、如何让上传文件这些类似的功能继续正常，这个时候通常会考虑的机制是使用共享文件系统或存储等；架构演变第五步：增加webserver在解决了这些问题后，终于是把webserver增加为了两台，系统终于是又恢复到了以往的速度。架构演变第五步：增加webserver这一步涉及到了不少的知识体系：负载均衡技术：包括但不限于硬件负载均衡、软件负载均衡、负载算法、linux转发协议、所选用的技术的实现细节等。目前负载均衡较多的是F5和Apache自带的负载均衡方案。主备技术：包括但不限于ARP欺骗、linuxheart-beat等，heart-beat技术比较普遍，用户探测哪些服务器可用。状态信息或缓存同步技术：包括但不限于Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等。在服务器压力大的情况的Cookie技术是个不错的选择。共享文件技术：包括但不限于NFS等，分布式文件系统，一般多采用GFS的架构。存储技术：包括但不限于存储设备等。架构演变第六步享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢？经过查找，发现数据库写入、更新的这些操作的部