大型网站瓶颈及解决方案

大型网站面临的问题:

  • 海量数据处理

大型网站每天的数据量可能上百万,甚至上千万或更多。如果存在设计不好的多对多关系,在前期可能没有任何问题,但是随着用户增长,数据量会以几何级数增加。此时,对于一个表的select和update(还不用说多表联合查询)的成本是非常高的。

  • 数据并发处理

死锁在高并发情况下存在的概率非常高,这时使用缓存仍是一个大问题。因为在整个应用范围下,缓存是全局共享的。当两个或者多个请求同时对缓存有更新要求时,尽管我们有lock机制,但并不是很灵验,应用程序还是会直接死掉。

  • 文件存贮问题

当文件量是海量数据的情况下,那么维护和使用时,磁盘I/O就是一个巨大的问题,哪怕你的带宽足够,但是你的磁盘也未必响应得过来。如果这个时候还涉及上传,磁盘很容易就over了。

  • 数据关系处理

在Web2.0时代,数据关系大多是多对多关系,涉及的大多是多表联合查询。如果避免是一个问题。

  • 数据索引问题

索引和更新是一对矛盾。廉价的索引可能带来高代价的update。

  • 分布式处理

为了保证各地的访问速度,如何有效实现数据同步和更新,实现各地服务器的实时通信是一个很大的问题。

  • Ajax利弊

Ajax利用简单的post和get进行数据传递,采用HTTP debuger抓取数据,但存在攻击危险。

  • 数据安全性

大型网站面临的危险主要有外挂、群发等,如采用验证码,对用户体验又是一个很意外的影响。

  • 数据同步和集群处理

当数据库服务器不堪重负时,就需要做基于数据库的负载和集群了。这时可能会遇到最让人困扰的问题:根据数据库的设计不同,数据基于网络传输时会发生数据延迟。这是很可怕的问题,也不可避免。由此,我们就需要通过另外的手段来保证在这延迟的几秒或者更长时间内,实现有效的交互。比如数据散列、分割、内容、异步处理等问题。

  • Open API以及数据共享

Open API已经成为不可避免的趋势,从google,facebook,myspace到海内、校内,都在考虑这个问题,它可以更有效地留住用户,并激发用户更多参与,让更多人帮助你做最有效的开发。

  • 大量like,or,in以及多表查询带来的性能屏障
  • 大量上传文件攻击

解决方案

把Web2.0网站用户量级别定为三种,百万级别(M)、千万级别(S)以及亿万级别(Q)。如果全表查询,可以采用分区视图、分表索引处理。

对于M级别来说,主要应对的是I/O问题:对数据库的file文件分磁盘存贮(不是分区,是不同的硬盘),根据负载量大小,我们可以适当控制硬盘的数量和文件分区的数量。对于S级别,需要对注册和入库的流程进行简单修改。解决方案是数据散列和分区视图。

常用的方案有三种。第一种是等容扩充法:在用户注册控制的基础上,保证每个库的用户容量不超过500万,超过之后入第二个库,以此类推。这个方案可以保证有效的扩充性,但不能保证数据被有效索引。第二种就是共区索引方案,其实和第一种方案有异曲同工之处。但是对第一种方案进行了合理的优化,按照用户名进行了分库存贮。如建立26个数据库,按照用户名的索引来控制用户数据入哪个库。假如用户名是crazycode,那该用户名的数据存放在用户表C中。方案三是一个更具模型化的方案,进行用户ID的编码。我们用一种序列化的方案将用户名以编码的形式存贮,如crazycode按照C,R,A,......存贮为数字索引,然后进行分区存贮。数字类型的数据在数据库中可以更有效地被查询、更新和共享,这就是结合方案一和方案二的方案三。

对于Q级别,可以根据用户活跃度的权值结合数据量进行临时数据表的存放。如果是在非意外的数据情况下,每天登录的用户量不会上千万。利用一个简单的数据代理程序,一个临时的用户验证数据库,每天执行一次批处理,将活跃度高的用户帐户撮到临时数据库中。查询的时候先查询临时库,如果没有,再进行全库查询。

一个更高级的查询方案——数据缓存服务,就是将最常用最直接的数据直接存放在缓存服务器中,而这个缓存服务器定时从主服务器获取并更新信息。更深入地,可以将缓存服务器做二次缓存,也就是一次性处理输入并存放到list数据中,作为全局变量放到内存中进行查询,同时用散列表或者数组进行数据索引,根据查询分布到各个变量中,直接从内在中读取数据。

时间: 2024-11-05 07:49:36

大型网站瓶颈及解决方案的相关文章

大型网站问题的解决方案

大型网站问题的解决方案 大并发 答:可以使用服务分层架构实现,主要使用的技术是负载均衡器. 分层: 单服务器 b. 简单分层 c. 集群(负载均衡集群) 场景模拟: 实现图: ? 负载均衡器常见实现: 硬件:f5 ,立竿见影,效果明显,价格昂贵,主要游戏公司,银行使用,20w左右单台 软件:nginx(七层)和lvs(四层,性能更好) nginx也是一个高性能 lvs 章文嵩 ? 负载均衡算法 轮询:一个一个轮着来,像一个圆环 加权:能者多劳,配置强的完成多的请求 ip_hash:拿用户的IP多

