闲谈 Web 图片服务器

现在很多中小网站(尤其是 Web 2.0 站点) 都允许用户上传图片,如果前期没有很好的规划,那么随着图片文件的增多,无论是管理还是性能上都带来很多问题。就自己的一点理解,抛砖引玉,以期能引出更具价值的信息。

事关图片的存储

把图片存储到什么介质上? 如果有足够的资金购买专用的图片服务器硬件或者 NAS 设备,那么简单的很;如果有能力自己开发单独存储图片的文件系统,那么也不用接着往下看了。

如果上述条件不具备,只想在普通的硬盘上存储,首先还是要考虑一下物理硬盘的实际处理能力。是 7200 转的还是 15000 转的,实际表现差别就很大。是选择 ReiserFS 还是 Ext3 ,怎么也要测试一下吧? 创建文件系统的时候 Inode 问题也要加以考虑,选择合适大小的 inode size ,在空间和速度上做取舍,同时防患于未然,注意单个文件系统下文件个数别达到极限。

独立,独立的服务器

无论从管理上,还是从性能上看,只要有可能,尽量部署独立的图片服务器。这几乎成为常识了(不过在我做过面向 Web 的项目之前就这个问题也被人笑话过)。具备独立的图片服务器或者服务器集群后,在 Web 服务器上就可以有针对性的进行配置优化。比如采用传说中更有效率的 Lighttpd

如果不想在几台机器间同步所有图片,只用 NFS 模式共享一下即可。注意软、硬连接可能带来的问题,以及 NFS 特定的传输速度。

独立,独立的域名

如果大部分 Web 页面必须要载入很多图片,那么需要注意 IE 浏览器的连接数问题(参见对该问题的测试)。

前几天有个朋友在线上问我,”一些大网站,图片服务器为什么都用另外一个域名? 比如yahoo.com 图片服务器用了 yimg.com 的域名?” ,粗糙一点的答案:除了管理方便,便于CDN 同步处理,上面说的 IE 连接数限制也是个考虑因素吧(其他原因我也不知,有请 Yahoo!的同学发言) 【还有一个我没考虑到的是 Cookie 的因素,参加楼下高春辉的留言】

雅虎 Web 优化 14 条

关于雅虎 YSlow 工具倡导的 优化 14 条规则,建议每个 Web 维护人员必须倒背如流,当然也应该辩证来看–介绍这 14 条规则的页面本身也只能得到 70 多分…其中的第九条和上面说的独立域名之间多少有些矛盾。实际情况要根据自己的 Benchmark 与具体需求而确定了。

有效利用客户端 Cache

很多网站的 UI 设计人员为了达到某些视觉效果,会在一些用户需要频繁访问的页面模块上应用大量的图片。这样的情况,研究表明,对于用户粘度比较高的站点, 在Web 服务器上对这一类对象设置 Expires Header 就是十分有必要的,大量带宽就这么节省下来,费用也节省了下来。顺便说一下,对于验证码这样的东西,要加个简单的规则过滤掉。

服务器端的 Cache

在国内,CDN 也是有钱才能玩得起。而类似 Amazon S3 这样的一揽子存储服务,国内还没有出现。所以,充分利用服务器端的 Cache 也是有必要的。Squid 作为反向代理服务器,缓冲图片效果应该说尚可,新浪技术团队贡献的 Ncache 据评测,效果更佳。

服务器端做Cache的好处是显而易见的,一个数据对象的请求时间会控制在 100ms 以内,否则的话,至少要几百个 ms 甚至更长。

高解析图片问题

如果网站存在大量高解析度的图片,那么有必要考虑部署 IIPImage 或者类似的软件。

运营问题

很多比较有规模的网站对于用户上传的图片不做任何处理,结果页面上还能看到很多 BMP 格式的图片(个人觉得任何网站出现 BMP 格式的图片都是可耻的)…这完全是运营上的策略之误了。找个程序员投入一点时间写个图片处理模块,对那些”截屏”得来的图片做个转换,投入成本可能远比存储上的开销小,而用户再访问该图片,质量未必能有什么损失,浏览速度无疑好多了。哪种处理方式更让人接受,不言而喻。

EOF

图片处理工具的选择

可能大多数网站都是选择 ImageMagick 做为基础库,不过这里也有一篇 GraphicsMagick 1.2 vs ImageMagick 6.3.6 Benchmark Report,如果图片处理量巨大,性能问题又怎能不考虑?

Lighttpd 的 ModCache 模块非常值得推荐。

Updated: 对于创业团队来说,推荐又拍云服务,用了都说好。


