海量图片系统集群分布式存储和负载均衡案例分享

对于Web服务器而言,用户对图片信息的访问是很消耗服务器资源的。当一个网页被浏览时,Web服务器与浏览器建立连接,每个连接表示一个并发。当页面包含多个图片时,Web服务器与浏览器会产生多个连接,同时发送文字和图片以提高浏览速度。因此,页面中图片越多Web服务器受到的压力也就越大。

一般小型网站是把所有页面和图片统一存放在一个主目录下,这样的网站对系统架构、性能要求都很简单。下面是原理图


一些稍有规模的网站都保存有大量图片资源。用户在访问这些站点网页时,网页中图片信息占到页面数据流量的大部分。由于受客户端浏览器限制,无法从一台服务器上同时下载页面中所有图片信息,因此即使服务器有很高带宽,用户的访问速度还是会受到很大影响。由于图片保存在物理硬盘上,访问图片需要频繁进行I/O
操作,因此当并发用户数越来越多时,I/O操作就会成为整个系统的性能瓶颈。这个时候我们就要考虑把这些图片信息进行分布式存储了。


下面说一个适用于中等规模商务网站的图片数据分布式动态存储及负载均衡的解决方案的思路。这种思想只需增加很少的硬件成本,即可提升网站的访问速度,并且可以根据需要动态调整图片服务器的数量及图片的存储目录,确保系统具有可扩展性和伸缩性。但对于大型的网站系统来说,他们可能会有更好的技术来实现数据的分布式存储。

增加了图片服务器后,对于客户端而言,整个网站系统执行过程应该仍然是透明的,不会给用户带来任何影响。但后台系统需要解决以下4个问题:

(1)如何实现图片的分布式部署,图片上传时如何动态确定保存到哪台图片服务器;

(2)如何做到图片服务器的负载均衡,既要保证所有图片服务器都有均等的机会来保存图片.

(3)如何把一台图片服务器上图片均衡保存到多个子目录中以便突破操作系统在同一个目录中保存文件数的限制,对图片进行更好的管理和维护;

(4)如何能根据性能需要和图片数量的增加实现图片服务器的动态扩充。

下面是原理图


Web服务器部署网站的Web页面,用于响应客户端用户的请求。当用户浏览网页时,Web服务器响应请求并访问数据库服务器,获得网页中所有图片的URL路径,然后生成页面并返回给客户端,客户端接收该页面并根据页面中的图片URL路径自动从不同的图片服务器下载并显示相应图片。当用户上传图片时,Web服务器首先从数据库服务器中获取所有图片服务器的当前状态,并根据相关算法选择一个图片服务器及保存的目录,再调用该图片服务器的Web
Service方法把图片保存到该服务器,最后在数据库服务器中纪录该图片的编号及URL路径等信息。数据库服务器用于记录所有图片的编号以及图片的存放位置等信息,同时需要记录所有图片服务器的配置及当前状态信息。图片服务器集群用于存放网站的所有图片信息,该集群的服务器数量可以根据需要动态增加。

图片服务器信息表


Web
服务器需要及时掌握所有图片服务器的状态和信息才能动态决定把图片保存到哪一台图片服务器,因此,需要把所有的图片服务器的状态信息全部纪录到数据库服务器中,
状态信息表中的ServerId字段为主键自增列,唯一代表一条图片服务器纪录。ServerName字段记录服务器的名称,方便管理员识别该记录代表哪台服务器。ServerUrl字段标识了图片服务器上图片主目录的URL根路径。PicRootPath字段标识了保存图片的物理主目录。
MaxPicAmount字段表示图片服务器能保存的最大图片数,该数可以根据图片服务器的硬件配置和性能以及用户实际需要而进行动态调整。
CurPicAmount字段表示当前已保存的图片数,当CurPicAmount≥MaxPicAmount时系统将不再把图片上传到该服务器。
FlgUsable字段表示图片服务器是否可用。

把图片保存到图片服务器上

可以在图片服务器上部署相应的服务,实现方式有web service、WCF、webclient类,共享文件等等。

获取图片服务器的随机算法

从状态表筛选出可用的图片服务器集合记作C,并获取集合的总记录数N。然后用随机函数产生一个随机数R1并用R1与N进行取余运算记作I=R1%N。则C[I]即为要保存图片的图片服务器

