Nginx图片缩略图

本nginx模块主要功能是对请求的图片进行缩略。

1.环境准备
确认已经安装了libgd2-devel,libpcre-devel,libcurl-devel模块

2.下载nginx的tar.gz文件，并通过tar -zxvf  进行解压缩

3.下载模块源代码(https://github.com/3078825/nginx-image/archive/master.zip
)，保存到nginx的源文件目录下（如/usr/local/src/nginx1.2.6）。模块的源代码文件为ngx_image_thumb-master.zip。通过 unzip ngx_image_thumb-master.zip 对模块源码进行解压缩

4.配置nginx的参数 添加图片处理模块
./configure --add-module=ngx_image_thumb-master

5.make & makeinstall 编译安装nginx

6.通过nginx.conf文件 配置图片处理模块
    location / {
            root   html;
            index  index.html index.htm;
            image on;
            image_output on;
            image_water on;
            image_water_type 0;
            image_water_file "/usr/local/nginx/html/vanke.png";
            image_water_pos 0;
            image_water_min 300 300;
            #image_water_text Vanke.com;
            #image_water_font_size 14;
        }

7.配置参数说明
image on/off 是否开启缩略图功能,默认关闭
image_backend on/off 是否开启镜像服务，当开启该功能时，请求目录不存在的图片（判断原图），将自动从镜像服务器地址下载原图
image_backend_server 镜像服务器地址
image_output on/off 是否不生成图片而直接处理后输出 默认off
image_jpeg_quality 75 生成JPEG图片的质量 默认值75
image_water on/off 是否开启水印功能
image_water_type 0/1 水印类型 0:图片水印 1:文字水印
image_water_min 300 300 图片宽度 300 高度 300 的情况才添加水印
image_water_pos 0-9 水印位置 默认值9 0为随机位置,1为顶端居左,2为顶端居中,3为顶端居右,4为中部居左,5为中部居中,6为中部居右,7为底端居左,8为底端居中,9为底端居右
image_water_file 水印文件(jpg/png/gif),绝对路径或者相对路径的水印图片
image_water_transparent 水印透明度,默认20
image_water_text 水印文字 "Power By Vampire"
image_water_font_size 水印大小 默认 5
image_water_font 文字水印字体文件路径
image_water_color 水印文字颜色,默认 #000000

8.调用说明
这里假设你的nginx 访问地址为 http://127.0.0.1/
并在nginx网站根目录存在一个 test.jpg 的图片
通过访问
http://127.0.0.1/test.jpg!c300x200.jpg 将会 生成/输出 test.jpg 300x200 的缩略图
其中 c 是生成图片缩略图的参数， 300 是生成缩略图的宽度， 200 是生成缩略图的高度
一共可以生成四种不同类型的缩略图。
支持 jpeg / png / gif (Gif生成后变成静态图片)
C 参数按请求宽高比例从图片高度 10% 处开始截取图片，然后缩放/放大到指定尺寸（ 图片缩略图大小等于请求的宽高 ）
M 参数按请求宽高比例居中截图图片，然后缩放/放大到指定尺寸（ 图片缩略图大小等于请求的宽高 ）
T 参数按请求宽高比例按比例缩放/放大到指定尺寸（ 图片缩略图大小可能小于请求的宽高 )
W 参数按请求宽高比例缩放/放大到指定尺寸，空白处填充白色背景颜色（ 图片缩略图大小等于请求的宽高

9.调用举例
http://127.0.0.1/test.jpg!c300x300.jpg

http://127.0.0.1/test.jpg!t300x300.jpg

http://127.0.0.1/test.jpg!m300x300.jpg

http://127.0.0.1/test.jpg!w300x300.jpg

http://127.0.0.1/test.c300x300.jpg

http://127.0.0.1/test.t300x300.jpg

http://127.0.0.1/test.m300x300.jpg

http://127.0.0.1/test.w300x300.jpg






1、需要image_filter模块，没有的话重新编译nginx，编译参数加上
--with-http_image_filter_module
2、配置文件1（需要使用缩略图的虚拟主机）
location ^~ /images/ {
autoindex off;
alias /path/to/image/file/;
expires 30d;
location ~ ^/images/thumb(100|150|346)/(.*)\.(jpg|png|gif)$
{
alias /path/to/image/cache/thumb$1/$2.$3;
set $image_uri /images/$2.$3?width=$1&height=$1;
set $image_filename thumb$1/$2.$3;
if (!-f $request_filename) {
proxy_pass http://127.0.0.1/$image_uri;
break;
}
proxy_store /path/to/image/cache/$image_filename;
proxy_store_access user:rw group:rw all:r;
proxy_set_header Host 127.0.0.1;
}
}
3、配置文件2（进行缩略图处理的虚拟主机）
server
{
listen 80;
listen [::]:80;
server_name 127.0.0.1;
charset utf-8;
location ~ ^/images/(.*)\.(jpg|png|gif)$
{
alias /path/to/image/file/$1.$2;
set $img_width $arg_width;
set $img_height $arg_height;
image_filter test;
image_filter resize $img_width -;
image_filter_buffer 1M;
image_filter_jpeg_quality 80;
# image_filter_sharpen 50; 0.7.45无该参数
allow 127.0.0.0/8;
deny all;
}
access_log off;
}
4、本例中限定缩小后的宽度为100、150、346之一。

