如何走出海量数据及访问量压力困境

本文涉及的产品
云数据库 RDS SQL Server,独享型 2核4GB
简介:
一、 国外大型IT网站的成功之道 
(一) MySpace 
    今天,MySpace已经成为全球众口皆碑的社区网站之王。尽管一流和营销和管理经验自然是每个IT企业取得成功的首要因素,但是本节中我们却抛弃这一点,而主要着眼于探讨在数次面临系统扩张的紧急关头MySpace是如何从技术方面采取应对策略的。 
第一代架构—添置更多的Web服务器 
    MySpace最初的系统很小,只有两台Web服务器(分担处理用户请求的工作量)和一个数据库服务器(所有数据都存储在这一个地方)。那时使用的是 Dell双CPU、4G内存的系统。在早期阶段,MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。但到在2004年早期,在 MySpace用户数增长到五十万后,其数据库服务器已经开始疲于奔命了。 

第二代架构—增加数据库服务器 
    与增加Web服务器不同,增加数据库并没那么简单。如果一个站点由多个数据库支持,设计者必须考虑的是,如何在保证数据一致性的前提下让多个数据库分担压力。

    MySpace运行在三个SQL Server数据库服务器上—一个为主,所有的新数据都向它提交,然后由它复制到其它两个;另两个数据库服务器全力向用户供给数据,用以在博客和个人资料 栏显示。这种方式在一段时间内效果很好——只要增加数据库服务器,加大硬盘,就可以应对用户数和访问量的增加。

    这一次的数据库架构按照垂直分割模式设计,不同的数据库服务于站点的不同功能,如登录、用户资料和博客。垂直分割策略利于多个数据库分担访问压力,当用户 要求增加新功能时,MySpace只需要投入新的数据库加以支持。在账户到达二百万后,MySpace还从存储设备与数据库服务器直接交互的方式切换到 SAN(存储区域网络)—用高带宽、专门设计的网络将大量磁盘存储设备连接在一起,而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可 靠性。然而,当用户继续增加到三百万后,垂直分割策略也变得难以维持下去。

第三代架构—转到分布式计算架构 
    几经折腾,最终,MySpace将目光移到分布式计算架构——它在物理上分布的众多服务器,整体必须逻辑上等同于单台机器。拿数据库来说,就不能再像过去 那样将应用拆分,再以不同数据库分别支持,而必须将整个站点看作一个应用。现在,数据库模型里只有一个用户表,支持博客、个人资料和其他核心功能的数据都 存储在相同数据库。

    既然所有的核心数据逻辑上都组织到一个数据库,那么MySpace必须找到新的办法以分担负荷——显然,运行在普通硬件上的单个数据库服务器是无能为力 的。这次,不再按站点功能和应用分割数据库,MySpace开始将它的用户按每百万一组分割,然后将各组的全部数据分别存入独立的SQL Server实例。目前,MySpace的每台数据库服务器实际运行两个SQL Server实例,也就是说每台服务器服务大约二百万用户。据MySpace的技术人员说,以后还可以按照这种模式以更小粒度划分架构,从而优化负荷分 担。 

第四代架构—求助于微软方案 
    2005年早期,账户达到九百万,MySpace开始用微软的C#编写ASP.NET程序。在收到一定成效后,MySpace开始大规模迁移到ASP.NET。 
    账户达到一千万时,MySpace再次遭遇存储瓶颈问题。SAN的引入解决了早期一些性能问题,但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。 

第五代架构—增加数据缓存层并转到支持64位处理器的SQL Server 2005 
    2005年春天,MySpace账户达到一千七百万,MySpace又启用了新的策略以减轻存储系统压力,即增加数据缓存层——位于Web服务器和数据库 服务器之间,其唯一职能是在内存中建立被频繁请求数据对象的副本,如此一来,不访问数据库也可以向Web应用供给数据。

    2005年中期,服务账户数达到两千六百万时,MySpace因为我们对内存的渴求而切换到了还处于beta测试的支持64位处理器的SQL Server 2005。升级到SQL Server 2005和64位Windows Server 2003后,MySpace每台服务器配备了32G内存,后于2006年再次将配置标准提升到64G。

    事实上,MySpace的Web服务器和数据库仍然经常发生超负荷,其用户频繁遭遇“意外错误”和“站点离线维护”等告示,他们不得不在论坛抱怨不停…… 
    MySpace正是在这样不断重构站点软件、数据库和存储系统中,才一步步走到今天。事实上,MySpace已经成功解决了很多系统扩展性问题,其中存在 相当的经验值得我们借鉴。MySpace系统架构到目前为止保持了相对稳定,但其技术人员仍然在为SQL Server支持的同时连接数等方面继续攻坚,尽可能把事情做到最好。 