检测图片服务器是否正常运行

可以利用心跳机制

客户端用户通过浏览器向Web服务器发出浏览某页面的请求,Web服务器从数据库服务器中获取该页面的所有图片URL信息,并根据URL信息去搜索图片服务器的状态信息表,判断该URL所指向的图片服务器的状态字段FlgUsable,若FlgUsable
==
false表示该图片服务器当前因某种原因处于不可用状态,则把该图片的URL替换成Web服务器上保存的一个默认图片的URL,否则把该URL直接返回给客户端。客户端再根据图片的URL路径自动从不同的图片服务器上下载并显示相应的图片。由于图片URL路径直接指向具体的图片服务器,因此需要在每个图片服务器的保存图片的主目录上建立一个Web站点。由于客户端浏览器所需要的图片是从多个图片服务器上直接下载,因此浏览器可以并发地从多台服务器上同时下载图片,这样就缩短了图片下载时间,同时也减轻了Web服务器的I/O请求及性能压力,因此,提高了网站的访问速度
.

海量图片的分布式存储及负载均衡研究

前言

针对海量图片给网站带来的访问速度下降、性能压力增大和I/O瓶颈等问题,提出一种海量图片的分布式存储及负载均衡技术。通过把图片数据和网站内容分开部署、在数据库中记录和维护图片服务器状态信息等方法实现图片和页面数据的分离。实验结果表明,该技术能提高网站的访问速度和运行效率,并可动态增加图片服务器的数量满足日益增加的性能需求

摘 要:

针对海量图片给网站带来的访问速度下降、性能压力增大和I/O瓶颈等问题,提出一种海量图片的分布式存储及负载均衡技术。通过把图片数据和网站内容分开部署、在数据库中记录和维护图片服务器状态信息等方法实现图片和页面数据的分离。实验结果表明,该技术能提高网站的访问速度和运行效率,并可动态增加图片服务器的数量满足日益增加的性能需求。

关键词:海量图片;分布式存储;负载均衡

【Abstract】Aiming at the problems of the mass images can cause to Web site
such as lower access speed, more performance pressure, I/Operformance
bottle-neck, etc., a technology of distributed store and load balance for mass
images is proposed. By the means of deploying Website pages and images
separately and recording status of image servers in database, solves the problem
of separation for image data and page data.Experimental result shows that the
solution can improve the access speeds and running efficiency for Web site, and
can add additional imageservers to meet the increasing performance demands.

【Key words】mass images; distributed store; load balance

一、概述

随着计算机网络技术的发展和普及,出现了越来越多像“新浪”、“淘宝”大型门户站点及电子商务网站[1]。这类网站都保存有大量图片资源。用户在访问这些站点网页时,网页中图片信息占到页面数据流量的大部分。由于受客户端浏览器限制,无法从一台服务器上同时下载页面中所有图片信息,因此即使服务器有很高带宽,用户的访问速度还是会受到很大影响。由于图片保存在物理硬盘上,访问图片需要频繁进行I/O操作,因此当并发用户数越来越多时,I/O操作就会成为整个系统的性能瓶颈[2]。同时,由于受操作系统的限制,一个目录中能存放的图片文件数量是有限的,因此随着图片资源的不断增加,如何合理有效地对图片进行管理和维护也是一个难题。

对于少数大型网站系统,由于自身具有雄厚的资金和人力资源,可采用NFS[3]、CDN[4]、Lighttpd、反向代理、负载均衡等技术提高用户访问速度。但这些技术需要庞大的资金支持,对于处于创业初期中等规模的商务网站,由于缺少必要的资金支持,因此无法采用这些技术提升网站的访问速度。对此,
笔者提出了适用于中等规模商务网站的海量图片数据分布式动态存储及负载均衡的解决方案。该方案只需增加很少的硬件成本,即可提升网站的访问速度,并且可以根据需要动态调整图片服务器的数量及图片的存储目录,确保系统具有可扩展性和伸缩性[5]。

二、系统架构设计

