高并发高流量网站架构.docx

上传人:b****1 文档编号:2036865 上传时间:2023-05-02 格式:DOCX 页数:18 大小:33.42KB
下载 相关 举报
高并发高流量网站架构.docx_第1页
第1页 / 共18页
高并发高流量网站架构.docx_第2页
第2页 / 共18页
高并发高流量网站架构.docx_第3页
第3页 / 共18页
高并发高流量网站架构.docx_第4页
第4页 / 共18页
高并发高流量网站架构.docx_第5页
第5页 / 共18页
高并发高流量网站架构.docx_第6页
第6页 / 共18页
高并发高流量网站架构.docx_第7页
第7页 / 共18页
高并发高流量网站架构.docx_第8页
第8页 / 共18页
高并发高流量网站架构.docx_第9页
第9页 / 共18页
高并发高流量网站架构.docx_第10页
第10页 / 共18页
高并发高流量网站架构.docx_第11页
第11页 / 共18页
高并发高流量网站架构.docx_第12页
第12页 / 共18页
高并发高流量网站架构.docx_第13页
第13页 / 共18页
高并发高流量网站架构.docx_第14页
第14页 / 共18页
高并发高流量网站架构.docx_第15页
第15页 / 共18页
高并发高流量网站架构.docx_第16页
第16页 / 共18页
高并发高流量网站架构.docx_第17页
第17页 / 共18页
高并发高流量网站架构.docx_第18页
第18页 / 共18页
亲,该文档总共18页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

高并发高流量网站架构.docx

《高并发高流量网站架构.docx》由会员分享,可在线阅读,更多相关《高并发高流量网站架构.docx(18页珍藏版)》请在冰点文库上搜索。

高并发高流量网站架构.docx

高并发高流量网站架构

高并发高流量网站架构

Web2.0的兴起,掀起了互联网新一轮的网络创业大潮。

以用户为导向的新网站建设概念,细分了网站功能和用户群,不仅成功的造就了一大批新生的网站,也极大的方便了上网的人们。

但Web2.0以用户为导向的理念,使得新生的网站有了新的特点——高并发,高流量,数据量大,逻辑复杂等,对网站建设也提出了新的要求。

本文围绕高并发高流量的网站架构设计问题,主要研究讨论了以下内容:

首先在整个网络的高度讨论了使用镜像网站,CDN内容分发网络等技术对负载均衡带来的便利及各自的优缺点比较。

然后在局域网层次对第四层交换技术,包括硬件解决方案F5和软件解决方案LVS,进行了简单的讨论。

接下来在单服务器层次,本文着重讨论了单台服务器的Socket优化,硬盘级缓存技术,内存级缓存技术,CPU与IO平衡技术(即以运算为主的程序与以数据读写为主的程序搭配部署),读写分离技术等。

在应用层,本文介绍了一些大型网站常用的技术,以及选择使用该技术的理由。

最后,在架构的高度讨论了网站扩容,容错等问题。

本文以理论与实践相结合的形式,结合作者实际工作中得到的经验,具有较广泛的适用性。

1引言

1.1互联网的发展

最近十年间,互联网已经从一个单纯的用于科研的,用来传递静态文档的美国内部网络,发展成了一个应用于各行各业的,传送着海量多媒体及动态信息的全球网络。

从规模上看,互联网在主机数、带宽、上网人数等方面几乎一直保持着指数增长的趋势,2006年7月,互联网上共有主机439,286,364台,WWW站点数量达到96,854,877个[1]。

全球上网人口在2004年达到7亿2900万[2],中国的上网人数在2006年12月达到了约1亿3700万[3]。

另一方面,互联网所传递的内容也发生了巨大的变化,早期互联网以静态、文本的公共信息为主要内容,而目前的互联网则传递着大量的动态、多媒体及人性化的信息,人们不仅可以通过互联网阅读到动态生成的信息,而且可以通过它使用电子商务、即时通信、网上游戏等交互性很强的服务。

因此,可以说互联网已经不再仅仅是一个信息共享网络,而已经成为了一个无所不在的交互式服务的平台。

1.2互联网网站建设的新趋势

互联网不断扩大的规模,日益增长的用户群,以及web2.0[4]的兴起,对互联网网站建设提出了新的要求:

