架构高性能海量图片服务器的技术要素

在笔者的另一篇文章《nginx性能改进一例》有讲到,在图片规模比大的情况,nginx处理能力受制于文件系统的io,意味着,在大规模图片的场景,如果运维还依旧采用传统文件系统的方式,无论是备份成本,还是前端成本,将是无法去衡量,不要去指望调优一点文件系统的一些参数,能带来多大的性能收益,也不要去目录hash+rewrite的方式,改进不大,因为新版的文件系统默认开启了dir_index,解决了同一个目录下文件过多而过慢的问题。不过还有一种方案就是采购SSD盘、fusion-io卡之类高性能的硬件去解决随机io,当然你得容忍备份的痛苦。
先看一下架构图逻辑图,这也是现在各大公司采用的方式。

架构高性能海量图片服务器的技术要素

架构高性能海量图片服务器的技术要素

这个是一个大致逻辑图,具体布署是根据模块的性能消耗类型去混合部署。
第一点,分布存储的必要性:存储原始图片,用分布式存储有几个好处,分布式能自动提供冗余,不需要我们去备份,担心数据安全,在文件数量特别大的情况下,备份是一件很痛苦的事情,rsync扫一次可能是就是好几个小时。还有一点就是分布式存储动态扩容方便。不过唯一遗憾的是目前适合于存小文件系统比较少,我了解的只有fastdfs,以及淘宝的tfs,还有mongodb这几个,tfs经历过淘宝那种规模的考验,文档和工具都太少,如果能驾驭tfs,我觉得值得尝试一下。。

第二点,上传和下载分开处理:通常图片服务器上传的压力与下载的压力相差很大,大多数的公司都是下载的压力是上传压力的n倍。业务逻辑的处理也区别明显,上传服务器对图片重命名,记录入库信息,下载服务器对图片添加水印、修改尺寸之类的动态处理。从数据的角度,我们能容忍部分图片下载失败,但绝不能有图片上传失败,因为上传失败,意味着数据的丢失。上传与下载分开,能保证不会因下载的压力影响图片的上传,而且还有一点,下载入口和上传入口的负载均衡策略也不同,下面有说明。

第三点,使用cache做缓层:分布式存储解决了存储安全问题,但性能问题还需要用cache去解决,直接从分布式存储取文件给用户提供服务,每秒的request高不到哪里去,像淘宝之类的网站,都做了二层cache。对于cache的开源软件选型要考虑二点,1,缓存的量级大,尽可能让热点图片缓存在cache中,像varnish之类的,纯内存的cache,虽然性能很好,但能cache的量级很限于内存,用来做图片的缓存不太适合;2,避免文件系统式的缓存,在我的另一篇文章中有测过,在文件量非常的情况下,文件系统的型能很差,像squid,nginx的proxy_store,proxy_cache之类的方式缓存,当缓存的量级上来后,性能将不能满足要求。开源的traffic server直接用裸盘缓存,是一个不错的选择,当然使用leveldb之类的做缓存,我估计也能达到很好的效果。这里说明一下cache缓存最好不要去依赖第三方CDN,现在很多第三的CDN业务,不仅提供内容分发外,还额外提供第一个二级缓存之类的服务,但这里面就一个最大的风险就是如果第三调整带来的回源压力暴增,此时你的架构能否支撑,需要认真评估一下,如果成本允许,服务控制在自己手中最靠谱。

第四点,使用一致性哈希(consistent hashing)做下载负载均衡:虽公司的业务的增加带来流量的增加,一个阶段后,一个cache通常不能解决问题,这时扩容cache就是常做的一件事,传统的哈希不足就是每扩容一次,哈希策略将重新分配,大部分cache将失效,带来的问题是后端压力暴增。对uri进行一性能哈希负载均衡,能避免增加或者减少cache引起哈希策略变化,目前大多开源的负载均衡软件都有这个功能,像haproxy都有,至于一致性哈希的最优化,可以参考一下下图(摘自网上的一张图,表示的是怎样的物理节点和虚拟节点数量关系,哈希最均匀)。

第五点,利用CDN分发和多域名访问入口:想要获得好的用户体验,利用CDN的快速分发是有必要的,从成本上考虑可以购买使用第三方的CDN平台。多域名访问方式,大多的浏览器都对单个域名进行了线程并发限制,采用多域名能够加快图片展示的速度。
关于图片服务器的部署基本算完了,其它的细节性调优这里就不说明了。

以上文章装载自:http://my.oschina.net/beiyou/blog/83210

赞(0)
未经允许不得转载:代码'S Blog » 架构高性能海量图片服务器的技术要素
分享到: 更多 (0)