大型网站演变剖析.pptVIP

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 架构演变第五步： 增加webserver 这一步涉及到了不少的知识体系： 负载均衡技术：包括但不限于硬件负载均衡、软件负载均衡、负载算法、linux转发协议、所选用的技术的实现细节等。 目前负载均衡较多的是F5和Apache自带的负载均衡方案。 主备技术：包括但不限于ARP欺骗、linux heart-beat等，heart-beat技术比较普遍，用户探测哪些服务器可用。 状态信息或缓存同步技术：包括但不限于Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等。在服务器压力大的情况的Cookie技术是个不错的选择。 共享文件技术：包括但不限于NFS等，分布式文件系统，一般多采用GFS的架构 。 存储技术：包括但不限于存储设备等。 架构演变第六步 享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢？ 经过查找，发现数据库写入、更新的这些操作的部分数据库连接的 资 源竞争非常激烈，导致了系统变慢。也就是说所有的表放在一个数据库中导致数据库IO竞争过高，数据库响应变慢了。 这下怎么办呢?? 架构演变第六步：分库 可选的方案有数据库集群和分库策略，集群方面像有些数据库支持的并不是很好，因此分库会成为比较普遍 的策略，分库也就意味着要对原有程序进行修改，一通修改实现分库后，不错，目标达到了，系统恢复甚至速度比以前还快了。 分库主要要做的工作就是把逻辑上独立的一些表放到不同机器上的数据库中去，应用程序分别按照需要从不同的数据库中获取数据。例如DB1存放用户信息数据，DB2存放产品数据，DB3存放订单数据… 分库过程要修改原有的应用程序，需要修改逻辑代码，因此一定要仔细。 架构演变第六步：分库 这一步涉及到了这些知识体系： 这一步更多的是需要从业务上做合理的划分，以实现分库，具体技术细节上没有其他的要求； 但同时随着数据量的增大和分库的进行，在数据库的设计、调优以及维护上需要做的更好，因此对这些方面的技术还是提出了很高的要求的。 架构演变第七步：分表、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的软