对于Web服务器而言,用户对图片信息的访问是很消耗服务器资源的。当一个网页被浏览时,Web服务器与浏览器建立连接,每个连接表示一个并发。当页面包含多个图片时,Web服务器与浏览器会产生多个连接,同时发送文字和图片以提高浏览速度。因此,页面中图片越多Web服务器受到的压力也就越大。同时由于受到浏览器本身的并发连接数限制(2个~6个并发),意味着页面上有多于并发连接数限制的图片时,也不能并行地把所有图片同时下载和显示。对于小型网站,由于数据规模小,可以把网站所有页面和图片统一存放在一个主目录下,这样的网站对系统架构、性能要求都很简单。但大中型网站都保存有海量级的图片文件,所采用的技术更是涉及广泛,从硬件到软件、编程语言、数据库、Web服务器、防火墙等各个领域都有较高要求。因此,有必要设立单独的图片服务器来专门存放图片,把图片数据的流量从Web服务器上分离开,这样的架构可以有效缓解Web服务器的I/O性能瓶颈,提升用户的访问速度。

系统架构设计需要满足以下4点要求:(1)图片能进行分布式存储;(2)能实现负载均衡;(3)能根据用户访问量及网站图片数据量的增加能动态添加图片服务器节点;(4)图片服务器节点的动态调整对网站用户而言是透明的,并且不会中断系统的正常运行。系统整体架构如图1所示,包括客户端、Web服务器、数据库服务器、图片服务器集群4个部分。


3.2 图片浏览

客户端用户通过浏览器向Web服务器发出浏览某页面的请求,Web服务器从数据库服务器中获取该页面的所有图片URL信息,并根据URL信息去搜索表1
所列的状态信息表,判断该URL所指向的图片服务器的状态字段FlgUsable,若FlgUsable ==
false表示该图片服务器当前因某种原因处于不可用状态,则把该图片的URL替换成Web服务器上保存的一个默认图片的URL,否则把该URL直接返回给客户端。客户端再根据图片的URL路径自动从不同的图片服务器上下载并显示相应的图片。由于图片URL路径直接指向具体的图片服务器,因此需要在每个图片服务器的保存图片的主目录上建立一个Web站点。由于客户端浏览器所需要的图片是从多个图片服务器上直接下载,因此浏览器可以并发地从多台服务器上同时下载图片,这样就缩短了图片下载时间,同时也减轻了Web服务器的I/O请求及性能压力,因此,提高了网站的访问速度。浏览图片算法如图2所示。


3.3 图片上传

由于B/S架构本身技术限制,图片无法通过Web服务器直接上传到不同的图片服务器,因此需要在所有图片服务器上部署一个Web
Service[6]以便Web服务器可通过调用不同图片服务器上的Web Service执行保存或删除图片的操作。

图片上传的过程比较复杂,首先Web服务器接收客户端的访问请求并访问数据库,通过执行“select * from tb_ServerStatus where
FlgUsalbe = 1 and MaxPicAmount
>CurPicAmount”语句(tb_ServerStatus为表1所列的图片服务器状态信息表),从状态表筛选出可用的图片服务器集合记作
C,并获取集合的总记录数N。然后用随机函数产生一个随机数R1并用R1与N进行取余运算记作I=R1%N。则C[I]即为要保存图片的图片服务器。获取 C
[I]记录中的SubFoldAmount的值记作K,K即为C[I]图片服务器中的图片子目录的个数。为了简化算法,规定所有的子目录名从“0”开始编号,直到“K-1”。例如:SubFoldAmount值为1
000,则图片服务器上图片子目录名分别为“0”、“1”、“2”、…、“999”。再用随机函数生成随机数R2,使得S=R2%K,则S即为要保存的图片的子文件夹名称。为了确保上传的图片名称不重复,以当前时间+随机数的形式组成图片名称。综上所述,通过利用随机函数取值的随机性和取余运算,使每台图片服务器及同一台服务器上的所有图片子目录都有均等的机会保存图片。因此,所有图片都是被随机保存到不同图片服务器的不同子目录中,实现了图片的分布式部署和负载均衡。同时网站管理员也可通过设定服务器状态信息表中的“MaxPicAmount”和“SubFoldAmount”2个字段的值来限定所能保存图片的最大数和子目录数,从而能够根据服务器的硬件配置和性能差异等因素来决定该服务器能保存图片的最大数和子目录数,因此,进一步提升了整个图片服务器集群的负载均衡能力。当需要增加图片服务器时,也只需在状态信息表中增加一条新的图片服务器纪录,添加新图片服务器的过程对整个网站系统的运行没有任何影响,从而实现了图片服务器的动态增加。用户上传图片的算法如图3所示。


