设计高性能可扩展互动网站

转载 2007年10月01日 21:40:00
 

使用开源软件,设计高性能可扩展互动网站

上次我们以LiveJournal为例详细分析了一个小网站在一步一步的发展成为大规模的网站中性能优化的方案,以解决在发展中由于负载增长而引起的性能问题,同时在设计网站架构的时候就从根本上避免或者解决这些问题。

今天我们来看一下在网站的设计上一些通常使用的解决大规模访问,高负载的方法。我们将主要涉及到以下几方面:

1、 前端负载
2、 业务逻辑层
3、 数据层

LJ性能优化文章中我们提到对服务器分组是解决负载问题,实现无限扩展的解决方案。通常中我们会采用类似LDAP的方案来解决,这在邮件的服务器以及个人网站,博客的应用中都有使用,在Windows下面有类似的Active Directory解决方案。有的应用(例如博客或者个人网页)会要求在二级域名解析的时候就将用户定位到所属的服务器群组,这个时候请求还没到应用上面,我们需要在DNS里解决这个问题。这个时候可以用到一款软件bind dlz,这是bind的一个插件,用于取代bind的文本解析配置文件。它支持包括LDAP,BDB在内的多种数据存储方式,可以比较好的解决这个问题。

另外一种涉及到DNS的问题就是目前普遍存在的南北互联互通的问题,通过bind9内置的视图功能可以根据不同的IP来源解析出不同的结果,从而将南方的用户解析到南方的服务器,北方的用户解析到北方的服务器。这个过程中会碰到两个问题,一是取得南北IP的分布列表,二是保证南北服务器之间的通讯顺畅。第一个问题有个笨办法解决,从日志里取出所有的访问者IP,写一个脚本,从南北的服务器分别ping回去,然后分析结果,可以得到一个大致准确的列表,当然最好的办法还是直到从运营商那里拿到这份列表(update:参见这篇文章)。后一个问题解决办法比较多,最好的办法就是租用双线机房,同一台机器,双IP,南北同时接入,差一些的办法就是南北各自找机房,通过大量的测试找出中间通讯顺畅的两个机房,后一种通常来说成本较低,但效果较差,维护不便。

另外DNS负载均衡也是广泛使用的一种负载均衡方法,通过并列的多条A记录将访问随即的分布到多台前端服务器上,这种通常使用在静态页面居多的应用上,几大门户内容部分的前端很多都是用的这种方法。

用户被定位到正确的服务器群组后,应用程序就接手用户的请求,并开始沿着定义好的业务逻辑进行处理。这些请求主要包括两类静态文件(图片,js脚本,css等),动态请求。

静态请求一般使用squid进行缓存处理,可以根据应用的规模采用不同的缓存配置方案,可以是一级缓存,也可以是多级缓存,一般情况下cache的命中率可以达到70%左右,能够比较有效的提升服务器处理能力。Apache的deflate模块可以压缩传输数据,提高速度,2.0版本以后的cache模块也内置实现磁盘和内存的缓存,而不必要一定做反向代理。

动态请求目前一般有两种处理方式,一种是静态化,在页面发生变化时重新静态页面,现在大量的CMS,BBS都采用这种方案,加上cache,可以提供较快的访问速度。这种通常是写操作较少的应用比较适合的解决方案。

另一种解决办法是动态缓存,所有的访问都仍然通过应用处理,只是应用处理的时候会更多的使用内存,而不是数据库。通常访问数据库的操作是极慢的,而访问内存的操作很快,至少是一个数量级的差距,使用memcached可以实现这一解决方案,做的好的memcache甚至可以达到90%以上的缓存命中率。10年前我用的还是2M的内存,那时的一本杂事上曾经风趣的描述一对父子的对话:

儿子:爸爸,我想要1G的内存。

爸爸:儿子,不行,即使是你过生日也不行。

时至今日,大内存的成本已经完全可以承受。Google使用了大量的PC机建立集群用于数据处理,而我一直觉得,使用大内存PC可以很低成本的解决前端甚至中间的负载问题。由于PC硬盘寿命比较短,速度比较慢,CPU也稍慢,用于做web前端既便宜,又能充分发挥大内存的优势,而且坏了的话只需要替换即可,不存在数据的迁移问题。

