图片存储构架学习

一、部署独立图片服务器的必要性

  无论对于Apache还是IIS,图片始终是最消耗系统资源的,如果将图片服务和应用服务放在同一个服务器的话,应用服务器很容易会因为图片的高I/O负载而崩溃,因此对于有些大型网站项目,我们有必要将图片服务器和应用服务器分离。

  部署独立的图片服务器(甚至是服务器集群)是大型网站图片存储解决方案中最基础的。因为有了独立的图片服务器后,我们才能对图片服务器做更有针对性的性能优化,比如从硬件角度说,图片服务器可以配置高端的硬盘,7200转的换成15000转的,而CPU却只要一般就可以了;从软件角度说,可以为图片服务器配置特殊的文件系统来满足对图片的I/O请求,如淘宝的TFS,就很好地解决了大规模小图片文件带来的I/O噩梦,同时,我们也可以采用nginx、squid来代理图片请求等等。

二、采用独立域名

  注意,这里是指独立域名,不是子域哦,比如yahoo.com图片服务器用了yimg.com的域名,而不是用二级域名img.yahoo.com,这是为什么呢?个人觉得原因主要有以下几点:

  (1) 同一域名下浏览器的并发连接数有限制,一般在2 - 6之间

    如果给图片服务器配置独立的域名,那么在一个页面中加载图片时,就可以突破浏览器连接数的限制,理论上,增加一个独立域名,并发连接数加倍。

  (2) 由于cookie的原因,对缓存不利

    比如有一张图片http://www.test.com/img/xx.gif,那么当我们向它发起请求的时候,会带上www.test.com域名下的cookie,由于大部分web cache都只缓存不带cookie的请求,这样就导致每次的图片请求都不能命中cache,而仍旧要去原始服务器获取图片,导致图片缓存意义不大。所以,还是给单独搞一个图片独立域名吧,当然,不只是图片,css和js文件也可以参照这个思路来搞。

  (3) 方便CDN同步

三、图片服务器分离后,如何进行图片上传和图片同步

当然任何事物都具有两面性,图片服务器分离固然提升了图片访问的效率,大大缓解了服务器因图片造成的I/O瓶颈,但是分离以后图片的上传和同步就成了一个大问题了。下面就我个人的想法谈谈几种解决方案。

1、NFS共享方式

如果你不想在每台图片服务器同步所有图片,那NFS共享是最简单也最实用的方式。NFS是个分布式的客户机/服务器文件系统,NFS的实质在于用户间计算机的共享,用户可以联结到共享计算机并象访问本地硬盘一样访问共享计算机上的文件。

具体实现思路是:web服务器通过nfs挂载多台图片服务器export出来的目录,用户先将图片上传到web服务器,然后将上传的图片通过程序拷贝到这个mount目录中去,这样那几台图片服务器就也能访问到刚上传的图片了(注意,只是共享了,并没有真正拷贝到图片服务器)。再给那几台图片服务器绑定独立域名,于是浏览器端就可以用单独的域名来访问图片了。这种方式基本不会有因同步造成的延时,但需要依赖NFS,NFS挂掉会影响web服务器。为了更直观的表达,我还是上一幅图吧,画得比较粗糙,大家将就着看看。

NFS入门基础  

  NFS,是Network File System的简写,即网络文件系统。NFS允许一个系统在网络上与他人共享目录和文件。通过使用NFS,用户和程序可以像访问本地文件一样访问远端系统上的文件。

 NFS组成:

  NFS至少有两个主要部分:一台服务器和一台(或者多台)客户机。客户机远程访问存放在服务器上的数据。为了正常工作,一些进程需要被配置并运行。

  NFS应用:

  NFS有很多实际应用。下面是比较常见的一些:

  1.多个机器共享一台CDROM或其他设备。这对于在多台机器中安装软件来说更加便宜跟方便。

  2.在大型网络中,配置一台中心NFS服务器用来放置所有用户的home目录可能会带来便利。这些目录能被输出到网络以便用户不管在哪台工作站上登录,总能得到相同的home目录。

  3.几台机器可以有通用的/usr/ports/distfiles目录。这样的话,当您需要在几台机器上安装port时,您可以无需在每台设备上下载而快速访问源码。

   以下是NFS最显而易见的好处:

  1.本地工作站使用更少的磁盘空间,因为通常的数据可以存放在一台机器上而且可以通过网络访问到。

   2.用户不必在每个网络上机器里头都有一个home目录。Home目录可以被放在NFS服务器上并且在网络上处处可用。

   3.诸如软驱,CDROM和 Zip(是指一种高储存密度的磁盘驱动器与磁盘)之类的存储设备可以在网络上面被别的机器使用。这可以减少整个网络上的可移动介质设备的数量。

  

  2、利用FTP同步

    和上面nfs不一样的是,用户上传完图片后是利用ftp同步到各个图片服务器的,php、java、asp.net基本上都能操作ftp。这样的话每个图片服务器就都保存一份图片的副本,也起到了备份的作用。但是缺点是将图片ftp到服务器比较耗时,如果异步去同步的话又会有延时,不过一般的小图片文件也还好了。

    当然除了上面两种方法,还有诸如安装同步软件、webservice等方法,但我个人觉得上面2种比较靠谱一点,所以其他的就暂时不介绍了,如果各位朋友有更好地建议,请留言分享。

