网站架构演变.pptVIP

网站架构演变 客户端与服务器端的对立 “客户端”与“服务器端”，从技术上来说就是一个相互对立的战争。初期，网站访问量较小，弄几台服务器随便拉起一只队伍，就能抵抗住客户端的访问。慢慢的，访问量大起来，这时候，就需要讲究战略战术、多兵种协调作战。于是，开始有了负载均衡服务器、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集群经历了从最初的一个主库一个从库、到一个主库多个从库、 然后到多个主库多个从库的一个发展过程。 最初是由一台主库和一台从库组成，当时从库只用作备份和容灾，当主库出现故障时，从库就手动变成主库，一般情况下，从库不作读写操作（同步除外）。