3.4 图片删除

客户端向Web服务器发出删除某个图片的请求,Web服务器接收请求并搜索图片数据库获取待删除图片的URL信息。把该URL信息通过字符串运算分隔为图片服务器的URL根路径R、图片所存放的子目录D以及图片名称N。再查找图片数据库状态信息表,获取与R匹配的记录记作C,C即为要删除图片的图片服务器。然后调用C图片服务器上的WebService[7]方法,并以图片名称N和图片所存放的子目录D为参数通知该方法删除该图片,最后把该图片纪录从数据库服务器中删除。用户删除图片信息的算法如图4所示。


3.5 图片修改

修改图片的算法是删除图片和上传图片2个功能的叠加。客户端发出修改图片的请求并把新的图片上传到Web服务器,Web服务器访问数据库获取旧图片的
URL地址,调用删除图片的功能把旧图片删除,最后调用上传图片的功能完成新图片的上传。最后修改图片数据库,纪录新图片的URL路径。其算法流程如图5 所示。


四、系统性能分析

在局域网环境中,对采用图片服务器和不采用图片服务器2种情况进行了性能测试。硬件配置如下:Web服务器、数据库服务器各一台,配置为CPU: Intel
Xeon四核2.2 GHz,内存4 GB,网络带宽100 Mb/s。客户端机器5台为CPU:Pentium 3.0 GHz,内存2 GB,网络带宽100
Mb/s。图片服务器3台,为普通的PC机: CPU: Intel双核P2.0 GHz,内存1
GB,网络带宽100Mb/s。测试数据中共有300万张图片,均匀分布在3台图片服务器上,每台图片服务器建立1
000个子目录。在5台客户端上同时运行压力测试软件,分别模拟200个~1 000个并发用户的请求,测试结果如图6所示。


从图6可以看出,采用3台普通PC机作为图片服务器后,整个系统的响应时间大大减少,性能得到明显提升,而且并发访问量越大,性能的提升越明显,而对于整个系统而言增加的硬件成本却很有限。

五、结束语

面对网站日益增长的图片数据,本文设计并实现了一种适用于中等规模网站的图片分布式部署和负载均衡的解决方案。论述了对图片分布式存储、数据库结构设计及相关查询、修改、删除算法等关键技术。通过性能分析数据可知,该解决方案只需增加很少的硬件成本即可大幅度提升网站的访问速度和运行效率。

时间: 2024-09-20 05:52:50

海量图片系统集群分布式存储和负载均衡案例分享的相关文章

[负载均衡案例分享系列] 一个由负载均衡使用模式导致间断访问失败问题的处理

对于负载均衡的使用,相信大家都不陌生.常见的使用方法是在多台ECS上架设Web服务器后,前端配置负载均衡,将ECS作为后端Real Server,根据实际业务需求,配置TCP模式或HTTP/HTTPS模式提供服务. 本篇文章主要讨论的是负载均衡4层TCP模式下,一种罕见的部署访问模式导致的间断访问失败问题的处理过程.由此大家可以了解到: 1.4层TCP模式下负载均衡的工作原理 2.4层TCP模式下负载均衡访问部署的限制 3.4层TCP模式下负载均衡问题排查的常见思路 4层TCP模式下负载均衡的工

web集群服务的负载均衡方案选择与实现

web 集群系统,是由一群同时运行同一个web应用的服务器组成的集群系统,在外界看来,就像是一个服务器一样.为了均衡集群服务器的负载,达到优化系统性能的目的,集群服务器将众多的访问请求,分散到系统中的不同节点进行处理.从而实现了更高的有效性和稳定性,而这也正是基于Web的企业应用所必须具备的特性. 高可靠性可以看作为系统的一种冗余设定.对于一个特定的请求,如果所申请的服务器不能进行处理的话,那么其他的服务器能不能对之进行有效的处理呢?对于一个高效的系统,如果一个Web服务器失败的话,其他的服务器

高可用集群HA及负载均衡集群LB的实现方法

