大型网站架构经验.ppt

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 架构演变第七步：分表、DAL和分布式缓存 随着系统的不断运行，数据量开始大幅度增长，某些表可能达到上百万甚至上千万的数据量。这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作。 分表的规则有水平分表和垂直分表两种。水平分表我们可以按照某个维度例如时间。2008-10-01至2008-12-31的放在 TABLE1,2009-01-01至2009-03-30的数据放在TABLE2,以此类推。垂直分表的话可以将表的前10列放TABLE1，后10列放TABLE2…,不过所有的垂直分开的 表要有相同的 主键。 当然，这不可避免的会需要对程序 进行一些修改，也许在这个时候就会发现应用自己要关心分库分表的规则等，还是有些复杂的，于是萌生能否增加一个通用的框架来实现分库分表的数据访问。 这个架构就是DAL（数据访问层 ? Data ? Access ? Layer），这个演变的过程相对而言需要花费较长的时间，当然，也有可能这个通用的框架会等到分表做完后才开始做，同时，在这个阶段可 能会发现之前的缓存同步方案出现问题，因为数据量太大，导致现在不太可能将缓存存在本地，然后同步的方式，需要采用分布式缓存方案了，于是，又是一通考察和折磨，终于是将大量的数据缓存转移到分布式缓存上了。 架构演变第七步：分表、DAL和分布式缓存 这一步涉及到了这些知识体系： 分表更多的同样是业务上的划分，技术上涉及到的会有动态hash算法、consistent hash算法等；DAL涉及到比较多的复杂技术，例如数据库连接的管理（超时、异常）、数据库操作的控制（超时、异常）、分库分表规则的封装等； 架构演变第八步：增加更多的webserver 在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了，突然有一天，发现系统的访问又开始有变慢的趋势 了。 这个时候首先查看数据库，压力一切正常，之后查看webserver，发现apache阻塞了很多的请求，而应用服务器对每个请求也是比较快的，看来 是请求数太高导致需要排队等待，响应速度变慢。 这块怎么处理呢？比较简单，两台server不够用嘛 ，多点不就行啦。 架构演变第八步：增加更多的webserver 一般来说，这个时候也会有些钱了，于是添加一些webserver服务器，在这个添 加 webserver服务器的过程，有可能会出现几种挑战: 1、Apache的软负载或LVS软负载等无法承担巨大的web访问量（请求连接数、网络流量等）的调度了，这个时候如果经费允许的话，会采取的方案是购 买硬件负载，例如F5、Netsclar、Athelon之类的，如经费不允许的话，会采取的方案是将应用从逻辑上做一定的分类，然后分散到不同的软负载集群中； 2、原有的一些状态信息同步、文件共享等方案可能会出现瓶颈，需要进行改进，也许这个时候会根据情况编写符合网站业务需求的分布式文件系统等；在做完这些工作后，开始进入一个看似完美的无限伸缩的时代，当网站流量增加时，应对的解决方案就是不断的添加webserver。 架构演变第八步：增加更多的webserver 架构演变第八步：增加更多的webserver 这一步涉及到了这些知识体系： 到了这一步，随着机器数的不断增长、数据量的不断增长和对系统可用性的要求越来越高。 这个时候要求对所采用的技术都要有更为深入的理解，并需要根据网站的需求来做更加定制性质的产品。 已经不是局限于单纯的某项技术了，而是各项知识、产品分析和技术的结合，要求更高了。一个人很难把这些都学会，团队合作非常重要。 架构演变第九步 突然有一天，发现这个完美的时代也要结束了，数据库的噩梦又一次出现在眼前了，由于添加的webserver太多了，导致数据库连接的资源还是不够用，而这个时候又已经分库分表了。 开始分析数据库的压力状况，可能会发现数据库的读写比很高。也就是说数据库的读比写高出很多。这意味着什么呢？ 数据库的原理相信大家也有一些了解了。数据库有索引，写数据库会有写锁，读数据有读锁。读和写在设计理念上是有冲突的。 架构演变第九步：数据读写分离和廉价存储方案 这个时候通常会想到数据读写分离的方案，当然，这个方案要实现并不容易。 另外，可能会发现一些数据存储在数据库上有些浪费，或者说过于占用数据库资源。 因此在这个阶段可能会形成的架构演变是实现数据读写分离，同时编写一些更为廉价的存储方案，例如BigTable这种。 架构演变第九步：数据读