[转]Nginx负载均衡原理初解

什么是负载均衡

 

咱们知道单台服务器的性能是有上限的，当流量很大时，就须要使用多台服务器来共同提供服务，这就是所谓的集群。

负载均衡服务器，就是用来把通过它的流量，按照某种方法，分配到集群中的各台服务器上。这样一来不只能够承担

更大的流量、下降服务的延迟，还能够避免单点故障形成服务不可用。通常的反向代理服务器，都具有负载均衡的功能。

负载均衡功能能够由硬件来提供，好比之前的F5设备。也能够由软件来提供，LVS能够提供四层的负载均衡(利用IP和端口)，

Haproxy和Nginx能够提供七层的负载均衡(利用应用层信息)。

 

来看一个最简单的Nginx负载均衡配置。

http {
    upstream cluster {
        server srv1;
        server srv2;
        server srv3;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://cluster;
        }
    }
}

经过上述配置，Nginx会做为HTTP反向代理，把访问本机的HTTP请求，均分到后端集群的3台服务器上。

此时使用的HTTP反向代理模块是ngx_http_proxy_module。

通常在upstream配置块中要指明使用的负载均衡算法，好比hash、ip_hash、least_conn。

这里没有指定，因此使用了默认的HTTP负载均衡算法 - 加权轮询。

 

负载均衡流程图

 

在描述负载均衡模块的具体实现前，先来看下它的大体流程：

 

 

负载均衡模块 

 

Nginx目前提供的负载均衡模块：

ngx_http_upstream_round_robin，加权轮询，可均分请求，是默认的HTTP负载均衡算法，集成在框架中。

ngx_http_upstream_ip_hash_module，IP哈希，可保持会话。

ngx_http_upstream_least_conn_module，最少链接数，可均分链接。

ngx_http_upstream_hash_module，一致性哈希，可减小缓存数据的失效。

 

以上负载均衡模块的实现，基本上都遵循一套类似的流程。

 

1. 指令的解析函数

好比least_conn、ip_hash、hash指令的解析函数。

这些函数在解析配置文件时调用，主要用于：

检查指令参数的合法性

指定peer.init_upstream函数指针的值，此函数用于初始化upstream块。

 

2. 初始化upstream块

在执行完指令的解析函数后，紧接着会调用全部HTTP模块的init main conf函数。

在执行ngx_http_upstream_module的init main conf函数时，会调用全部upstream块的初始化函数，

即在第一步中指定的peer.init_upstream，主要用于：

建立和初始化后端集群，保存该upstream块的数据

指定peer.init，此函数用于初始化请求的负载均衡数据

 

来看下ngx_http_upstream_module。

ngx_http_module_t ngx_http_upstream_module_ctx = {
    ...
    ngx_http_upstream_init_main_conf, /* init main configuration */
    ...
};