Nginx + GridFS 实现的缩略图处理机制 « weberliu.com


场景

在 B2C 系统中，由于页面上大量的使用商品的缩略图，因此如何来处理和存储缩略图也就显得尤为重要了。以前在做 Ecshop 的时候出于用户服务器环境的限制，我们是在图片上传的时候来根据系统设置来生成缩略图。这样带来的问题是：用户更换模板以后有可能调整图片的大小，而导致之前生成的缩略图不可用，因此在 Ecshop 中提供了重新生成缩略图的功能。

在新的B2C系统开发之初，我们就对缩略图的生成机制进行了定义，要求是：

缩略图尺寸由模板来决定，也就是通过请求的url地址来生成相应尺寸的缩略图
动态生成缩略图并缓存缩略图，缓存不存在的时候自动重新生成
难点

动态生成缩略图有可能会使 Web 服务器需要同时处理大量的缩略图请求，而导致 CPU 负载过高。即便有CDN缓存、本地文件缓存也不能完全排除这种可能性。
URL 地址的问题，最开始我们考虑采用 图片id_width_height.jpg 这样的形式，但是这么做的风险是，如果有人大量的刷不同宽度和高度的数值就可能会造成撑爆缓存。Amazone 采用的是规则的定义来作为图片路径，这样一定程度的解决了被刷的可能性，但是对于我们来说这种方式也存在一定的问题，因为他的规则中只有大中小等几个规则的定义，并没有具体的宽度和高度，很难适应各种各样的运营经理和产品经理提出来的需求。基于这些考虑，我们最好考虑文件的路径还是采用id_width_height.jpg这种形式的命名，但是给用户看到的地址采用了 TinyURL 的方式来处理，这样既能避免恶意的刷尺寸同时也可以灵活的满足各种需求
方案 1

在最初的解决方案中，我们采用了和手机之家类似的方式来处理：当有缩略图的请求的时候，图片控制器来检查是否存在缓存，如果不存在则生成新的缩略图并写入缓存。

经过了一段时间的运行之后，我们发现这种方式处理的图片在没有CDN的前提下，系统的处理时间相对过长，页面上经常会出现图片一个个的“蹦”出来的情况，效果不是很理想。

方案 2

在一次浏览 Nginx Wiki的时候无意中发现了一个插件：GridFs。下面是关于这个插件的描述：

nginx-gridfs is an Nginx module to serve content directly from MongoDB’s GridFS.

非常的简单，就是允许Nginx直接访问 MongoDB 的 GridFS。这也就触发了我一个新的想法：如果将缩略图的缓存文件放到GridFS中，直接通过 Nginx 来访问是不是能改善现有的状况呢？

于是我做了一个简单的测试：

缓存写入Memcache，PHP 读取Memcache并返回给用户；
直接通过Nginx-GridFS插件读取GridFS中的缓存文件。
在用ab简单的压力测试之后发现效果是惊人的。使用GridFS系统的响应时间是10ms左右，而第一种方式则比第二种相差了10倍左右（具体数字记不太清楚了）。

难点

虽然直接访问 GridFS 的效率是如此的优秀，但是还面临着一个问题，在没有缓存的时候如何来触发缩略图的生成？前面已经提到过系统的要求就是要动态的生成缩略图，因此不可能采用主动缓存的方式。而通过Nginx直接访问GridFS这种方式由于跳过了PHP，我们没有办法来触发缩略图的生成。

这个问题困扰了我好几天。。。。

404

在又一遍仔细阅读Nginx配置参数的时候发现了 error_page 这个参数，他可以将一个错误信息指定到另一个URL。当GridFS中缓存文件不存在的时候 Nginx 同样也是返回一个 404 的错误，而我们可以通过 error_page 将404的错误重新定向到 PHP 处理程序，交给PHP来生成缩略图并缓存到GridFS中，这样整个的流程就完整了：

Nginx配置

要实现这一功能，首先要安装 nginx-gridfs 插件，具体的安装方法还是到官方去看吧：https://github.com/mdirolf/nginx-gridfs。这里就不多说了

其次是要修改vhost里面的server容器，将图片的请求单独进行处理，例如：

  server
  {
    listen          80;
    server_name     statics.*;
    root            /www/statics;

    location  /thumb/
    {  
      gridfs        files root_collection=thumbnail field=filename type=string;
      mongo         192.168.0.11:27017;
      error_page    404 =201 /thumb.php?f=$request_filename;
      expires       30d;
    }
    ... ...
  }
注意 error_page 这一行中的 =201，它的作用是将404的Status Code改变为201，当然您可以写成 =200，我们这里用201的目的是为了通过 HTTP Status Code来判断是否为缓存中读到的文件

转自
http://space.itpub.net/28624388/viewspace-763316
http://lubao515.info/archives/2012/01/64.html
http://zoomq.qiniudn.com/ZQScrapBook/ZqFLOSS/data/20110718145649/