(二) Amazon 
    亚马逊书店无疑是电子商务发展的里程碑。2000年到现在,世界网络业腥风血雨。Amazon曾经成为网络泡沫的头号代表。如今,当这个“最大的泡沫”用几经易改的数字把自己变成了坚实的IT巨人。 
历 览Amazon发展过程,其成功经验在于,它创造性地进行了电子商务中每一环节的探索,包括系统平台的建设,程序编写、网站设立、配送系统等等方面。用 Amazon当家人贝索斯的话说就是,“在现实世界的商店最有力的武器就是地段,地段,地段,而对于我们来说最重要的三件事就是技术,技术,技术。” 

(三) eBay 
    eBay是世界闻名的拍卖网站,eBay公司通信部主管凯文•帕斯格拉夫认为,“eBay成功的最重要原因在于公司管理和服务。” 
其成功的奥秘可以列举为以下几点: 
①敢为天下先—在网络尚不普及的时代,eBay率先进入网络拍卖领域; 
②依托虚拟商场所产生的特有的“零库存”是eBay公司取得成功的另一个重要原因。该公司的核心业务没有任何库存风险,所有的商品都是由客户提供,它只需要负责提供虚拟的拍卖平台—网络和软件。所以,eBay公司的财务报表上不会出现“库存费用”和“保管费用”等。 
③自eBay公司成立开始,它就一直遵循两条“黄金原则”:建设虚拟社区,给网民以家的感觉;保证网站稳定安全地运行。
二、 国内大型网站开发时的几点建议 
    从本节开始,我们将结合国内外大型IT网站在技术扩展方面的沉痛教训和成功经验,探讨在如今刚刚开始的Web 2.0时代如何应对国内网站即将面临的数据访问量增加(甚至是急剧膨胀)的问题,并提出一些供参考的策略和建议。 

(四) 搭建科学的系统架构 
    构建大型的商业网站绝对不可能像构建普通的小型网站一样一蹴而就,需要从严格的软件工程管理的角度进行认真规划,有步骤有逻辑地进行开发。对于大型网站来 说,所采用的技术涉及面极其广泛,从硬件到软件、编程语言、数据库、Web服务器、防火墙等各个领域都有了很高的要求,已经不是原来简单的html静态网 站所能比拟的。以著名的Yahoo!为例,他们的每一个大型网站工程都需要大量相应专业人员的参与。 

(五) 页面静态化 
    可不要小看纯静态化的HTML页面!其实在很多情况下,HTML往往意味着“效率最高、消耗最小”,所以我们尽可能使我们的网站上的页面采用静态页面来实 现。但是,对于大量内容并且频繁更新的网站,我们无法全部手动实现,因此可以开发相应的自动化更新工具,例如我们常见的信息发布系统CMS。像我们经常访 问的各个门户站点的新闻频道,甚至他们的其他频道,都是通过信息发布系统来管理和实现的。信息发布系统可以实现最简单的信息录入自动生成静态页面,还能具 备频道管理、权限管理、自动抓取等功能,对于一个大型网站来说,拥有一套高效、可管理的CMS是必不可少的。 

(六) 存储问题 
    存储也是一个大问题,一种是小文件的存储,比如图片这类;另一种是大文件的存储,比如搜索引擎的索引。 
大 家知道,对于Web服务器来说,不管是Apache、IIS还是其他容器,图片是最消耗资源的,于是我们有必要将图片与页面进行分离,这是基本上大型网站 都会采用的策略,他们都有独立的图片服务器,甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力,并且可以保证系统不会因为图片 问题而崩溃,在应用服务器和图片服务器上,可以进行不同的配置优化以保证更高的系统消耗和执行效率。