30 thoughts on “闲谈 Web 图片服务器

  1. Fenng

    @海风
    晕,这也抢沙发…
    心有些乱, 没整理好. 后续再补充些细节内容吧

    Reply
  2. bixuan

    多个域名关键是有一个dns查询的开销,当然,可以针对某几个域名进行ttl的调整。我觉得最大的还是是cookie的影响!
    这里跟大家分享一个经验:如果每天图片增量有100G的话,那么一般情况下,存储用3台750*6(RAID5)的存储就够了。当然看压力适当加cache。

    Reply
  3. ak47

    图片方面的网站是我一直关注的,比如zooomr,虽然期望很高,但是也让人很失望。
    fenng说的算是比较粗略的,其实简单说,如果有钱,就用硬件换效率,如果没钱,就从软件上想办法,不过软件能提高的其实也就那么多。
    国内做图片服务器的主要担忧其实不是服务器。。。。。。

    Reply
  4. 怿飞

    @aw
    就是 taobao.com 域下的 Cookie 信息不会被带到 taobaoimg.com 域下,提高了图片服务器解析 header 头的速度。

    Reply
  5. weavesky.com

    储存介质用NAS其实是不Web 2.0的做法
    更好的是用MogileFS这种分布式文件系统
    我所知道不少Web 2.0的网站就在用这个
    把容量、备份、同步都解决了
    用独立的图片域名甚至更多的域名(例如img1. img2.)的做法,是因为IE等浏览器对单一域名有并发限制,最明显的例子就是如果你打开一个有几十张图片的网页的时候,图片是一张一张出来的,即使你的带宽足够
    CDN是肯定要做的,难道不解决南北问题了?
    (题外话,你用的openid插件不支持昵称)

    Reply
  6. piner

    今天才看到这个帖子
    taobao就建立有大量自己的cdn站点与自己的分布式文件系统。
    关于独立域名,上面的同学说得对,cookie的影响是很大的。如果处理的合理,可以节省大量的带宽费用。

    Reply
  7. Summer

    有问题请教各位:
    我在开发一个多用户blog,分配给用户二级域名。cookie的作用域是 .domain.com
    那么我的静态内容域名和图片域名不能使用 static.domain.com,只能换别的域名了吗?
    换别的域名对网站有何影响?

    Reply
  8. mike

    关注piner的评论
    很想知道taobao的cdn实现方式 bind+squid?
    还有分布式文件系统 现有的还是自己开发的?

    Reply
  9. vox

    在《程序员》上看了你这篇文章的详细版,里面有写到图片服务器由于读操作密集,所以不能用raid5,能说一下为什么吗?我记得raid5只是写的性能比较低,读应该还是可以的。

    Reply
  10. 代码罐头

    实际上还会碰到许多问题
    1.文件的重复性问题(许多用户上传相同内容的文件)
    2.文件的重复存储问题(如果简单实用同步,就会发现每个文件在N台服务器上都有留存,增高了存储成本)
    3.备份问题(那么多文件备份是件很头疼的问题,特别是那么多小文件)
    最后这个解决方案,会越来越类似google file system或者mogilefs

    Reply
  11. wall

    蛮有新意的,呵呵,我想独立图片服务器的其他好处还有:
    1)便于独立权限管理和存储优化
    2)便于WEB SERVER的访问调优

    Reply
  12. fhmob

    冯哥,是这样的,我在别处已经读到过你这篇文章,不过转载来转载去,已经变得有些面目全非了。
    我想请教一个问题,我们做的一个B2C网站,因为是珠宝类的,对于图片的要求非常高,我们自己的投资并不足,所以想到利用yupoo的图片管家服务,这样的话我们网站的图片基本都是存储在yupoo了。速度不算特别快,但是比我们自建服务器好多了。yupoo的技术实力作为yupoo普通用户我非常信赖。我们自己的VPS流量降下来很多,速度提高很多。
    但是后来有朋友建议说这样的图片地址(http://pic.yupoo.com/username/xxxxx.jpg)非常不利于搜索引擎优化!他讲到的几个原则似乎我们都违反了:1、命名中含有关键字;2、放在自己的服务器上,否则可能会被认为是盗链;
    关于这个问题我上网查询了一些资料,在月光博客中还看到有人这么说:我真是不能理解某些图片存储服务商,不但拿走了人家的流量,还要收费。留言中很多人就认为是yupoo。
    我凌乱了!求冯哥指点啊!
    ——————
    这个,我知道说实话可能会得罪一些人,但是,这个只是牵涉技术交流,并无道德评判。

    Reply
  13. Fenng

    我不知道你说的“朋友”究竟对SEO理解有多深,但我可以说,这个和SEO没有实际的关系,基本上等同于扯淡。
    你这样考虑好了:国外有大量的网站在用Amazon之类的云存储服务,难道他们都傻透了么?

    Reply
  14. fhmob

    呵呵,冯哥回的速度挺快的哈,请允许我把这个源地址贴上,如果不便通过留言审核的话,直接删除吧。以免引起不必要的误会。
    http://www.williamlong.info/archives/1330.html 我是29#的回复,加上提建议的是以前搜房网的一个朋友,心里忐忑了半天。
    既然冯哥这么说,而且我现在用的也确实很不错,yupoo的API接入后舒服的很,还是现在这样就好了,其他方面注意一下优化即可。

    Reply
  15. Fenng

    你提到的那个Blog中的观点颇有些脑残,难道网络上带宽是免费的?
    别人帮你承担带宽,提升你页面的访问速度,收费(如果收费的话)不是天经地义的么?
    做事情是以用户体验为上还是以SEO为上?不是目标用户SEO来有个鸟用呢?

    Reply
  16. liubw320

    你好,博主,读了你的这篇博文,我尝试使用了 GraphicsMagick 这个图片处理工具。测试发现,在本地环境下, GraphicsMagick的确是比ImageMagick快很多,特别是内存优化这一块,GM做得更为出色。但真正放上线后,GM的处理速度就慢很多了,有时候上传一张图片,GM处理,可能会达到10秒的时间,而在同一环境下,IM要快很多;初步认为,GM存在并发处理上的问题,诚心请教,我该如何解决这个问题,或者提供一点思路,指点指点后辈,谢谢!

    Reply
  17. virusswb

    图片服务器还应该包含一整套图片的接口,保存,获取,生成缩略。
    对外应该屏蔽文件系统信息。
    具体的存储位置由图片服务器来决定,或者说设定几种可选的位置,变成接口的参数,但是接口不用关心具体的文件目录。

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *