nginx 图片服务

网上找的，感受还不错

1 介绍

如今不少的网站上都会用到大量的图片，而图片是网页传输中占主要的数据量,也是影响网站性能的主要因素。所以不少网站都会将图片存储从网站中分离出来，另外架构一个或多个服务器来存储图片，将图片放到一个虚拟目录中，而网页上的图片都用一个URL地址来指向这些服务器上的图片的地址，这样的话网站的性能就明显提升了，图片服务器(ImageServer)的概念也就产生了。

1.1 图片服务器的优点

 

1， 分担Web服务器的I/O负载-将耗费资源的图片服务分离出来，提升服务器的性能和稳定性。

2， 可以专门对图片服务器进行优化-为图片服务设置有针对性的缓存方案，减小带宽成本，提升访问速度。

3， 提升网站的可扩展性-经过增长图片服务器，提升图片吞吐能力。

 

1.2 图片服务器的注意事项

1， 选择适合图片存储的物理介质和文件系统

2， 使用物理上独立的服务器

3， 若是拥有多台图片服务器，要考虑服务器之间的图片同步问题

4， 使用独立域名

5， 制定合理的缓存策略

6， 使用图片处理模块对用户上传的图片进行再加工

1.3 图片服务器的架构

图片是网站中必不可少的一个组成部分，随着网站的不断发展，对图片的处理也将随着访问的增加，图片的增长提出不断改进的需求， 网站初期，全部的一切都从简图片所存在的位置一般会在站点下的Images文件夹。

随着访问的增长，IIS压力的增大，开始作拆分，将图片文件夹做为单独站点提取出来如http://images.***.com/(可能根据须要会拆分红多个图片服务器，与具体业务环境相关)，拆分以后很好的将单个IIS应用池的压力分担到2个乃至多个上，大大提升访问瓶颈。随着访问的进一步增长，服务器压力已经没法支撑，这时咱们须要将图片站点做为独立服务器存在。在访问图片的过程当中，咱们可能会面临一个图片有多个图片尺寸的需求，前期咱们一般会在保存页面的过程当中保存咱们须要的各个尺寸图片，但随着所需尺寸的不一样，保存图片时须要的尺寸愈来愈多，这时咱们如何应对？

IIS服务器的并发访问意味着随着用户的进一步增长，咱们单台图片服务器已经不足以应对了，此时咱们如何进一步扩展？

 

如上图所示，咱们此时可针对这两个问题作出统一解决方案，在前端添加squid缓存服务器，添加一台或者多台动态切图服务器。Squid或者Nginx代理缓存服务器可以极大的提高图片系统的并发访问，使系统突破现有限制。动态切图服务器主要的做用是针对不一样尺寸的图片访问调取原图临时生成符合需求的图片并返回。原图的存储区能够与图片服务放在一块儿，也能够讲图片放于单独的服务器上。

在此种结构中，并发的最大访问限制将是squid或者其余代理服务器的系统瓶颈，当切图服务压力增大时，只需添加相应切图服务器便可，图片存储区的增加也可经过添加硬盘或者服务器进行解决。

若是您的站点访问量还在进一步增加，squid的访问瓶颈即将被突破，这时咱们又该如何应对呢？

 

如上图所示，采用多台Squid或Nginx服务器，在前端添加F5或LVS负载均衡(同时还可开启缓存功能)。此时将极大提高访问的并发量，能够根据状况随时调配服务器。固然此时也存在必定的瑕疵，那就是可能在多台Squid上存在同一张图片，由于访问图片时可能第一次分到squid1，在F5过时后第二次访问到squid2或者别的，固然相对并发问题的解决，此种少许的冗余彻底在咱们的容许范围以内。在作了这许多的工做后，若是条件容许对图片服务器作下CDN，那将会对您站点的图片访问质量有更大的提高。

 

1.4 图片存储架构

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

咱们知道，不管对于Apache仍是IIS，图片始终是最消耗系统资源的，若是将图片服务和应用服务放在同一个服务器的话，应用服务器很容易会由于图片的高I/O负载而崩溃，所以对于有些大型网站项目，咱们有必要将图片服务器和应用服务器分离。部署独立的图片服务器（甚至是服务器集群）是大型网站图片存储解决方案中最基础的，由于有了独立的图片服务器后，咱们才能对图片服务器作更有针对性的性能优化，好比从硬件角度说，图片服务器能够配置高端的硬盘，7200转的换成15000转的，而CPU却只要通常就能够了；从软件角度说，能够为图片服务器配置特殊的文件系统来知足对图片的I/O请求，如淘宝的TFS，就很好地解决了大规模小图片文件带来的I/O噩梦，同时，咱们也能够采用nginx、squid来代理图片请求等等。

 

1.4.2 采用独立域名

注意，这里是指独立域名，不是子域哦，好比yahoo.com图片服务器用了yimg.com的域名，而不是用二级域名img.yahoo.com，这是为何呢？我的以为缘由主要有如下几点：

一、同一域名下浏览器的并发链接数有限制，通常在2 - 6之间，下图列举了各个浏览器的并发链接数（下图供参考）

    

这样，咱们若是给图片服务器配置独立的域名，那么在一个页面中加载图片时，就能够突破浏览器链接数的限制，理论上，增长一个独立域名，并发链接数加倍。

二、因为cookie的缘由，对缓存不利

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

三、方便CDN同步

 

1.4.3 图片服务器分离后，如何进行图片上传和图片同步

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

一、NFS共享方式

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

具体实现思路是：web服务器经过nfs挂载多台图片服务器export出来的目录，用户先将图片上传到web服务器，而后将上传的图片经过程序拷贝到这个mount目录中去，这样那几台图片服务器就也能访问到刚上传的图片了（注意，只是共享了，并无真正拷贝到图片服务器）。再给那几台图片服务器绑定独立域名，因而浏览器端就能够用单独的域名来访问图片了。这种方式基本不会有因同步形成的延时，但须要依赖nfs，nfs挂掉会影响web服务器。以下图

至于如何配置nfs，你们google一下，或者看一下这篇文章，是在Linux下配置NFS的http://blog.csdn.net/lixinso/article/details/6639643

二、利用FTP同步

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

 

2 图片服务器的URL HASH架构剖析 

2.1 什么是url hash 架构

url hash架构对url进行一次hash算法，而后经过hash结果找到对应的服务器。由于针对单一个url的hash结果是同样的，因此理论上这个url会被永久分配到固定的一台服务器上。另外由于通过了hash算法，因此分配url就很均匀，同时访问量也能够达到均衡。

 

2.2 为何要用url hash架构 

1, 图片服务器的特色一是访问量很大，二是容量也很大，经过简单的负载均衡，能够解决访问量大的问题，可是容量的问题并无改善。因此会形成容灾问题。

2, 容灾问题：系统某个时间段被访问的数据严重超出缓存集群中最小单机的容纳容量就会形成容灾，容灾会使大量单一连接穿透，直接对后台的IO性能影响很大。

3, 虽然能够经过增长缓存容量的配置来解决容灾问题，可是内存老是有限的，为每一台机器增长超大内存成本上也开销很大，另外在squid中也不宜配置很大的磁盘缓存，不然squid中的hash表会很大，性能不好。

4, 经过hash架构，能够充分利用缓存集群的内存，容灾问题就再也不取决于缓存集群中最小单机的容纳容量，而是缓存集群中全部机器的容纳容量之和。

2.3 各类url hash架构

1）基于dns的hash架构。

2）基于nginx的自动hash架构。

3）基于nginx的手动hash架构。

 

2.3.1 基于dns的hash架构

dns的hash架构图

 

 

dns的hash架构说明

这个架构适合面向用户的图片系统，好比论坛、相册、博客中的图片上传。这样它才可以保证文件名有一致的规范。

这个架构图分了36个域名，图片文件名是用md5值起的，在md5值中取一位字母就能够代表它是在哪一个域名里，域名就对应了机器，上传分发的时候也是根据此字母来分发。

 

dns的hash架构的优缺点

优势：

1）使用了dns分流，成本较低，并且dns性能高，不用维护。

2）可突破IE默认每主机2个线程的限制。

缺点：

1）可用性方面，若是有一台机器宕机，则指向这台机器的请求没法读取。

2）分流方面，只能所有同步，成本较高

3）只适用于面向用户的系统

 

2.3.2 基于nginx的自动手动hash架构

nginx的自动hash架构图

 

nginx的自动hash架构说明

1, 这是一种新的缓存架构，由nginx做为最前端，代理到缓存机器。

2, nginx后面是缓存组，由nginx通过url hash后将请求分到缓存机器。

3, 这个架构方便纯squid缓存升级，能够在squid的机器上加装nginx。