下面就是应用的设计。应用在设计的时候应当尽量的设计成支持可扩展的数据库设计,数据库可以动态的添加,同时支持内存缓存,这样的成本是最低的。另外一种应用设计的方法是采用中间件,例如ICE。这种方案的优点是前端应用可以设计的相对简单,数据层对于前端应用透明,由ICE提供,数据库分布式的设计在后端实现,使用ICE封装后给前端应用使用,这路设计对每一部分设计的要求较低,将业务更好的分层,但由于引入了中间件,分了更多层,实现起来成本也相对较高。

在数据库的设计上一方面可以使用集群,一方面进行分组。同时在细节上将数据库优化的原则尽量应用,数据库结构和数据层应用在设计上尽量避免临时表的创建、死锁的产生。数据库优化的原则在网上比较常见,多google一下就能解决问题。在数据库的选择上可以根据自己的习惯选择,Oracle,MySQL等,并非Oracle就够解决所有的问题,也并非MySQL就代表小应用,合适的就是最好的。

前面讲的都是基于软件的性能设计方案,实际上硬件的良好搭配使用也可以有效的降低时间成本,以及开发维护成本,只是在这里我们不再展开。

网站架构的设计是一个整体的工程,在设计的时候需要考虑到性能,可括展性,硬件成本,时间成本等等,如何根据业务的定位,资金,时间,人员的条件设计合适的方案是件比较困难的事情,但多想多实践,终究会建立一套适合自己的网站设计理念,用于指导网站的设计工作,为网站的发展奠定良好的基础。 

高性能可扩展mysql(用户模块设计,分区表使用)

如何把用户的属性存到表中?问题: 需求:单独保存会员级别信息(没有用户登录名)->sql无法执行数据更新异常当我们数据量比较大时,更新一次就需要很长的时间数据删除异常数据冗余问题 级别积分上限,级...

高性能可扩展mysql(电商数据库设计构思)

数据库设计规范(统一) 数据库命名规范 数据库基本设计规范(存储引擎的选择,字符类型的选择) 数据库索引设计规范(索引列的选择,索引的优化技巧) 数据库字段设计规范(列的字段类型) SQL开发规范(开...

高性能可扩展mysql(其他模块,库设计)

商品模块品牌信息表(brand_info)分类信息表(product_category)供应商信息表(supplier_info)商品信息表(product_info)没有拆分,数据基本是一起使用的。...

可扩展、高可用、负载均衡网站架构设计方案

基本需求: 1、  高可用性:将停止服务时间降低到最低甚至是不间断服务 2、  可扩展性:随着访问的增加,系统具备良好的伸缩能力 3、  可视性:系统、服务的状态处于一个实时的监控之下 4、 ...

可扩展、高可用、负载均衡网站架构设计方案

基本需求: 1、  高可用性:将停止服务时间降低到最低甚至是不间断服务2、  可扩展性:随着访问的增加,系统具备良好的伸缩能力3、  可视性:系统、服务的状态处于一个实时的监控之下4、  高性能高可靠...

高性能可扩展mysql(执行计划,索引分析优化改写,删除重复数据,区间统计,满查询日志)

需求:对评论进行分页展示(利用执行计划优化查询)explain执行计划sql分析 select update insert replace delete SELECT customer_id,titl...

译文 Ceph:一个可扩展,高性能分布式文件系统

我们开发Ceph,一个分布式文件系统,它提供了优秀的性能、可靠性和可伸缩性。Ceph通过用一个伪随机数据分布函数(CRUSH)替代分布 表来最大化的分离数据与元数据管理,这个算法用于异构和动态不可靠的...

java架构师高并发集群高可用高可扩展高性能性能优化

java架构师高并发集群高可用高可扩展高性能性能优化

高性能MySQL.读书笔记(四)可扩展的MySQL

向上扩展 向上扩展(有时也称为垂直扩展)意味着购买更多强悍的硬件,对很多应用来说这是唯一需要做的事情。这种策略有很多好处。例如,单台服务器比多台服务器更加容易维护和开发,能显著节约开销。在单台服务器上...
  • xtjsxtj
  • xtjsxtj
  • 2013年11月13日 13:57
  • 2066
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:设计高性能可扩展互动网站
举报原因:
原因补充:

(最多只允许输入30个字)