高性能和高可扩展性。

2000年5月,访问量排名世界第一(统计数据来源[5])的Yahoo[6]声称其日页浏览数达到6亿2500万,即每秒约30,000次HTTP请求(按每个页面浏览平均产生4次请求计算)。

这样大规模的访问量对服务的性能提出了非常高的要求。

更为重要的是,互联网受众的广泛性,使得成功的互联网服务的访问量增长潜力和速度非常大,因此服务系统必须具有非常好的可扩展性,以应付将来可能的服务增长。

支持高度并发的访问。

高度并发的访问对服务的存储与并发能力提出了很高的要求,当前主流的超标量和超流水线处理器能处理的并发请求数是有限的,因为随着并发数的上升,进程调度的开销会很快上升。

互联网广域网的本质决定了其访问的延迟时间较长,因此一个请求完成时间也较长,按从请求产生到页面下载完成3秒计算,Yahoo在2000年5月时平均有90,000个并发请求。

而且对于较复杂的服务,服务器往往要维护用户会话的信息,例如一个互联网网站如果每天有100万次用户会话,每次20分钟的话,那平均同时就会有约14000个并发会话。

高可用性。

互联网服务的全球性决定了其每天24小时都会有用户访问,因此任何服务的停止都会对用户造成影响。

而对于电子商务等应用,暂时的服务中止则意味着客户的永久失去及大量的经济损失,例如[7]1999年6月的一次22小时的网站不可访问,对此网站的380万用户的忠诚度造成巨大影响,使得Ebay公司不得不支付了近500万美元用于补偿客户的损失,而该公司的市值同期下降了40亿美元[8]。

因此,关键互联网应用的可用性要求非常高。

1.3新浪播客的简介

以YouTube[9]为代表的微视频分享网站近来方兴未艾,仅2006年一年,国内就出现近百家仿YouTube的微视频分享网站[10],试图复制YouTube的成功模式。

此类网站可以说是Web2.0概念下的代表网站,具有Web2.0网站所有典型特征:

高并发,高流量,数据量大,逻辑复杂,用户分散等等。

新浪[11]作为国内最大的门户网站,在2005年成功运作新浪博客的基础上,于2006年底推出了新浪播客服务。

新浪播客作为国内门户网站中第一个微视频分享服务的网站,依靠新浪网站及新浪博客的巨大人气资源,在推出后不到半年的时间内,取得了巨大的成功:

同类网站中上传视频数量第一、流量增长最快、用户数最多[12],所有这些成绩的取得的背后,是巨大的硬件投入,良好的架构支撑和灵活的应用层软件设计。

2.1镜像网站技术

镜像网站是指将一个完全相同的站点放到几个服务器上,分别有自己的URL,这些服务器上的网站互相称为镜像网站[13]。

镜像网站和主站并没有太大差别,或者可以视为主站的拷贝。

镜像网站的好处是:

如果不能对主站作正常访问(如服务器故障,网络故障或者网速太慢等),仍能通过镜像服务器获得服务。

不便之处是:

更新网站内容的时候,需要同时更新多个服务器;需要用户记忆超过一个网址,或需要用户选择访问多个镜像网站中的一个,而用户选择的,不一定是最优的。

在用户选择的过程中,缺乏必要的可控性。

在互联网发展的初期,互联网上的网站内容很少,而且大都是静态内容,更新频率底。

但因为服务器运算能力低,带宽小,网速慢,热门网站的访问压力还是很大。

镜像网站技术在这种情况下作为一种有效解决方案,被广泛采用。

随着互联网的发展,越来越多的网站使用服务器端脚本动态生成内容,同步更新越来越困难,对可控性要求越来越高,镜像技术因为不能满足这类网站的需要,渐渐的淡出了人们的视线。

