网站架构演变

单击此处编辑母版标题样式,*,*,*,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,网站架构演变,-,老代,2010-4,客户端与服务器端的对立,“客户端”与“服务器端”，从技术上来说就是一个相互对立的战争。初期，网站访问量较小，弄几台服务器随便拉起一只队伍，就能抵抗住客户端的访问。慢慢的，访问量大起来，这时候，就需要讲究战略战术、多兵种协调作战。于是，开始有了负载均衡服务器、,Web,服务器、缓存服务器、数据库服务器、存储服务器等多兵种；开始有了系统架构等战略战术。随着新项目和运营需求的越来越多，网站就需要多线作战。,高性能的,web,服务器,Nginx,软件并发,700,左右,数据库的并发,架构演变第一步,物理分离应用程序和数据库,架构演变第二步,增加反向代理缓存（前端页面缓存）,代表：,squid,、,varnish,主要作用：将页面、图片、,css,放入到后端服务器前面，用户访问直接到反向代理缓存取页面、图片、,css,等数据，减少对后端的压力。,会出现问题：命中率提高？,更新时间策略？,哪些需要穿透？,架构演变第三步,增加数据缓存层,代表：,memcache,、,tt,、,tair,等,.,主要作用：将大量多次使用的信息或压力比较大的表整体推送进入该层，减少对数据库的压力，提高程序的响应速度。,需要考虑的问题：命中率？,使用策略？,数据持久化？,高并发下的读写速度？,数据库缓存分类,一般数据库缓存分为四种,1,、,Key/Value,单个对象缓存，技术不难，,Memcached,、,Squid,均能实现。,2,、列表缓存，就像论坛里帖子的列表、,SNS,中的,Feed,信息，要求实时更新。,3,、记录条数的缓存，比如一个论坛板块里有多少,个帖子，这样才方便实现分页。,4,、复杂一点的,group,，,sum,，,count,查询等数据库的运算，比如一个论坛里按点击数排名的最,HOT,的帖子列表。,架构演变第四步,组建,web,集群,问题：多服务器的负载均衡策略？,多服务器的如何保持用户状态信息的同步？数据缓存策略改变不？,多服务器文件、图片上传策略？,多服务器内容同步策略？,架构演变第五步,增加数据库集群,问题：选择数据库集群模型和分库策略？,数据的集中存储？分布式存储？,数据库的代理层？,随着数据量的增大和分库的进行，在数据库的设计、调优以及,维护上要非常细化。,架构演变第六步,增加缓存集群,选择缓存集群模型和策略？,缓存集群的代理层？,分布策略？,MYSQL,数据库的架构,MYSQL,数据库的架构,最上面一层包含的服务不是,MySQL,所独有的。它是多数基于网络的客户端,/,服务器工具或者服务所需要的：连接处理、鉴权、安全等等。,MySQL,的重要组件都在这部分，包括查询的解析、分析、优化、缓存以及其他所有的内置函数,(,如日期函数，时间函数，数学函数以及加密函数等,),。另外所有存储引擎所共有的功能也都在这一层，比如存储过程、触发器、视图等。,第三层包括了存储引擎。存储引擎负责在,MySQL,中存储和获取数据。服务器通过存储引擎,API,来与存储引擎进行交互。这个接口隐藏了各个存储引擎之间实现上的差异，并且很大程度上使得存储引擎与查询层分开。,MYSQL,数据库储存引擎,具体的案例,服务器端开发语言主要是,PHP,和,c,，其中,PHP,用于编写,Web,逻辑（通过,HTTP,和用户直接打交道）， 而,c,则主要用于开发内部服务和后台任务。,由于,PHP,的单线程模型，我们把耗时较久的运算和,I/O,操作从,HTTP,请求周期中分离出来， 交给由,c,实现的任务进程来完成，以保证请求响应速度。这些任务主要包括：邮件发送、数据索引、数据聚合和好友动态推送（稍候会有介绍）等等。通常这些任务由用户触发，并且，用户的一个行为可能会触发多种任务的执行。 比如，用户上传了一张新的照片，我们需要更新索引，也需要向他的朋友推送一条新的动态。,PHP,通过消息队列来触发任务执行。,PHP,和,c,的协作,数据库一向是网站架构中最具挑战性的，瓶颈通常出现在这里。,Web2.0,数据量通常很大，数据库也长期出现严重的压力问题。,因此，这里我主要介绍一下,web2.0,在分库设计这方面的一些尝试。,分库设计,和很多使用,MySQL,的,2.0,站点一样，一般的,MySQL,集群经历了从最初的一个主库一个从库、到一个主库多个从库、 然后到多个主库多个从库的一个发展过程。,最初是由一台主库和一台从库组成，当时从库只用作备份和容灾，当主库出现故障时，从库就手动变成主库，一般情况下，从库不作读写操作（同步除外）。随着压力的增加，我们加上了,memcached,，当时只用其缓存单行数据。 但是，单行数据的缓存并不能很好地解决压力问题，因为单行数据的查询通常很快。所以我们把一些实时性要求不高的,Query,放到从库去执行。后面又通过添加多个从库来分流查询压力，不过随着数据量的增加，主库的写压力也越来越大。,我们决定进行数据库拆分。也就是将数据存放到不同的数据库服务器中，一般可以按两个纬度来拆分数据,:,垂直拆分、水平拆分,。,拆分方式不同,垂直拆分,：是指按功能模块拆分，比如可以将群组相关表和照片相关表存放在不同的数据库中，这种方式多个数据库之间的,表结构不同,。,水平拆分,：而水平拆分是将同一个表的数据进行分块保存到不同的数据库中，这些数据库中的,表结构完全相同,。,拆分方式,一般都会先进行垂直拆分，因为这种方式拆分方式实现起来比较简单，根据表名访问不同的数据库就可以了。但是垂直拆分方式并不能彻底解决所有压力问题，另外，也要看应用类型是否合适这种拆分方式。如果合适的话，也能很好的起到分散数据库压力的作用。核心业务对象是什么？,拆分规则,水平拆分实现起来相对复杂，我们要先确定一个拆分规则，也就是按什么条件将数据进行切分。 一般,2.0,网站都以用户为中心，数据基本都跟随用户，比如用户的照片、朋友和评论等等。因此一个比较自然的选择是根据用户来切分。每个用户都对应一个数据库，访问某个用户的数据时， 我们要先确定他,/,她所对应的数据库，然后连接到该数据库进行实际的数据读写。,那么，怎么样对应用户和数据库呢？我们有这些选择：,拆分规则,按算法对应,最简单的算法是按用户,ID,的奇偶性来对应，将奇数,ID,的用户对应到数据库,A,，而偶数,ID,的用户则对应到数据库,B,。这个方法的最大问题是，只能分成两个库。另一个算法是按用户,ID,所在区间对应，比如,ID,在,0-10000,之间的用户对应到数据库,A,，,ID,在,10000-20000,这个范围的对应到数据库,B,，以此类推。按算法分实现起来比较方便，也比较高效，但是不能满足后续的伸缩性要求，如果需要增加数据库节点，必需调整算法或移动很大的数据集， 比较难做到在不停止服务的前提下进行扩充数据库节点。,拆分规则,按索引,/,映射表对应,这种方法是指建立一个索引表，保存每个用户的,ID,和数据库,ID,的对应关系，每次读写用户数据时先从这个表获取对应数据库。新用户注册后，在所有可用的数据库中随机挑选一个为其建立索引。这种方法比较灵活，有很好的伸缩性。一个缺点是增加了一次数据库访问，所以性能上没有按算法对应好。,比较之后，我们采用的是索引表的方式，我们愿意为其灵活性损失一些性能，更何况我们还有,memcached,等， 因为索引数据基本不会改变的缘故，缓存命中率非常高。所以能很大程度上减少了性能损失。,拆分规则,索引表的方式能够比较方便地添加数据库节点，在增加节点时，只要将其添加到可用数据库列表里即可。 当然如果需要平衡各个节点的压力的话，还是需要进行数据的迁移，但是这个时候的迁移是少量的，可以逐步进行。要迁移用户,A,的数据，首先要将其状态置为,迁移数据中,，这个状态的用户不能进行写操作，并在页面上进行提示。 然后将用户,A,的数据全部复制到新增加的节点上后，更新映射表，然后将用户,A,的状态置为,正常,，最后将原来对应的数据库上的数据删除。这个过程通常会在临晨进行，所以，所以很少会有用户碰到,迁移数据中,的情况。,当然，有些数据是不属于某个用户的，比如系统消息、配置等等，我们把这些数据保存在一个全局库中。,带来的问题,分库会给你在应用的开发和部署上都带来很多麻烦。,不能执行跨库的关联查询,不能保证数据的一致,/,完整性,所有查询必须提供数据库线索,自增,ID,谢谢！,