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/