但有一些大型的软件下载站,因为符合镜像网站的条件——下载的内容是静态的,更新频率较低,对带宽,速度要求又比较高,如国外的SourceForge(http:

//www.SourceF,著名开源软件托管网站),Fedora(http:

//fedoraproject.org,RedHat赞助的Linux发行版),国内的华军软件园(),天空软件站()等,还在使用这项技术(图1)。

在网站建设的过程中,可以根据实际情况,将静态内容作一些镜像,以加快访问速度,提升用户体验。

2.2CDN内容分发网络

CDN的全称是ContentDeliveryNetwork,即内容分发网络。

其目的是通过在现有的互联网中增加一层新的网络架构,将网站的内容发布到最接近用户的网络“边缘”,使用户可以就近取得所需的内容,分散服务器的压力,解决互联网拥挤的状况,提高用户访问网站的响应速度。

从而解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题[14]。

CDN与镜像网站技术的不同之处在于网站代替用户去选择最优的内容服务器,增强了可控制性。

CDN其实是夹在网页浏览者和被访问的服务器中间的一层镜像或者说缓存,浏览者访问时点击的还是服务器原来的URL地址,但是看到的内容其实是对浏览者来说最优的一台镜像服务器上的页面缓存内容。

这是通过调整服务器的域名解析来实现的。

使用CDN技术的域名解析服务器需要维护一个镜像服务器列表和一份来访IP到镜像服务器的对应表。

当一个用户的请求到来的时候,根据用户的IP,查询对应表,得到最优的镜像服务器的IP地址,返回给用户。

这里的最优,需要综合考虑服务器的处理能力,带宽,离访问者的距离远近等因素。

当某个地方的镜像网站流量过大,带宽消耗过快,或者出现服务器,网络等故障的时候,可以很方便的设置将用户的访问转到另外一个地方(图2)。

这样就增强了可控制性。

CDN网络加速技术也有它的局限性。

首先,因为内容更新的时候,需要同步更新多台镜像服务器,所以它也只适用于内容更新不太频繁,或者对实时性要求不是很高的网站;其次,DNS解析有缓存,当某一个镜像网站的访问需要转移时,主DNS服务器更改了IP解析结果,但各地的DNS服务器缓存更新会滞后一段时间,这段时间内用户的访问仍然会指向该服务器,可控制性依然有不足。

目前,国内访问量较高的大型网站如新浪、网易等的资讯频道,均使用CDN网络加速技术(图3),虽然网站的访问量巨大,但无论在什么地方访问,速度都会很快。

但论坛,邮箱等更新频繁,实时性要求高的频道,则不适合使用这种技术。

ChinaCache的服务节点全球超过130个,

其中中国节点超过80个,

覆盖全国主要6大网络的主要省份[15]。

2.3应用层分布式设计

新浪播客为了获得CDN网络加速的优点,又必须避免CDN的不足,在应用层软件设计上,采取了一个替代的办法。

新浪播客提供了一个供播放器查询视频文件地址的接口。

当用户打开视频播放页面的时候,播放器首先连接查询接口,通过接口获得视频文件所在的最优的镜像服务器地址,然后再到该服务器去下载视频文件。

这样,用一次额外的查询获得了全部的控制性,而这次查询的通讯流量非常小,几乎可以忽略不计。

CDN中由域名解析获得的灵活性也保留了下来:

由接口程序维护镜像网站列表及来访IP到镜像网站的对应表即可。

镜像网站中不需要镜像所有的内容,而是只镜像更新速度较慢的视频文件。

这是完全可以承受的。

2.4网络层架构小结

从整个互联网络的高度来看网站架构,努力的方向是明确的:

让用户就近取得内容,但又要在速度和可控制性之间作一个平衡。

对于更新比较频繁内容,由于难以保持镜像网站之间的同步,则需要使用其他的辅助技术。

3交换层架构

3.1第四层交换简介

按照OSI[16]七层模型,第四层是传输层。

传输层负责端到端通信,在IP协议栈中是TCP和UDP所在的协议层。

TCP和UDP数据包中包含端口号(portnumber),它们可以唯一区分每个数据包所属的协议和应用程序。

接收端计算机的操作系统根据端口号确定所收到的IP包类型,并把它交给合适的高层程序。

IP地址和端口号的组合通常称作“插口(Socket)”。

第四层交换的一个简单定义是:

它是一种传输功能,它决定传输不仅仅依据MAC地址(第二层网桥)或源/目标IP地址(第三层路由),而且依据IP地址与TCP/UDP(第四层)应用端口号的组合(Socket)[17]。

第四层交换功能就像是虚拟IP,指向实际的服务器。

它传输的数据支持多种协议,有HTTP、FTP、NFS、Telnet等。

以HTTP协议为例,在第四层交换中为每个服务器组设立一个虚拟IP(VirtueIP,VIP),每组服务器支持某一个或几个域名。

在域名服务器(DNS)中存储服务器组的VIP,而不是某一台服务器的真实地址。

当用户请求页面时,一个带有目标服务器组的VIP连接请求发送给第四层交换机。

第四层交换机使用某种选择策略,在组中选取最优的服务器,将数据包中的目标VIP地址用实际服务器的IP地址取代,并将连接请求传给该服务器。

第四层交换一般都实现了会话保持功能,即同一会话的所有的包由第四层交换机进行映射后,在用户和同一服务器间进行传输[18]。

第四层交换按实现分类,分为硬件实现和软件实现。

3.2硬件实现

第四层交换的硬件实现一般都由专业的硬件厂商作为商业解决方案提供。

常见的有Alteon[19],F5[20]等。

这些产品非常昂贵,但是能够提供非常优秀的性能和很灵活的管理能力。

Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了[21]。

鉴于条件关系,这里不展开讨论。

3.3软件实现

第四层交换也可以通过软件实现,不过性能比专业硬件稍差,但是满足一定量的压力还是可以达到的,而且软件实现配置起来更灵活。

软件四层交换常用的有Linux上的LVS(LinuxVirtualServer),它提供了基于心跳(heartbeat)的实时灾难应对解决方案,提高了系统的鲁棒性,同时提供了灵活的VIP配置和管理功能,可以同时满足多种应用需求[22]。

4服务器优化

4.1服务器整体性能考虑

对于价值昂贵的服务器来说,怎样配置才能发挥它的最大功效,又不至于影响正常的服务,这是在设计网站架构的时候必须要考虑的。

常见的影响服务器的处理速度的因素有:

网络连接,硬盘读写,内存空间,CPU速度。

如果服务器的某一个部件满负荷运转仍然低于需要,而其他部件仍有能力剩余,我们将之称为性能瓶颈。

服务器想要发挥最大的功效,关键的是消除瓶颈,让所有的部件都被充分的利用起来。

4.2Socket优化

以标准的GNU/Linux为例。

GNU/Linux发行版试图对各种部署情况都进行优化,这意味着对具体服务器的执行环境来说,标准的发行版可能并不是最优化的[23]。

GNU/Linux提供了很多可调节的内核参数,可以使用这些参数为服务器进行动态配置,包括影响Socket性能的一些重要的选项。

这些选项包含在/proc虚拟文件系统中。

这个文件系统中的每个文件都表示一个或多个参数,它们可以通过cat工具进行读取,或使用echo命令进行修改。

这里仅列出一些影响TCP/IP栈性能的可调节内核参数[24]:

/proc/sys/net/ipv4/tcp_window_scaling“1”(1表示启用该选项,0表示关闭,下同)启用RFC[25]1323[26]定义的windowscaling;要支持超过64KB的窗口,必须启用该值。

/proc/sys/net/ipv4/tcp_sack“1”启用有选择的应答(SelectiveAcknowledgment),通过有选择地应答乱序接收到的报文来提高性能(这样可以让发送者只发送丢失的报文段);对于广域网通信来说,这个选项应该启用,但是这也会增加对CPU的占用。

/proc/sys/net/ipv4/tcp_timestamps“1”以一种比重发超时更精确的方法(参阅RFC1323)来启用对RTT的计算;为了实现更好的性能应该启用这个选项。

/proc/sys/net/ipv4/tcp_mem“245763276849152”确定TCP栈应该如何反映内存使用;每个值的单位都是内存页(通常是4KB)。

第一个值是内存使用的下限。

第二个值是内存压力模式开始对缓冲区使用应用压力的上限。

第三个值是内存上限。

超过这个上限时可以将报文丢弃,从而减少对内存的使用。

/proc/sys/net/ipv4/tcp_wmem“409616384131072”为自动调优定义每个socket使用的内存。

第一个值是为socket的发送缓冲区分配的最少字节数。

第二个值是默认值(该值会被wmem_default覆盖),缓冲区在系统负载不重的情况下可以增长到这个值。

第三个值是发送缓冲区空间的最大字节数(该值会被wmem_max覆盖)。

/proc/sys/net/ipv4/tcp_westwood“1”启用发送者端的拥塞控制算法,它可以维护对吞吐量的评估,并试图对带宽的整体利用情况进行优化;对于WAN通信来说应该启用这个选项。

与其他调优努力一样,最好的方法实际上就是不断进行实验。

具体应用程序的行为、处理器的速度以及可用内存的多少都会影响到这些参数对性能作用的效果。

在某些情况中,一些认为有益的操作可能恰恰是有害的(反之亦然)。

因此,需要逐一试验各个选项,然后检查每个选项的结果,最后得出最适合具体机器的一套参数。

如果重启了GNU/Linux系统,设置的内核参数都会恢复成默认值。

为了将所设置的值作为这些参数的默认值,可以使用/etc/rc.local文件,在系统每次启动时自动将这些参数配置成所需要的值。

在检测每个选项的更改带来的效果的时候,GNU/Linux上有一些非常强大的工具可以使用:

ping这是用于检查主机的可用性的最常用的工具,也可以用于计算网络带宽延时。

traceroute打印连接到特定网络主机所经过的一系列路由器和网关的路径(路由),从而确定每个hop之间的延时。

netstat确定有关网络子系统、协议和连接的各种统计信息。

tcpdump显示一个或多个连接的协议级的报文跟踪信息,其中包括时间信息,可以使用这些信息来研究不同协议的报文时间。

Ethereal以一个易于使用的图形化界面提供tcpump(报文跟踪)的信息,支持报文过滤功能。

iperf测量TCP和UDP的网络性能;测量最大带宽,并汇报延时和数据报的丢失情况。

4.3硬盘级缓存

硬盘级别的缓存是指将需要动态生成的内容暂时缓存在硬盘上,在一个可接受的延迟时间范围内,同样的请求不再动态生成,以达到节约系统资源,提高网站承受能力的目的。

Linux环境下硬盘级缓存一般使用Squid[27]。

Squid是一个高性能的代理缓存服务器。

和一般的代理缓存软件不同,Squid用一个单独的、非模块化的、I/O驱动的进程来处理所有的客户端请求。

它接受来自客户端对目标对象的请求并适当地处理这些请求。

比如说,用户通过浏览器想下载(即浏览)一个web页面,浏览器请求Squid为它取得这个页面。

Squid随之连接到页面所在的原始服务器并向服务器发出取得该页面的请求。

取得页面后,Squid再将页面返回给用户端浏览器,并且同时在Squid本地缓存目录里保存一份副本。

当下一次有用户需要同一页面时,Squid可以简单地从缓存中读取它的副本,直接返回给用户,而不用再次请求原始服务器。

当前的Squid可以处理HTTP,FTP,GOPHER,SSL和WAIS等协议。

Squid默认通过检测HTTP协议头的Expires和Cache-Control字段来决定缓存的时间。

在实际应用中,可以显式的在服务器端脚本中输出HTTP头,也可以通过配置apache的mod_expires模块,让apache自动的给每一个网页加上过期时间。

对于静态内容,如图片,视频文件,供下载的软件等,还可以针对文件类型(扩展名),用Squid的refresh_pattern来指定缓存时间。

Squid运行的时候,默认会在硬盘上建两层hash目录,用来存储缓存的Object。

它还会在内存中建立一个HashTable,用来记录硬盘中Object分布的情况。

如果Squid配置成为一个Squid集群中的一个的话,它还会建立一个DigestTable(摘要表),用来存储其它Squid上的Object摘要。

当用户端想要的资料本地硬盘上没有时,可以很快的知道应该去集群中的哪一台机器获得。

在硬盘空间快要达到配置限额的时候,可以配置使用某种策略(默认使用LRU:

LeastRecentlyUsed-最近最少用)删除一些Object,从而腾出空间[28][29]。

集群中的SquidServer之间可以有两种关系:

第一种关系是:

Child和Parent。

当ChildSquidServer没有资料时,会直接向ParentSquidServer要资料,然后一直等,直到Parent给它资料为止。

第二种关系是:

Sibling和Sibling。

当SquidServer没有资料时,会先向Sibling的SquidServer要资料,如果Sibling没资料,就跳过它向Parent要或直接上原始网站去拿。

默认配置的Squid,没有经过任何优化的时候,一般可以达到50%的命中率[30](图4)。

如果需要,还可以通过参数优化,拆分业务,优化文件系统等办法,使得Squid达到90%以上的缓存命中率。

Squid处理TCP连接消耗的服务器资源比真正的HTTP服务器要小的多,当Squid分担了大部分连接,网站的承压能力就大大增强了。

蓝线表示Squid的流量,绿色部分表示Apache流量

4.4内存级缓存

内存级别的缓存是指将需要动态生成的内容暂时缓存在内存里,在一个可接受的延迟时间范围内,同样的请求不再动态生成,而是直接从内存中读取。

Linux环境下内存级缓存Memcached[31]是一个不错的选择。

Memcached是(运营LiveJournal[32]的技术团队)开发的一套非常优秀的分布式内存对象缓存系统,用于在动态系统中减少数据库负载,提升性能。

和Squid的前端缓存加速不同,它是通过基于内存的对象缓存来减少数据库查询的方式改善网站的性能,而其中最吸引人的一个特性就是支持分布式部署;也就是说可以在一群机器上建立一堆Memcached服务,每个服务可以根据具体服务器的硬件配置使用不同大小的内存块,这样,理论上可以建立一个无限大的基于内存的缓存系统。

Memcached是以守护程序方式运行于一个或多个服务器中,随时接受客户端的连接操作,客户端可以由各种语言编写,目前已知的客户端API包括Perl/PHP/Python/Ruby/Java/C#/C等等[附录1]。

客户端首先与Memcached服务建立连接,然后存取对象。

每个被存取的对象都有一个唯一的标识符key,存取操作均通过这个key进行,保存的时候还可以设置有效期。

保存在Memcached中的对象实际上是放置在内存中的,而不是在硬盘上。

Memcached进程运行之后,会预申请一块较大的内存空间,自己进行管理,用完之后再申请一块,而不是每次需要的时候去向操作系统申请。

Memcached将对象保存在一个巨大的Hash表中,它还使用NewHash算法来管理Hash表,从而获得进一步的性能提升。

所以当分配给Memcached的内存足够大的时候,Memcached的时间消耗基本上只是网络Socket连接了[33]。

Memcached也有它的不足。

首先它的数据是保存在内存当中的,一旦服务进程重启(进程意外被关掉,机器重启等),数据会全部丢失。

其次Memcached以root权限运行,而且Memcached本身没有任何权限管理和认证功能,安全性不足。

第一条是Memcached作为内存缓存服务使用无法避免的,当然,如果内存中的数据需要保存,可以采取更改Memcached的源代码,增加定期写入硬盘的功能。

对于第二条,我们可以将Memcached服务绑定在内网IP上,通过Linux防火墙进行防护。

4.5CPU与IO均衡

在一个网站提供的所有功能中,有的功能可能需要消耗大量的服务器端IO资源,像下载,视频播放等,而有的功能则可能需要消耗大量的服务器CPU资源,像视频格式转换,LOG统计等。

在一个服务器集群中,当我们发现某些机器上CPU和IO的利用率相差很大的时候,例如CPU负载很高而IO负责很低,我们可以考虑将该服务器上的某些耗CPU资源的进程换成耗IO的进程,以达到均衡的目的。

均衡每一台机器的CPU和IO消耗,不仅可以获得更充分的服务器资源利用,而且还能够支持暂时的过载,遇到突发事件,访问流量剧增的时候,实现得体的性能下降(Gracefulperformancedegradation)[34],而不是立即崩溃。

4.6读写分离

如果网站的硬盘读写性能是整个网站性能提升的一个瓶颈的话,可以考虑将硬盘的读,写功能分开,分别进行优化。

在专门用来写的硬盘上,我们可以在Linux下使用软件RAID-0(磁盘冗余阵列0级)[35]。

RAID-0在获得硬盘IO提升的同时,也会增加整个

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 工程科技 > 能源化工

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2