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