大型网站架构改进历程:存储的瓶颈(五)

摘要:什么是大型网站,从网站的技术角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标,懂点行的人也许会认为是网站在单位时间里的并发量的大小来作为指标,如果按这些标准那么像hao123网站就是了. [编者按]本文转自博客园的 夏天的森林,在看这篇之前,大家可以移步看 大型网站架构改进历程:存储的瓶颈(一).(二).(三).(四). 上文里我遗留了两个问题,一个问题是数据库做了水平拆分以后,如果我们对主键的设计采取一种均匀分布的策略,那么它对于被水平拆分出的表后续的查询操作将有何种

关于大型网站技术演进的思考(一)--存储的瓶颈(上)

前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训,两天12个小时信息量非常大,知识的广度和难度也非常大,培训完后我很难完整理出全部听到的知识,今天我换了个思路是回味这次培训,这个思路就是通过本人目前的经验和技术水平来思考下大型网站技术演进的过程. 首先我们要思考一个问题,什么样的网站才是大型网站,从网站的技术指标角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标,懂点行的人也许会认为是网站在单位时间里的并发量的大小来作为指标,如果按这些标准那么像hao123

关于大型网站技术演进的思考(三)--存储的瓶颈(3)(转)

原文:http://www.cnblogs.com/sharpxiajun/p/4251714.html 存储的瓶颈写到现在就要进入到深水区了,如果我们所做的网站已经到了做数据库垂直拆分和水平拆分的阶段,那么此时我们所面临的技术难度的挑战也会大大增强. 这里我们先回顾下数据库的垂直拆分和水平拆分的定义: 垂直拆分:把一个数据库中不同业务单元的数据分到不同的数据库里. 水平拆分:是根据一定的规则把同一业务单元的数据拆分到多个数据库里. 垂直拆分是一个粗粒度的拆分数据,它主要是将原来在一个数据库下的

关于大型网站技术演进的思考(二)--存储的瓶颈(中)

上篇里我讲到某些网站在高并发下会报出503错误,503错误的含义是指网站服务端暂时无法提供服务的含义,503还表达了网站服务端现在有问题但是以后可能会提供正常的服务,对http协议熟悉的人都知道,5开头的响应码表达了服务端出现了问题,在我们开发测试时候最为常见的是500错误,500代表的含义是服务端程序出现了错误导致网站无法正常提供服务,500通常是服务端异常和错误所致,如果生产系统里发现了500错误,那么只能说明网站存在逻辑性的错误,这往往是系统上线前的测试做的不到位所致.回到503错误,我上

关于大型网站技术演进的思考--存储的瓶颈(转)

(一)第一部分 前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训,两天12个小时信息量非常大,知识的广度和难度也非常大,培训完后我很难完整理出全部听到的知识,今天我换了个思路是回味这次培训,这个思路就是通过本人目前的经验和技术水平来思考下大型网站技术演进的过程. 首先我们要思考一个问题,什么样的网站才是大型网站,从网站的技术指标角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标,懂点行的人也许会认为是网站在单位时间里的并发量的大小来作为指标,如果按这些标准那

大型网站数据库解决方案

对于大型网站系统而言,有三个难以逾越的难题: 1.数据资源已近乎等同生存资本,如何保障网站数据不丢失? 2.网站业务停服带来巨大经济损失,如何构建多级高可用? 3.高并发流量带来的系统压力激增,系统如何应对? 阿里云云数据库RDS沉淀阿里巴巴集团多年数据库技术,深耕各行业数据库解决方案,对网站系统的各级难题均有可靠的应对策略.   一.网站数据安全      数据安全已经成为一家网站赖以生存的资本,尤其对于电商网站而言,数据近乎等于直接的生存资源.近日国内某知名电商网站也遭遇了拖库危机,可见数据

关于大型网站技术演进的思考(二)-存储的瓶颈2

503错误 在上篇,我讲到某些网站在高并发下会报出503错误,503错误的含义是指网站服务端暂时无法提供服务,503还表达了网站服务端现在有问题,但是以后可能会提供正常的服务,对http协议熟悉的人都知道,5开头的响应码表达了服务端出现了问题,在我们开发测试时候最为常见的是500错误,500代表的含义是服务端程序出现了错误导致网站无法正常提供服务,500通常是服务端异常和错误所致,如果生产系统里发现了500错误,那么只能说明网站存在逻辑性的错误,这往往是系统上线前的测试做的不到位所致.回到503

【转】关于大型网站技术演进的思考(一)--存储的瓶颈(1)

前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训,两天12个小时信息量非常大,知识的广度和难度也非常大,培训完后我很难完整理出全部听到的知识,今天我换了个思路是回味这次培训,这个思路就是通过本人目前的经验和技术水平来思考下大型网站技术演进的过程. 首先我们要思考一个问题,什么样的网站才是大型网站,从网站的技术指标角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标,懂点行的人也许会认为是网站在单位时间里的并发量的大小来作为指标,如果按这些标准那么像hao123