(七) 数据库技术—集群和库表散列 
    对于大型网站而言,使用大型的数据库服务器是必须的事情。但是,在面对大量访问的时候,数据库的瓶颈仍然会显现出来,这时一台数据库将很快无法满足应用,于是我们需要借助于数据库集群或者库表散列技术。

    在数据库集群方面,很多数据库厂商都有自己的解决方案,Oracle、Sybase、SQL Server等都有很好的方案,常用的MySQL提供的Master/Slave也是类似的方案。因此,你使用了什么样的数据库,就参考相应的解决方案来实施即可。 

    上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用数据库类型的限制,于是我们需要从应用程序的角度来考虑改善系统架构,其中,库表散列是 常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离,不同的模块对应不同的数据库或者表,再按照一定的策略对某个页 面或者功能进行更小的数据库散列,比如用户表,按照用户ID进行表散列,这样就能够低成本的提升系统的性能并且有很好的扩展性。在这一方面一个现成的例子 就是搜狐。它的论坛就是采用了这样的架构,将论坛的用户、设置、帖子等信息进行数据库分离,然后对帖子、用户按照板块和ID进行散列数据库和表,最终可以 在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。 

(八) 缓存策略 
    这绝对不单指低级的缓存技术相关的编程,应从整个架构角度着眼,深入研究Web服务器、数据库服务器的各层级的缓冲策略,最后才是低级的缓冲技术的编程。 不同的Web服务器、数据库服务器及Web编程语言都有自己不同的缓冲策略。例如数据库存储方面,SQL Serve 2005中的主动式缓存机制,Oracle数据的cache group技术,Hibernate的缓存包括Session的缓存和SessionFactory的缓存;Web服务器方面,Apache提供了自己的 缓存模块,也可以使用外加的Squid模块进行缓存,这两种方式均可以有效的提高Apache的访问响应能力,IIS缓冲器技术;至于web开发语言,所 用缓存技术更存在很大不同,例如ASP.NET 2.0中提出了两种缓存应用程序数据和缓存服务页输出的策略,这两种缓存技术相互独立但不相互排斥,PHP有Pear的Cache模块,等等。 

(九) 镜像 
    镜像是大型网站常采用的提高性能和数据安全性的方式,镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异。在镜像的细节技术方面,这里不阐述 太深,有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路,比如Linux上的rsync等工具。 

(十) 负载均衡 
    负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。 
负载均衡技术发展了多年,有很多专业的服务提供商和产品可以选择,基于LAMP解决方案的Lighttped+Squid是相当不错的解决负载均衡和加速系统的有效方式。

(十一) 硬件四层交换 
    第四层交换使用第三层和第四层信息包的报头信息,根据应用区间识别业务流,将整个区间段的业务流分配到合适的应用服务器进行处理。第四层交换功能就象是虚 IP,指向物理服务器。它传输的业务服从的协议多种多样,有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上,需要复杂的 载量平衡算法。在IP世界,业务类型由终端TCP或UDP端口地址来决定,在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决 定。

    在硬件四层交换产品领域,有一些知名的产品可以选择,比如Alteon、F5等,这些产品很昂贵,但是物有所值,能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。
(十二) 软件四层交换 
    大家知道了硬件四层交换机的原理后,基于OSI模型来实现的软件四层交换也就应运而生,这样的解决方案实现的原理一致,不过性能稍差。但是满足一定量的压力还是游刃有余的。 
一个典型的使用负载均衡的策略就是,在软件或者硬件四层交换的基础上搭建squid集群,这种思路在很多大型网站包括搜索引擎上被采用,这样的架构低成本、高性能还有很强的扩张性,随时往架构里面增减节点都非常容易。 