集群是个热门话题,在企业中越来越多地应用Linux操作系统提供邮件.Web.文件存储.数据库等服务,随着Linux应用的日益增长,高可用及http://www.aliyun.com/zixun/aggregation/13996.html">负载均衡Linux集群也在企业中逐步地发展起来.Linux平台的低成本.高性能.高扩展性使得Linux集群能够以低廉的价格很好地满足各种应用的需求. 本文介绍Linux集群的基础知识,集群的分类.在熟悉集群的基础知识后会以RHCS(RedHat Clu

“Tomcat集群” ,“Tomcat负载均衡”,“Apache整合Tomcat” 这三个是一个意思吗?

问题描述 如果不是,他们有什么区别?在网上搜过,感觉说的是一回事.谁能说说,最好通俗一点? 解决方案 集群的本质是为了增强应用的容错性. 负载均衡则是提高应用的负载性能.当然集群跟负载均衡可以同时使用.apache整合tomcat可以分离静态文件跟动态文件的处理.同时apache具有负载均衡的能力.所以如果做负载均衡.可以选用apache+tomcat,当然也有别的选择.不一定非apache不可

服务器集群中的负载均衡技术深入讲解

&http://www.aliyun.com/zixun/aggregation/37954.html">nbsp;   由于目前现有网络的各个核心部分随着业务量的提高,访问量和数据流量的快速增长,其处理能力和计算强度也相应地增大,使得单一的服务器设备根本无法承担.在此情况下,如果扔掉现有设备去做大量的硬件升级,这样将造成现有资源的浪费,而且如果再面临下一次业务量的提升时,这又将导致再一次硬件升级的高额成本投入,甚至性能再卓越的设备也不能满足当前业务量增长的需求.  针对此情况而衍

方法-应用系统集群部署架构设计(监听、通知)

问题描述 应用系统集群部署架构设计(监听.通知) A类有个a方法,B类有个b方法,当外部调用a方法时,通知b方法执行,如果b方法在执行就不通知其执行,让其继续执行,外部一直在调用a方法,但b方法一直只有一个线程在执行,应用系统是集群部署,不管部署多少应用,b还是只用一个线程在运行,或在1号服务器或在2号服务器或在N号服务器运行.这样的场景怎么去设计怎么实现,请各位大虾提供一些思路或方法,谢谢. 再描述一下场景:应用集群部署,但是公用同一个数据库,系统向外抛一个接口,调用方下行数据,调用方有多个,

集群下并行难题-系统集群的环境下出现的问题

问题描述 系统集群的环境下出现的问题 现在有这么一个情况:一个终端每10秒发出一笔数据,这样的终端有几千个,终端的数据假设有个A类来保存,在我的cache中有一个List来保存数据列表,数据的格式是,如果终端发送数据的时间距离上次发来的时间超过三分钟,那么我记录新记录,否则只更新时间,这种情况在单机环境下没有问题,因为在一台服务器的队列中是有先后顺序,但是如果到了集群环境,上一笔数据访问到第一台服务器,本次数据访问到第二台服务器,这个时候会出现并行计算情况,导致时间段获取不正确,如何解决

使用系统集群技术实现高度可用轻量级LDAP用户管理

设计一个 LDAP http://www.aliyun.com/zixun/aggregation/13687.html">用户管理解决方案应满足以下要求: 服务一个集群环境:该环境严重依赖 于一个一致的注册表视图:所有集群成员必须在任何时候都能访问相同的注册表信息. 包括所有用户和组特权:典型的 LDAP 解决方案把登录凭证和实际组成员分离开来.该解决方案必须能够管理上述两项. 管理一个注册表:典型的 LDAP 解决方案把系统用户和普通用户分开.这就确保当 LDAP 不可访问时,root

Hadoop集群datanode磁盘不均衡的解决方案

一.引言: Hadoop的HDFS集群非常容易出现机器与机器之间磁盘利用率不平衡的情况,比如集群中添加新的数据节点,节点与节点之间磁盘大小不一样等等.当hdfs出现不平衡状况的时候,将引发很多问题,比如MR程序无法很好地利用本地计算的优势,机器之间无法达到更好的网络带宽使用率,机器磁盘无法利用等等. 二.问题: 因业务需要搭建一个新hadoop集群,并将老的hadoop集群中的数据迁移至新的hadoop集群,而且datanode节点不能全部上线,其中还可能会出现节点上线或下线的情况,这个时候就很