看了网上大部分文章,在此做一个总结:

由于网站规模扩大,程序和图片放在同一个服务器,将不能满足需要。

所以要将图片存储在单独的服务器上,下面总结了三种方案

一.  NFS方案

此结构说明
1 mount目录说明
所有前端web服务器都通过nfs挂载3台图片服务器export出来的目录,以接收web服务器PHP进程写入的图片。然后image1挂载另外两台图片服务器的export目录到本地给nginx对外提供访问。
2 用户上传图片说明
用户通过Internet访问页面提交上传请求post到web服务器,web服务器处理完图片后由php拷贝到对应的mount本地目录。
3 用户访问图片说明
用户访问图片时,通过image1这台图片服务器来访问通过2.1里边说明的目录以访问对应目录里边的图片。

现有结构的问题
1 现有结构过度依赖nfs,当图片服务器的nfs服务器有问题时,可能影响到前端web服务器。
2 现有对外服务的图片服务器只有一台,这个服务器是个单点。
3 服务器之间的依赖过多,而且横向扩展余地不够。
4 web服务器上传热点不可控,造成现有图片服务器空间占用不均衡。
5 nfs方式对于拥有web服务器的密码的人来说,可以随意修改nfs里边的内容,安全级别不高。

二.  在图片服务器上部署一个提供上传服务的应用

用户上传流程
用户上传图片到web服务器后,web服务器处理完图片,然后再由前端web服务器把图片post到对应设置ID的图片服务器,图片服务器php接收到post过来的图片,然后把图片写入到本地磁盘并返回对应成功状态码。前端web服务器根据返回状态码决定对应操作,如果成功的话,把图片服务器对应的ID和对应图片路径写入DB数据库。
用户访问流程
用户访问页面的时候,根据请求从数据库读取图片服务器ID和图片的URL,拼写成对应URL到对应图片服务器去访问图片。
上传控制
我们需要调节上传时,只需要修改web服务器post到的目的图片服务器的ID,就可以控制上传到哪台图片服务器。
新结构优点
1 整个结构中无任何nfs的依赖关系,同时也不会因为图片服务器的故障影响到web服务器。
2 对外服务的图片服务器不再是单点,而且单台图片服务器故障也不会导致所有图片受影响。
3 图片服务器之间无任何依赖关系,图片服务器的横向扩展空间很大。
4 能随时调节上传热点,均衡图片服务器空间。
5 能随时规避故障服务器,从而不会影响到前端上传。
6 改造后的图片服务器中文件对于web服务器完全不可见,提高了安全级别。

三.   采用应用层第三方软件同步方案

将图片上传到web服务器,在同步到图片服务器。

csync2+inotify、rsync、unison、DRBD、tsync

四.  采用应用层分布式文件系统同步方案-投入比较大

FastDFS、MogileFS、Hadoop HDFS

参考:http://www.javabloger.com/article/nginx-moosefs-hbase-haproxy.html