static char *ngx_http_upstream_init_main_conf(ngx_conf_t *cf, void *conf)
{
    ...
    /* 数组的元素类型是ngx_http_upstream_srv_conf_t */
    for (i = 0; i < umcf->upstreams.nelts; i++) {
        /* 若是没有指定upstream块的初始化函数，默认使用round robin的 */
        init = uscfp[i]->peer.init_upstream ? uscfp[i]->peer.init_upstream :
                        ngx_http_upstream_init_round_robin;

        if (init(cf, uscfp[i] != NGX_OK) {
            return NGX_CONF_ERROR;
        }
    }
    ...
}

 

3. 初始化请求的负载均衡数据块

当收到一个请求后，通常使用的反向代理模块（upstream模块）为ngx_http_proxy_module，

其NGX_HTTP_CONTENT_PHASE阶段的处理函数为ngx_http_proxy_handler，在初始化upstream机制的

函数ngx_http_upstream_init_request中，调用在第二步中指定的peer.init，主要用于：

建立和初始化该请求的负载均衡数据块

指定r->upstream->peer.get，用于从集群中选取一台后端服务器（这是咱们最为关心的）

指定r->upstream->peer.free，当不用该后端时，进行数据的更新（无论成功或失败都调用）

 

请求的负载均衡数据块中，通常会有一个成员指向对应upstream块的数据，除此以外还会有本身独有的成员。

"The peer initialization function is called once per request. 
It sets up a data structure that the module will use as it tries to find an appropriate
backend server to service that request; this structure is persistent across backend re-tries,
so it's a convenient place to keep track of the number of connection failures, or a computed
hash value. By convention, this struct is called ngx_http_upstream_<module_name>_peer_data_t."

 

4. 选取一台后端服务器

通常upstream块中会有多台后端，那么对于本次请求，要选定哪一台后端呢？

这时候第三步中r->upstream->peer.get指向的函数就派上用场了：

采用特定的算法，好比加权轮询或一致性哈希，从集群中选出一台后端，处理本次请求。 

选定后端的地址保存在pc->sockaddr，pc为主动链接。

函数的返回值：

NGX_DONE：选定一个后端，和该后端的链接已经创建。以后会直接发送请求。

NGX_OK：选定一个后端，和该后端的链接还没有创建。以后会和后端创建链接。

NGX_BUSY：全部的后端（包括备份集群）都不可用。以后会给客户端发送502（Bad Gateway）。

 

5. 释放一台后端服务器

当再也不使用一台后端时，须要进行收尾处理，好比统计失败的次数。

这时候会调用第三步中r->upstream->peer.free指向的函数。

函数参数state的取值：

0，请求被成功处理

NGX_PEER_FAILED，链接失败

NGX_PEER_NEXT，链接失败，或者链接成功但后端未能成功处理请求

 

一个请求容许尝试的后端数为pc->tries，在第三步中指定。当state为后两个值时：

若是pc->tries不为0，须要从新选取一个后端，继续尝试，此后会重复调用r->upstream->peer.get。

若是pc->tries为0，便再也不尝试，给客户端返回502错误码（Bad Gateway）。

 

在upstream模块的回调

 

负载均衡模块的功能是从后端集群中选取一台后端服务器，而具体的反向代理功能是由upstream模块实现的，

好比和后端服务器创建链接、向后端服务器发送请求、处理后端服务器的响应等。

咱们来看下负载均衡模块提供的几个钩子函数，是在upstream模块的什么地方回调的。

 

Nginx的HTTP反向代理模块为ngx_http_proxy_module，其NGX_HTTP_CONTENT_PHASE阶段的处理函数为

ngx_http_proxy_handler，每一个请求的upstream机制是从这里开始的。

ngx_http_proxy_handler
    ngx_http_upstream_create /* 建立请求的upstream实例 */
    ngx_http_upstream_init /* 启动upstream机制 */
        ngx_htp_upstream_init_request /* 负载均衡模块的入口 */

            uscf->peer.init(r, uscf) /* 第三步，初始化请求的负载均衡数据块 */
            ...

            ngx_http_upstream_connect /* 可能会被ngx_http_upstream_next重复调用 */

                ngx_event_connect_peer(&u->peer); /* 链接后端 */
                    pc->get(pc, pc->data); /* 第四步，从集群中选取一台后端 */
                ...

                /* 和后端建连成功后 */
                c = u->peer.connection;
                c->data = r;
                c->write->handler = ngx_http_upstream_handler; /* 注册的链接的读事件处理函数 */
                c->read->handler = ngx_http_upstream_handler; /* 注册的链接的写事件处理函数 */
                u->write_event_handler = ngx_http_upstream_send_request_handler; /* 写事件的真正处理函数 */
                u->read_event_handler = ngx_http_upstream_process_header; /* 读事件的真正处理函数 */

选定后端以后，在和后端通讯的过程当中若是发生了错误，会调用ngx_http_upstream_next来继续尝试其它的后端。

ngx_http_upstream_next
    if (u->peer.sockaddr) {
          if (ft_type == NGX_HTTP_UPSTREAM_FT_HTTP_403 ||
               ft_type == NGX_HTTP_UPSTREAM_FT_HTTP_404)
               state = NGX_PEER_NEXT;
          else
               state = NGX_PEER_FAILED;

          /* 第五步，释放后端服务器 */
          u->peer.free(&u->peer, u->peer.data, state);
          u->peer.sockaddr = NULL;
     }

 

Reference

 

[1]. http://www.evanmiller.org/nginx-modules-guide.html#proxying

[2]. http://tengine.taobao.org/book/chapter_05.html#id5

 

---------------------

下载nginx源码包，编译nginx须要指定pcre，zlib，openssl，到官网上下载源代码包：
http://www.zlib.NET/
http://www.openssl.org/
http://www.pcre.org/

将这三个包下载放到/opt目录，tar -xzvf *.gz解压，而后也将nginx-0.6.32的包解压到/opt目录下，进入nginx目录，执行：
#./configure --sbin-path=/usr/local/sbin --with-http_ssl_module --with-pcre=../pcre-7.7 --with-zlib=../zlib-1.2.3 --with-openssl=../openssl-0.9.8g
#make && make install

若是在./configure时出如今错误，多是没有安装gcc g+编译器的缘故。单独安装这两个编译器比较麻烦，ubuntu提供了build-essential来安装gcc和g++编译器

apt-get install build-essential

 

采用aptitude安装的时候，系统会将全部依赖的包都一并装上，可是使 用源码编译的时候就没这么智能了，咱们须要找到须要的依赖包，而后手工安装，幸运的是，这并不复杂，也很少，例如pcre, ssl 和zlib，安装方法比较简单：

sudo aptitude install libpcre3 libpcre3-dev libpcrecpp0 libssl-dev zlib1g-dev

3、安装Nginx

ok，准备工做作完了，是时候开始下载、 安装Nginx了。

一、下载源代码

       到Nignx官网去下载源代码

二、 解压

tar -zxvf nginx-0.6.31.tar.gz
...
cd nginx-0.6.31/

三、选择须要的编译选项
Nginx的编译选项仍是很多 的，基本上都是定制位置和模块，分别是：
1）--sbin-path=/usr/local/sbin
从源码编译Nginx会安装在/usr/local/nginx目录下（你可使用参数--prefix=<path>指定本身须要的位置），而后会将bin文件放在/usr/local/nginx/sbin/nginx，虽然比较清晰，可是和咱们通常的习惯不一样

（做为程序员的咱们更习惯在/usr/local /sbin下寻找bin文件）；

2）--with-http_ssl_module
主要是提供https访问支持的。

五、 Compile

./configure --sbin-path=/usr/local/sbin --with-http_ssl_module

编 译的时间不会很长，完成的时候你会在屏幕上看到相似下面的信息：

...
nginx path prefix: "/usr/local/nginx"
nginx binary file: "/usr/local/sbin"
nginx configuration file: "/usr/local/nginx/conf/nginx.conf"
...

留 意上面的提示，涉及到nginx的几个重要文件的路径信息。

六、Make && make install
差很少快完成了，如今make一下。

make

sudo make install

在使用make install 命令时可能会提示当前执行的命令权限不够，sudo su命令而后输入密码提高下权限就ok

七、chmod（可选）
还须要给bin文件有执行权限，也比较简单：

chmod +x /usr/local/sbin/nginx

 

八、Nginx重要文件安装目录

默认nginx安装的目录在/usr/local/nginx下，包括：
/usr/local/nginx/sbin #nginx启动文件
/usr/local/nginx/conf ＃配置文件
/usr/local/nginx/html ＃默认网页文件
/usr/local/nginx/logs ＃日志文件

4、使用

安装完成后，试着使用下。
一、启动

sudo /usr/local/sbin/nginx

而后把本身的浏览器导航到http://IP就可 以看到默认的欢迎界面了

 

Welcome to nginx!

 

If you see this page, the nginx web server is successfully installed andworking. Further configuration is required.

For online documentation and support please refer tonginx.org.
Commercial support is available atnginx.com.

Thank you for using nginx.

 

二、中止

 

   sudo /usr/local/sbin/nginx -s stop

 

 

6、附录：Compile-time options

（原文参考：http://wiki.codemongers.com/NginxInstallOptions ）

configure 脚本肯定系统所具备一些特性，特别是 nginx 用来处理链接的方法。而后，它建立 Makefile 文件。

configure 支持下面的选项：

1）目录属性

--prefix=<path> - Nginx安装路径。若是没有指定，默认为 /usr/local/nginx。

--sbin-path=<path> - Nginx可执行文件安装路径。只能安装时指定，若是没有指定，默认为<prefix>/sbin/nginx。

--conf-path=<path> - 在没有给定-c选项下默认的nginx.conf的路径。若是没有指定，默认为<prefix>/conf/nginx.conf。

--pid-path=<path> - 在nginx.conf中没有指定pid指令的状况下，默认的nginx.pid的路径。若是没有指定，默认为 <prefix>/logs/nginx.pid。

--lock-path=<path> - nginx.lock文件的路径，默认为<prefix>/logs/nginx.lock

--error-log-path=<path> - 在nginx.conf中没有指定error_log指令的状况下，默认的错误日志的路径。若是没有指定，默认为 <prefix>/logs/error.log。

--http-log-path=<path> - 在nginx.conf中没有指定access_log指令的状况下，默认的访问日志的路径。若是没有指定，默认为 <prefix>/logs/access.log。

--user=<user> - 在nginx.conf中没有指定user指令的状况下，默认的nginx使用的用户。若是没有指定，默认为 nobody。

--group=<group> - 在nginx.conf中没有指定user指令的状况下，默认的nginx使用的组。若是没有指定，默认为 nobody。

--builddir=DIR - 指定编译的目录

 

2）模块

--with-rtsig_module - 启用 rtsig 模块

--with-select_module --without-select_module -容许或不容许开启SELECT模式，若是 configure 没有找到更合适的模式，好比：kqueue(sun os),epoll (Linux kenel 2.6+), rtsig(实时信号)或者/dev/poll(一种相似select的模式，底层实现与SELECT基本相 同，都是采用轮训方法) SELECT模式将是默认安装模式

--with-poll_module --without-poll_module - Whether or not to enable the poll module. This module is enabled by default if a more suitable method such as kqueue, epoll, rtsig or /dev/poll is not discovered by configure.

--with-http_ssl_module -开启HTTP SSL模块，使NGINX能够支持HTTPS请求。这个模块须要已经安装了OPENSSL，在DEBIAN上是libssl

--with-http_realip_module - 启用 ngx_http_realip_module

--with-http_addition_module - 启用 ngx_http_addition_module

--with-http_sub_module - 启用 ngx_http_sub_module

--with-http_dav_module - 启用 ngx_http_dav_module

--with-http_flv_module - 启用 ngx_http_flv_module

--with-http_stub_status_module - 启用 "server status" 页

--without-http_charset_module - 禁用 ngx_http_charset_module

--without-http_gzip_module - 禁用 ngx_http_gzip_module. 若是启用，须要 zlib 。

--without-http_ssi_module - 禁用 ngx_http_ssi_module

--without-http_userid_module - 禁用 ngx_http_userid_module

--without-http_access_module - 禁用 ngx_http_access_module

--without-http_auth_basic_module - 禁用 ngx_http_auth_basic_module

--without-http_autoindex_module - 禁用 ngx_http_autoindex_module

--without-http_geo_module - 禁用 ngx_http_geo_module

--without-http_map_module - 禁用 ngx_http_map_module

--without-http_referer_module - 禁用 ngx_http_referer_module

--without-http_rewrite_module - 禁用 ngx_http_rewrite_module. 若是启用须要 PCRE 。

--without-http_proxy_module - 禁用 ngx_http_proxy_module

--without-http_fastcgi_module - 禁用 ngx_http_fastcgi_module

--without-http_memcached_module - 禁用 ngx_http_memcached_module

--without-http_limit_zone_module - 禁用 ngx_http_limit_zone_module

--without-http_empty_gif_module - 禁用 ngx_http_empty_gif_module

--without-http_browser_module - 禁用 ngx_http_browser_module

--without-http_upstream_ip_hash_module - 禁用 ngx_http_upstream_ip_hash_module

--with-http_perl_module - 启用 ngx_http_perl_module

--with-perl_modules_path=PATH - 指定 perl 模块的路径

--with-perl=PATH - 指定 perl 执行文件的路径

--http-log-path=PATH - Set path to the http access log

--http-client-body-temp-path=PATH - Set path to the http client request body temporary files

--http-proxy-temp-path=PATH - Set path to the http proxy temporary files

--http-fastcgi-temp-path=PATH - Set path to the http fastcgi temporary files

--without-http - 禁用 HTTP server

--with-mail - 启用 IMAP4/POP3/SMTP 代理模块

--with-mail_ssl_module - 启用 ngx_mail_ssl_module

--with-cc=PATH - 指定 C 编译器的路径

--with-cpp=PATH - 指定 C 预处理器的路径

--with-cc-opt=OPTIONS - Additional parameters which will be added to the variable CFLAGS. With the use of the system library PCRE in FreeBSD, it is necessary to indicate --with-cc-opt="-I /usr/local/include". If we are using select() and it is necessary to increase the number of file descriptors, then this also can be assigned here: --with-cc-opt="-D FD_SETSIZE=2048".

--with-ld-opt=OPTIONS - Additional parameters passed to the linker. With the use of the system library PCRE in FreeBSD, it is necessary to indicate --with-ld-opt="-L /usr/local/lib".

--with-cpu-opt=CPU - 为特定的 CPU 编译，有效的值包括：pentium, pentiumpro, pentium3, pentium4, athlon, opteron, amd64, sparc32, sparc64, ppc64

--without-pcre - 禁止 PCRE 库的使用。同时也会禁止 HTTP rewrite 模块。在 "location" 配置指令中的正则表达式也须要 PCRE 。

--with-pcre=DIR - 指定 PCRE 库的源代码的路径。

--with-pcre-opt=OPTIONS - Set additional options for PCRE building.

--with-md5=DIR - Set path to md5 library sources.

--with-md5-opt=OPTIONS - Set additional options for md5 building.

--with-md5-asm - Use md5 assembler sources.

--with-sha1=DIR - Set path to sha1 library sources.

--with-sha1-opt=OPTIONS - Set additional options for sha1 building.

--with-sha1-asm - Use sha1 assembler sources.

--with-zlib=DIR - Set path to zlib library sources.

--with-zlib-opt=OPTIONS - Set additional options for zlib building.

--with-zlib-asm=CPU - Use zlib assembler sources optimized for specified CPU, valid values are: pentium, pentiumpro

--with-openssl=DIR - Set path to OpenSSL library sources

--with-openssl-opt=OPTIONS - Set additional options for OpenSSL building

--with-debug - 启用调试日志

--add-module=PATH - Add in a third-party module found in directory PAT

---------------------

【转】nginx proxy_cache 缓存配置

 

 

 

前言：

因为本人工做缘由，涉及到网络直播领域，其中视频的回放下载，涉及到了一些视频下载方面的技术。针对于一个完整视频的下载，目前市面上的主流作法是，先将整个视频流切片，存储到文件服务器中，在用户须要观看回放视频时。经过一个视频回源服务器，去文件服务器中逐个请求切片，返回给用户播放。

今天着重探讨的是关于回源服务器缓存的配置以及合理的缓存策略。

经过给回源服务器配置缓存的案例，详细讲解一整套缓存配置机制，而且可沿用到其余任何缓存配置场景中。

 

今天的讲解分为四点：

• 回源服务器的工做是啥
• 为啥须要给回源服务器加缓存
• 如何配置缓存
• 如何针对业务场景配置完备的缓存机制

 

回源服务器的工做：

回源服务器在下面叙述中简称：源站

如图所示，在文件下载的过程当中，横跨在cdn与文件服务器之间，做为下载枢纽。

 

源站架构：源站是nginx+PHP的webserver架构，如图所示：

 

但若是源站只是简单的收到请求，而后下载资源，再返回，势必会存在如下几点不够优化的问题：

一、cdn可能存在屡次回源现象

二、源站对同一资源的屡次下载，存在网络流量带宽浪费，以及没必要要的耗时。

因此为了优化这些问题，须要给源站作一层缓存。缓存策略采用nginx自带的proxy_cache模块。

 

proxy_cache原理：

proxy_cache模块的工做原理如图所示：

 

如何配置proxy_cache模块

在nginx.conf文件中添加以下代码：

http{
    ......
    proxy_cache_path/data/nginx/tmp-test levels=1:2 keys_zone=tmp-test:100m inactive=7d max_size=1000g;
}

代码说明：

proxy_cache_path 缓存文件路径

levels 设置缓存文件目录层次；levels=1:2 表示两级目录

keys_zone 设置缓存名字和共享内存大小

inactive 在指定时间内没人访问则被删除

max_size 最大缓存空间，若是缓存空间满，默认覆盖掉缓存时间最长的资源。

 

当配置好以后，重启nginx，若是不报错，则配置的proxy_cache会生效

 

查看  proxy_cache_path /data/nginx/目录，

会发现生成了tmp-test文件夹。

 

如何使用proxy_cache

在你对应的nginx vhost server配置文件中添加以下代码:

location /tmp-test/ {
  proxy_cache tmp-test;
  proxy_cache_valid  200 206 304 301 302 10d;
  proxy_cache_key $uri;
  proxy_set_header Host $host:$server_port;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_passhttp://127.0.0.1:8081/media_store.php/tmp-test/;
}

配置项介绍：

Proxy_cache tmp-test 使用名为tmp-test的对应缓存配置

proxy_cache_valid  200 206 304 301 302 10d; 对httpcode为200…的缓存10天

proxy_cache_key $uri  定义缓存惟一key,经过惟一key来进行hash存取

proxy_set_header  自定义http header头，用于发送给后端真实服务器。

proxy_pass  指代理后转发的路径，注意是否须要最后的/

 

到这里，最基本的proxy_cache功能就配置成功了。当uri成功匹配到该location,则proxy_cache就会生效。

 

添加proxy_cache以后，请求过程的变化:

一、第一次访问：

 

第一次访问，proxy_cache并无找到对应的缓存文件（未命中缓存MISS），因此当第一次请求完成的同时，proxy_cache会保持缓存：

二、保存缓存，如图所示：

三、同一个url第二次访问，当同一个文件再次到达源站，proxy_cache就会找到其对应的缓存文件（命中缓存HIT）直接返回给请求端，无需再执行php程序，如图所示：

 

提出疑问：

到此，就完成了最基本的proxy_cache配置和访问过程介绍，可是最基本的配置，每每没法知足咱们的业务需求，咱们每每会提出如下几点疑问和需求：

1. 须要主动清理缓存文件
2. 写入路径为一块磁盘，若是磁盘打满该怎么解决？
3. 如何让源站支持断点续传，以及断点续传的缓存策略
4. 若是请求端 range 请求（分片下载）一个大资源，一样的uri，如何区别请求？
5. 还须要告诉请求端，资源的过时时间
6. 日志统计，如何配置命中与不命中字段，如何作统计？

面对以上疑问，咱们一个一个解决。

 

问题一：主动清理缓存

采用：nginx  proxy_cache_purge 模块 ，该模块与proxy_cache成对出现，功能正好相反。

设计方法：在nginx中，另启一个server，当须要清理响应资源的缓存时，在本机访问这个server。

例如:

访问 127.0.0.1:8083/tmp-test/TL39ef7ea6d8e8d48e87a30c43b8f75e30.txt 便可清理该资源的缓存文件。

配置方法：

location /tmp-test/ {
                allow 127.0.0.1; //只容许本机访问
                deny all; //禁止其余全部ip
                proxy_cache_purge tmp-test $uri;  //清理缓存
        }

proxy_cache_purge：缓存清理模块

tmp-test：指定的key_zone

$uri：指定的生成key的参数

proxy_cache_purge缓存清理过程，如图所示：

问题二：缓存文件强磁盘打满该怎么办？

因为写入路径为一个单一目录，只能写入一块磁盘。一块磁盘很快就会被打满，解决该问题有以下两种方法：

一、将多块磁盘作磁盘阵列？ 缺点是：减少了实际的存储空间。

二、巧妙得运用proxy_cache_path的目录结构，因为levels=1:2，这致使缓存文件的目录结构为两层，每层目录名，都是由hash函数生成。如图所示：

总共含有16*16*16=4096个文件目录。对该一级目录进行软链接，分别将0-f软链接到你所须要的指定磁盘目录上，如图所示：

经过软链的方法，实现：将不一样盘下的目录做为真正存放数据的路径，解决了多盘利用，单盘被打满的问题。

 

问题三：支持range（断点续传）

添加上缓存代理以后，客户端发起的range请求将会失效，以下图所示：

致使range参数没法传递到下一级的缘由以下：

当缓存代理转发http请求到后端服务器时，http header会改变，header中的部分参数，会被取消掉。其中range参数被取消，致使，后端nginx服务器没有收到range参数，最终致使这个分片下载不成功。因此须要对代理转发的header进行配置。

例如：

location /tmp-test/ {
                proxy_cache tmp-test;
                proxy_cache_valid  200 206 304 301 302 10d;
                proxy_cache_key $uri;
                <span style="color:#ff0000;">proxy_set_header Range $http_range;</span>
                proxy_pass http://127.0.0.1:8081/media_store.php/tmp-test/;
}

红色部分的含义：将http请求中的range值（$http_range）放到代理转发的http请求头中做为参数range的值。

 

问题四，当支持range加载后，proxy_cache_key，则须要从新配置：

若是请求端 Range请求（分片下载）一个大资源，一样的uri，proxy cache如何识别资源对应的key。

因为nginx配置为：proxy_cache_key $uri，用uri做为key

因此当请求为普通请求和range请求时，都是一样的uri做为key。proxy_cache将有可能致使错误返回。以下图所示：

解决方法以下：

修改proxy_cache_key ，配置proxy_cache_key $http_range$uri;

这样就能解决：key惟一性。能够避免无论是正常请求仍是不一样的range请求，第一次获取的内容和以后获取的缓存内容都不会出现异常。

问题五：如何配置-返回过时时间

须要经过返回过时时间来指定请求端，哪些资源须要缓存，哪些资源不缓存，

 

 

参数	正常请求	range请求
返回过时时间	返回	不返回

为了防止请求端将分片资源当作完整资源缓存起来，咱们须要对正常请求，返回过时时间；对range请求， 不返回过时时间。

解决该问题，经过对nginx配置便可解决：

location /media_store.php {
     fastcgi_pass   127.0.0.1:9000;
     fastcgi_index  media_store.php;
     fastcgi_param  SCRIPT_FILENAME  $document_root/$fastcgi_script_name;
     include        fastcgi_params;
     if ( $http_range = ''){
          expires 2592000s;
     }
}

在proxy_pass代理以后的location中加入对$http_range的判断，expires 表示过时时间。 2592000s指缓存过时时间。

 

问题七：缓存命中状况如何在http头中体现，以及在nginx日志中查看

解决方法：

利用nginx $upstream_cache_status变量:该变量表明缓存命中的状态，

若是命中，为HIT；若是未命中，为MISS

在返回nginx server配置中添加：

add_header  Nginx-Cache "$upstream_cache_status";

在nginxlog中添加：

log_format       combinedio  …$upstream_cache_status;

http返回head截图：

nginx log日志截图：

 

总结：

整个一套完备的缓存策略就介绍到此，这套方案中不只实现了基本的缓存配置，还解决了实际场景应用中会遇到的，磁盘扩展，缓存清理，断点续传，缓存过时时间，缓存命中提示等问题，只要将这套方案灵活运用，无论是再复杂的场景，基本都能知足需求。以上都是我在工做中爬过的坑，不断完善总结出的结果，但愿对读者能有帮助。