针对海量承载商品图片的解决方案学习
栏目：框架设计时间：2015-01-07 08:25:15
前言：
随着计算机网络技术的发展和普及,出现了愈来愈多像,“淘宝”,”京东”等大型电子商务网站。这类网站都保存有大量图片资源。用户在访问这些站点网页时,网页中图片信息占到页面数据流量的大部份。由于受客户端阅读器限制,没法从1台服务器上同时下载页面中所有图片信息,因此即便服务器有很高带宽,用户的访问速度还是会遭到很大影响。由于图片保存在物理硬盘上,访问图片需要频繁进行I/O操作,因此当并发用户数愈来愈多时,I/O操作就会成为全部系统的性能瓶颈。
对大型的网站系统来讲，由于具有雄厚的资金，可使用 NFS、CDN、Lighttpd等技术提高用户的访问速速。但这些技术需要庞大的资金支持,对处于创业早期中等范围的商务网站,由于缺少必要的资金支持,因此没法采取这些技术提升网站的访问速度 。今天我们讲1个适用于中等范围商务网站的海量图片数据散布式动态存储及负载均衡的解决方案。该方案只需增加很少的硬件本钱,便可提升网站的访问速度,并且可以根据需要动态调剂图片服务器的数量及图片的存储目录,确保系统具有可扩大性和伸缩性。系统架构设计：
对Web服务器而言，用户对图片信息的访问是很消耗服务器资源的。当1个网页被阅读时,Web服务器与阅读器建立连接,每一个连接表示1个并发。当页面包括多个图片时,Web服务器与阅读器会产生多个连接,同时发送文字和图片以提高阅读速度。因此,页面中图片越多Web服务器遭到的压力也就越大。对小型网站,由于数据范围小,可以把网站所有页面和图片统1寄存在1个主目录下,这样的网站对系统架构、性能要求都很简单 。但大中型网站都保存有海量级的图片文件,所采取的技术更是触及广泛 ，因此,有必要设立单独的图片服务器来专门寄存图片,把图片数据的流量从Web服务器上分离开,这样的架构可以有效减缓Web服务器的I/O性能瓶颈 ，提高用户的访问速度.
系统架构设计需要满足4点要求：
(1)图片能进行散布式存储;(2)能实现负载均衡;
(3)能根据用户访问量及网站图片数据量的增加能动态添加图片服务器节点;
(4)图片服务器节点的动态调剂对网站用户而言是透明的,并且不会中断系统的正常运行。
架构说明：
数据库服务器用于记录所有图片的编号和图片的寄存位置等信息,同时需要记录所有图片服务器的配置及当前状态信息（这里学习下心跳机制，负责监听图片服务器的状态，下面百科了心跳机制的方法）。
图片服务器集群用于寄存网站的所有图片信息,该集群的服务器数量可以根据需要动态增加。
系统实现及关键技术：
增加了图片服务器后,对客户端而言,全部网站系统履行进程应当依然是透明的,不会给用户带来任何影响。但后台系统需要解决以下4个问题:(1)如何实现图片的散布式部署,图片上传时如何动态肯定保存到哪台图片服务器;
(2)如何做到图片服务器的负载均衡,既要保证所有图片服务器都有均等的机会来保存图片.
(3)如何把1台图片服务器上图片均衡保存到多个子目录中以便突破操作系统在同1个目录中保存文件数的限制,对图片进行更好的管理和保护;
(4)如何能根据性能需要和图片数量的增加实现图片服务器的动态扩充。
数据库设计：
Web服务器需要及时掌握所有图片服务器的状态和信息才能动态决定把图片保存到哪1台图片服务器,因此,需要把所有的图片服务器的状态信息全部纪录到数据库服务器中, 状态信息表中的ServerId字段为主键自增列,唯1代表1条图片服务器纪录。ServerName字段记录服务器的名称,方便管理员辨认该记录代表哪台服务器。
ServerUrl字段标识了图片服务器上图片主目录的URL根路径。
PicRootPath字段标识了保存图片的物理主目录。
MaxPicAmount字段表示图片服务器能保存的最大图片数,该数可以根据图片服务器的硬件配置和性能和用户实际需要而进行动态调剂。
CurPicAmount字段表示当前已保存的图片数,当CurPicAmount≥MaxPicAmount时系统将不再把图片上传到该服务器。
FlgUsable字段表示图片服务器是不是可用。
图片文件上传：
由于B/S架构本身技术限制,图片没法通过Web服务器直接上传到不同的图片服务器,因此需要在所有图片服务器上部署1个Web Service以便Web服务器可通过调用不同图片服务器上的Web Service履行保存。从状态表挑选出可用的图片服务器集合记作C,并获得集合的总记录数N。然后用随机函数产生1个随机数R1并用R1与N进行取余运算记作I=R1%N。则C[I]即为要保存图片的图片服务器。图片阅读：
客户端用户通过阅读器向Web服务器发出阅读某页面的要求,Web服务器从数据库服务器中获得该页面的所有图片URL信息,并根据URL信息去搜索图片服务器的状态信息表,判断该URL所指向的图片服务器的状态字段FlgUsable,若FlgUsable == false表示该图片服务器当前因某种缘由处于不可用状态,则把该图片的URL替换成Web服务器上保存的1个默许图片的URL,否则把该URL直接返回给客户端。客户端再根据图片的URL路径自动从不同的图片服务器上下载并显示相应的图片。由于图片URL路径直接指向具体的图片服务器,因此需要在每一个图片服务器的保存图片的主目录上建立1个Web站点。由于客户端阅读器所需要的图片是从多个图片服务器上直接下载,因此阅读器可以并发地从多台服务器上同时下载图片,这样就缩短了图片下载时间,同时也减轻了Web服务器的I/O要求及性能压力,因此,提高了网站的访问速度 .
附-心跳机制：
网络中的接收和发送数据都是使用操作系统中的SOCKET进行实现。但是如果此套接字已断开，那发送数据和接收数据的时候就1定会有问题。可是如何判断这个套接字是不是还可使用呢？这个就需要在系统中创建心跳机制。其实TCP中已为我们实现了1个叫做心跳的机制。如果你设置了心跳，那TCP就会在1定的时间（比如你设置的是3秒钟）内发送你设置的次数的心跳（比如说2次），并且此信息不会影响你自己定义的协议。所谓“心跳”就是定时发送1个自定义的结构体（心跳包或心跳帧），让对方知道自己“在线”。 以确保链接的有效性。所谓的心跳包就是客户端定时发送简单的信息给服务器端告知它我还在而已。代码就是每隔几分钟发送1个固定信息给服务端，服务端收到后回复1个固定信息如果服务端几分钟内没有收到客户端信息则视客户端断开。比如有些通讯软件长时间不使用，要想知道它的状态是在线还是离线就需要心跳包，定时发包收包。发包方：可以是客户也能够是服务端，看哪边实现方便公道。1般是客户端。服务器也能够定时轮询发心跳下去。心跳包之所以叫心跳包是由于：它像心跳1样每隔固定时间发1次，以此来告知服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有甚么特别规定的，不过1般都是很小的包，或只包括包头的1个空包。在TCP的机制里面，本身是存在有心跳包的机制的，也就是TCP的选项。系统默许是设置的是2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。而且逻辑层处理断线可能也不是那末好处理。1般，如果只是用于保活还是可以的。心跳包1般来讲都是在逻辑层发送空的包来实现的。下1个定时器，在1定时间间隔下发送1个空包给客户端，然后客户端反馈1个一样的空包回来，服务器如果在1定时间内收不到客户端发送过来的反馈包，那就只有认定说掉线了。只需要send或recv1下，如果结果为零，则为掉线。但是，在长连接下，有可能很长1段时间都没有数据来往。理论上说，这个连接是1直保持连接的，但是实际情况中，如果中间节点出现甚么故障是难以知道的。更要命的是，有的节点（防火墙）会自动把1定时间以内没有数据交互的连接给断掉。在这个时候，就需要我们的心跳包了，用于保持长连接，保活。在获知了断线以后，服务器逻辑可能需要做1些事情，比如断线后的数据清算呀，重新连接呀固然，这个自然是要由逻辑层根据需求去做了。总的来讲，心跳包主要也就是用于长连接的保活和断线处理。1般的利用下，判定时间在30⑷0秒比较不错。如果实在要求高，那就在6⑼秒。
------分隔线----------------------------
下一篇 SQL2012数据库加密方法
------分隔线----------------------------