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

在图片规模比大的情况，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平台。多域名访问方式，大多的浏览器都对单个域名进行了线程并发限制，采用多域名能够加快图片展示的速度。