好了,对于独立图片服务器的介绍就到这里了,欢迎大家补充,咱们下回见。

时间: 2024-10-06 23:27:05

图片存储构架学习的相关文章

D瓜哥分享的架构资料

扯扯蛋 以前见过零零散散地介绍一些知名网站架构的分析文章.最近D瓜哥也想研究一下各大知名网站的架构.所以,就搜集了一下这方面资料.限于时间问题,这篇文章分享的文章并没有都看完,所以不保证所有文章的质量.另外,如果有朋友发现更好的文章,欢迎留言告知.再补充进来. 知名网站架构分析 探索Google App Engine背后的奥秘(1)–Google的核心技术 探索Google App Engine背后的奥秘(2)–Google的整体架构猜想 探索Google App Engine背后的奥秘(3)-

【Java技术点滴】——精简实现图片处理

 引言: 对于图片的处理是很多项目中都会用到的,如一般的人事管理系统等,处理方式主要分为两大类: 1.图片文件存储与磁盘中,数据库中只保存相对应的文件名: 2.文件采用二进制的形式保存于数据库中. 第二种方案占用空间大,并且对二进制流的操作也较为占用资源,因此采用第一种方案进行处理的情况较为常见,常用于一般的系统应用中,正在进行中的drp项目中用到了图片上传.显示的功能处理,采用commons-fileupload1.1.1版本,可以实现多文件的上传功能. 实现: 引入相关jar包后,对方法

架构方面的资料集锦

转自:http://www.diguage.com/archives/41.html 扯扯蛋 曾经见过零零散散地介绍一些知名站点架构的分析文章.近期D瓜哥也想研究一下各大知名站点的架构. 所以,就搜集了一下这方面资料. 限于时间问题,这篇文章分享的文章并没有都看完,所以不保证全部文章的质量.另外.假设有朋友发现更好的文章.欢迎留言告知.再补充进来. 知名站点架构分析 探索Google App Engine背后的奥秘(1)–Google的核心技术 探索Google App Engine背后的奥秘(

[转载] 分享D瓜哥最近攒的资料(架构方面)

原文: http://www.diguage.com/archives/41.html 扯扯蛋 以前见过零零散散地介绍一些知名网站架构的分析文章.最近D瓜哥也想研究一下各大知名网站的架构.所以,就搜集了一下这方面资料.限于时间问题,这篇文章分享的文章并没有都看完,所以不保证所有文章的质量.另外,如果有朋友发现更好的文章,欢迎留言告知.再补充进来. 知名网站架构分析 探索Google App Engine背后的奥秘(1)–Google的核心技术 探索Google App Engine背后的奥秘(2

网站架构资料集(转)

add by zhj:很多文章是转自www.itivy.com,很可惜,这个网站已经无法访问,不过,你可以用Google搜索一下这些文章,另外 各大网站架构总结笔记 也能看到部分转载的原文. 原文:http://www.diguage.com/archives/41.html 扯扯蛋 以前见过零零散散地介绍一些知名网站架构的分析文章.最近D瓜哥也想研究一下各大知名网站的架构.所以,就搜集了一下这方面资料.限于时间问题,这篇文章分享的文章并没有都看完,所以不保证所有文章的质量.另外,如果有朋友发现

网络编程之网络协议

一.C/S构架 学习网络编程就是要通过网络来访问另一台计算的数据,这样必然需要至少两台计算机,一台计算机上放着要分享的数据和用于分享数据的程序,另一台计算机上运行访问数据的程序, 我们把提供数据的一方称之为服务器(Server),把访问数据的一方称为客户端(Client),这就是C/S架构 二.网络通讯的基本要素 两台计算机要想通讯,必须要具备两个基本要素 1.物理连接介质,包括网线,无线电,光纤等 2.通讯协议 下面我们来分析为什么需要这两个东西 1.物理连接介质 人类说话需要有空气来传播震动

[转载]SharePoint 2013搜索学习笔记之搜索构架简单概述

Sharepoint搜索引擎主要由6种组件构成,他们分别是爬网组件,内容处理组件,分析处理组件,索引组件,查询处理组件,搜索管理组件.可以将这6种组件分别部署到Sharepoint场内的多个服务器上,组成适合需求的Sharepoint搜索场,搜索场的体系结构设计主要参考量是爬网内容量,微软根据爬网内容量不同将搜索场分为大型场,中型场和小型场,更多详细信息可参考: SharePoint Server 2013 中的搜索概述和在SharePoint Server 2013 中规划企业搜索体系结构.

Sharepoint2013搜索学习笔记之搜索构架简单概述(一)

Sharepoint搜索引擎主要由6种组件构成,他们分别是爬网组件,内容处理组件,分析处理组件,索引组件,查询处理组件,搜索管理组件.可以将这6种组件分别部署到Sharepoint场内的多个服务器上,组成适合需求的Sharepoint搜索场,搜索场的体系结构设计主要参考量是爬网内容量,微软根据爬网内容量不同将搜索场分为大型场,中型场和小型场,更多详细信息可参考:SharePoint Server 2013 中的搜索概述和在SharePoint Server 2013 中规划企业搜索体系结构. S

Unity3d之Hash&Slash学习笔记(一)--角色属性类的构架

角色属性类的构架 角色属性类有8个类,继承关系如下图: 每个类的具体作用见之后的随笔 Unity3d之Hash&Slash学习笔记(一)--角色属性类的构架