4, nginx有缓存的功能，能够将一些访问量特大的连接直接缓存在nginx上，就不用通过多一次代理的请求。好比favicon.ico和网站的logo。

nginx的自动hash架构优缺点

优势

1）高性能

2）使用方便，后台是什么样关系不大

3）有很高的可用性

4）缓存架构，分流方便

5）可直接在nginx代理缓存部分连接

缺点

url分流可控性弱，增减缓存机器都会引发缓存从新分配，意味着缓存所有失效。

 

nginx的手动hash架构说明

1，这个架构图和自动hash的架构是同样的，惟一有差异的是hash算法的变化，自动hash是用nginx upstream hash模块自带的hash算法来实现分流，这个手动架构是本身设计一个算法来实现。

2，算法设计思路是从url中取一个字符来做分流依据，好比定义连接的倒数第10个字符来分流，一样能够分配得很均匀。

3，手动架构能够避免自动架构中增减机器带来的缓存失效问题，另外能够精确知道一个连接到底存在哪台缓存上。

 

nginx的手动hash架构优缺点

优势

1）基本能够继承自动架构的优势

2）避免增减机器的问题

3）精确知道连接存储在哪台缓存上

缺点

配置较复杂，要分配均匀配置不易。

 

采用Hash架构对bbs架构优化

 

1，先前讲的bbs架构采用的是lvs+squid做为前端，这样的话squidclient更新缓存时须要更新全部的squid，这个效率很低下，使用hash架构就可使squidclient每次只须要清理一台squid，效率大为提高。

2，推荐的是使用nginx手动hash架构，它能够精确知道连接会存在哪台机器上，这样就能够配置精确的备份机器。

 

3 nginx图片服务器的架构方案

图片服务一般数据容量较大，并且访问也频繁，鉴于此，图片服务就会有两种问题，一是存储问题，二是访问量问题。
存储问题就是硬盘容量问题， 花钱买硬盘就能够了，看似简单，但着实也是最苦的问题。按目前探索来看，最好的方式是：在任什么时候刻遇到硬盘空间不够时，买颗硬盘插上，最多改改配置，就能 马上利用；另外，硬盘要能充分利用，否则图片存储量大再加上备份，很恐怖，最好是每颗硬盘都用上100%的空间。
访问量也是个大问题，如 果服务不容许防盗链，那么访问量会引发带宽、服务器压力等问题，有钱的话直接扔CDN，没钱或者有更多的钱，就本身作吧。根据垣古不变的真理“越老的图， 访问量也相对较少”这一点，分红两大部分，一边处理最新的图片，一边处理老旧的图片。最新的图片访问量大，但存储量较少；老图片访问量低，但存储量大。

 

3.1 拟定一个存储目录规则

在现有的/a/b/abcde.jpg这样的hash方式下多加一个日期的目录变成：/200810/16/a/b/abcde.jpg或者/2008/10/16/a/b/abcde.jpg。按日期制定这个目录规则后，就能够按年月来拆机器了。

3.2 分机器，分硬盘

按以前的计划，分红两个组，一组服务器用lvs作负载均衡负责新图片；另外一组服务器作旧图片访问和备份。新图机器找几台好点的服务器，SCSI硬盘；旧图机 器没太大要求，PC机就行，找够硬盘就能够，如今IDE的1T硬盘也不太贵，最好再搭个raid就省事了，最主要是这些机器要多。以下图：

 

 

说明一下：
1、图片服务经过lvs做为入口，处理能力上仍是有保障的。
2、利用nginx直接对外服务，没必要用squid。
3、图中的红线是指主nginx会将/2006和/2007年的图片分别代理到两台存档服务器，若是发现主nginx的cpu占用比较大，那么能够考虑使用nginx的proxy_store将图片存到主服务器上，按期清理。
4、图中有一台存储分配服务器，做为图片服务更新图片的统一入口，有新图片或者修改图片的话，由这台服务器负责将图片放到正确的服务器上去。
5、旧图片服务器当前用年份来划分，每一年增长两台服务器，亦但是加两块硬盘，注意，不要相信raid，必定要有两台机器，地理上分在两个城市则更好。
6、由于旧数据2006和2007年的数据基本上是没有变化的，因此假如硬盘够大，那么能够把两年的数据合并在一块儿。
7、若是细心定制，那么旧图片服务器的硬盘100%塞尽是能够的，旧数据的容量基本上不会大幅增加，小小预留1-2G空间就能够了。