(十三) 软件投资问题 
    据报导,目前国内除了一些上市企业和特别大知名大公司以外,很少有企业在成本中考虑正版软件的购置费用。这种思维极有可能给中国互联网带来噩梦。如果一些 公司真正面临软件资金方面的困难,完全可以考虑使用开源世界的LAMP解决方案(Linux+Apache+MySQL+Perl、PHP或者 Python Web编程语言);否则,随着我国加入WTO范围的不断扩大,盗版打击必然越来越严。因此,“苟且偷生”必将自食其果。 

    另外,随着网络带宽日渐提升,WEB 2.0技术必将影响到网络世界的几乎每一个角落。因此,如何积聚技术人员进行技术攻关并进一步加强安全防范也成为一个日益严峻的问题,宜尽早纳入到公司的议事日程。 
   
四、 总结  
    中国电子商务真正理性发展的一个标志,是大量的传统企业实实在在地开始用互联网来处理商务、做生意,而现在这样的浪潮已经开始。北京发行集团,联合SINA、6688.com等单位共同推出的网上虚拟书店—新新书店就是这样的一个标志。 

随 着网络带宽日渐提升,随着网络理念和WEB 2.0技术的断深入人心,各种B2B、B2C、C2C等电子商务模式很可能以立体交叉方式整合到各种大型商务网站中来。因此,作为公司的技术人员,作为临 危救驾的“白衣骑士”,如何应对海量存储、海量访问问题,海量信息检索的问题,日益严峻的安全问题,等等,已经刻不容缓。



















本文转自朱先忠老师51CTO博客,原文链接:http://blog.51cto.com/zhuxianzhong/59893 ,如需转载请自行联系原作者


相关实践学习
部署高可用架构
本场景主要介绍如何使用云服务器ECS、负载均衡SLB、云数据库RDS和数据传输服务产品来部署多可用区高可用架构。
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
2月前
|
供应链 安全 机器人
管理能力跟不上扩张规模,库迪正在拖垮自己?
许多昙花一现的消费品牌,根源都是管理能力跟不上扩张规模,被联营商、内部员工都在吐槽的库迪咖啡,显然面临着同样的挑战。
|
5月前
|
存储 测试技术 API
面对大促场景来临,如何从容进行性能测试
面对大促场景来临,如何从容进行性能测试
|
程序员 开发者
如何在重压之下,化压力为动力
随着现在快节奏的生活和工作,越来越多的年轻人承受着比之前要高很多倍的各种压力,无论在生活中还是工作中,抗压成为年轻人生存的必备技能。那么在日常中面临压力的时候,怎么才能化解压力,实现自己完美脱身呢?还是要保持积极乐观的心态最重要,端正心态,临危不乱,临险不惧,坚信车到山前必有路的观点,方能化解压力。
96 1
如何在重压之下,化压力为动力
|
运维
《运维如何应对十倍、百倍的业务增长?》电子版地址
运维如何应对十倍、百倍的业务增长?
47 0
《运维如何应对十倍、百倍的业务增长?》电子版地址
|
存储 编解码 缓存
微信朋友圈千亿访问量背后的技术挑战和实践总结
微信朋友圈千亿访问量背后的技术挑战和实践总结
309 0
微信朋友圈千亿访问量背后的技术挑战和实践总结
|
存储 缓存 运维
高并发,我把握不住啊!
高并发,我把握不住啊!
362 0
高并发,我把握不住啊!
|
移动开发 小程序 算法
线上流量越发昂贵,如何通过裂变营销实现业务增长?
公域流量流量越来越聚集于头部的媒体同时投放的费用越来越高。如:在游戏电商或金融行业,在广告投放拉新方面成本达到了100元左右。除了头部媒体的流量以外,在中长尾的流量上,这部分虽然成本低,但转化效果却很差。
线上流量越发昂贵,如何通过裂变营销实现业务增长?
|
新零售 NoSQL 容灾
业务爆发保持丝般顺滑 阿里云助力完美日记半年内系统吞吐量提升50倍
近年来,完美日记的“小黑钻口红”“动物眼影盘”等爆款彩妆出现在了越来越多女孩子的化妆台上,完美日记(Perfect Diary)是由逸仙电商在2017年推出的彩妆品牌,凭借着高颜值和性价比,完美日记彩妆销量增长迅猛,被众多网友誉为国货之光。
751 0
业务爆发保持丝般顺滑 阿里云助力完美日记半年内系统吞吐量提升50倍