Web负载均衡高可用之Nginx+Keepalived

╰半夏微凉° 2022-08-09 05:22 345阅读 0赞

**说明：** 实验环境CentOS\_6.5-X86\_64，由于前端Director上的操作有重复内容，因此下面的操作选择在管理机上使用ansible以及安装脚本统一部署Director上的nginx&&keepalived，后端两台RealServer上的Nginx在此前的实验中已经安装好，直接可以提供服务，实验过程中所有机器上的iptables&selinux均得关闭。管理机上ansible的配置，nginx详细配置及其SysV init脚本可查阅以前的博文，这里不再赘述。  
[http://blog.csdn.net/celeste7777/article/details/49003873][http_blog.csdn.net_celeste7777_article_details_49003873]  
[http://blog.csdn.net/celeste7777/article/details/48678837][http_blog.csdn.net_celeste7777_article_details_48678837]  
![这里写图片描述][20151012174530383]  
![这里写图片描述][20151012174537259]  
**一、配置后端两台RealServer提供web server**  
1、在管理机上配置好realserver.sh，拷贝到RS1，RS2上并执行，绑定VIP到网络设备lo:0，并修改相关内核参数来设定ARP抵制功能

[root@DQ ~]# ansible realserver -m copy -a 'src=/root/realserver.sh dest=/root/'
    [root@DQ ~]# ansible realserver -m shell -a 'sh /root/realserver.sh start'

realserver.sh  
![这里写图片描述][20151012174703363]  
![这里写图片描述][20151012174712211]  
可以将脚本启动命令添加至系统自启文件中，防止服务器调试时重启而忘记参数设置  
![这里写图片描述][20151012174723423]  
2、测试web服务是否正常提供  
![这里写图片描述][20151012174737944]  
![这里写图片描述][20151012174751300]  
![这里写图片描述][20151012174840256]  
**二、在前端两台Director上安装nginx**  
1、准备好编译环境并安装好依赖的基础库，添加运行nginx的用户和组

[root@DQ ~]# ansible nginx -m yum -a "name=pcre-devel"
    [root@DQ ~]# ansible nginx -m yum -a "name=openssl-devel"
    [root@DQ ~]# ansible nginx -m group -a "system=yes name=nginx"
    [root@DQ ~]# ansible nginx -m user -a "system=yes group=nginx name=nginx"

![这里写图片描述][20151012174949799]  
2、在管理机上编辑安装脚本  
![这里写图片描述][20151012175008095]  
3、将安装脚本从管理机拷贝到节点机上，使用copy模块传送文件的时候报错，是ansible需要python-selinux包而节点机上没有，于是用yum模块安装  
![这里写图片描述][20151012175025283]  
4、重新拷贝安装脚本到节点机；执行成功后为nginx提供SysV init脚  
本，而后赋予此脚本执行权限，将其添加至服务管理列表，并设置开机自动启动

[root@DQ ~]# ansible nginx -m copy -a 'src=/root/installNgx.sh dest=/root/'
    [root@DQ ~]# ansible nginx -m shell -a 'sh /root/installNgx.sh' 
    [root@DQ ~]# vim nginx ##SysV init脚本可查看前一篇博文
    [root@DQ ~]# ansible nginx -m copy -a 'src=/root/nginx dest=/etc/rc.d/init.d/nginx'
    [root@DQ ~]# ansible nginx -m shell -a 'chmod +x /etc/rc.d/init.d/nginx'
    [root@DQ ~]# ansible nginx -m shell -a 'chkconfig --add nginx'
    [root@DQ ~]# ansible nginx -m shell -a 'chkconfig nginx on'

5、配置Nginx的upstream模块，实现对RealServer访问的负载均衡，详细说明可参考官方文档：  
[http://nginx.org/en/docs/http/load\_balancing.html][http_nginx.org_en_docs_http_load_balancing.html]  
[http://nginx.org/en/docs/http/ngx\_http\_upstream\_module.html][http_nginx.org_en_docs_http_ngx_http_upstream_module.html]  
在前端两台Director上编辑nginx配置文件/etc/nginx/nginx.conf，添加下图红框内容  
![这里写图片描述][20151012175127715]  
6、测试启动nginx，访问成功  
![这里写图片描述][20151012175136193]  
**三、在前端两台Director上上安装keepalived，让其分别作为Web&Nginx的HA**  
1、管理机上编辑安装脚本，而后复制脚本到Director并执行脚本进行安装  
![这里写图片描述][20151012175210290]

[root@DQ ~]# ansible nginx -m copy -a 'src=/root/installKep.sh dest=/root/'
    [root@DQ ~]# ansible nginx -m shell -a 'sh /root/installKep.sh'

2、管理机上编辑脚本将keepalived做成服务模式，方便启动和关闭，安装成功后输出命令到系统PAT路径中，提供服务启动脚本和配置文件  
![这里写图片描述][20151012175329982]

[root@DQ ~]# ansible nginx -m copy -a 'src=/root/init.sh dest=/root/'
    [root@DQ ~]# ansible nginx -m shell -a 'sh /root/init.sh'

3、安装工具方便监测服务转移情况

[root@DQ ~]# ansible nginx -m yum -a "name=ipvsadm"

4、在Director配置keepalived，先输出keepalived的man手册至man命令的查找路径，通过命令man keepalived.conf查看配置选项帮助  
![这里写图片描述][20151012175401404]  
5、编辑配置文件

[root@Node1 ~]# vim /etc/keepalived/keepalived.conf 
    ! Configuration File for keepalived
    global_defs {
       notification_email {
       admin@localhost           ##出现故障向该邮箱发送信息，这里可设为本机
       }
    
       notification_email_from keepalived@localhost     ##指定发件人
       smtp_server 127.0.0.1      ##指定smtp服务器地址
       smtp_connect_timeout 30    ##指定smtp连接超时时间
       router_id LVS_DEVEL        ##运行keepalived的一个标识
    }
    
    vrrp_instance VI_1 {     ##VIP实例相当于虚拟路由
        state MASTER         ##当前节点的起始状态，通常在master/slave的双节点模型中，其一个默认为MASTER，而别一个默认为BACKUP
        interface eth0         ## 通告信息基于该接口发送以及虚拟路由的工作物理接口
        virtual_router_id 51      ## 两台服务器必须一样
        priority 99               ##priority为当关节点在当前虚拟路由器中的优先级，MASTER的优先级应该大于SLAVE
        advert_int 1            ##检查间隔，1秒
        authentication {
            auth_type PASS     ## 认证方式为加密 
            auth_pass 1234      ## 加密的密码，两台服务器必须一样（openssl rand -hex 6生成随机字符串）
        }
        virtual_ipaddress {
            10.33.100.11/16 dev eth0 label eth0:0
        }
    virtual_server 10.33.100.11 80 {
        delay_loop 6     ##健康检查时间间隔，单位秒
        lb_algo rr       ##负载调度算法，支持的算法：rr|wrr|lc|wlc|lblc|sh|dh
        lb_kind DR       ##LVS的类型：有NAT|DR|TUN
        nat_mask 255.255.255.0
        persistence_timeout50   ##会话保持时间，单位秒（可以适当延长时间以保持session）
        protocol TCP     ##转发协议类型，有TCP和UDP两种
    
        real_server 10.33.100.15 80 {
            weight 1
            HTTP_GET {
                url {
                  path /
                  status_code 200
                }
                connect_timeout 3
                nb_get_retry 3
                delay_before_retry 3
            }
        }
        real_server 10.33.100.16 80 {
            weight 1
            HTTP_GET {
                url {
                  path /
                  status_code 200
                }
                connect_timeout 3
                nb_get_retry 3
                delay_before_retry 3
            }
        }
    }

Node2上的配置文件只需要做以下两处修改即可，注意优先级设置要做好规划，一旦检测到故障MASTER要降低优先级，要确保降低以后的优先级比BACKUP小  
![这里写图片描述][20151012175547949]  
6、编辑好配置文件后就可以启动keepalived服务测试负载均衡  
![这里写图片描述][20151012175555090]  
![这里写图片描述][20151012175603267]  
![这里写图片描述][20151012175610405]  
![这里写图片描述][20151012175617584]  
不断刷新网页测试负载均衡效果  
![这里写图片描述][20151012175637812]  
**说明：** RealServer的高可用功能实际上是由前端Director的健康状况监测功能实现的，因此当其中一个RealServer故障时，并不会引起IP地址的漂移，而用ipvsadm -L -n命令查看时会发现故障的RealServer条目已被删除；当前端Director出现故障时则会引起IP地址的漂移。  
至此Keepalived+Nginx的高可用集群已部署完毕，接下来阐述测试高可用中的3个问题  
**Q1、当所有RealServer都故障停止服务，如何给用户返回错误页面？**  
当所有RealServer都down的时候，由Director本地提供错误页面，而由于无法确定故障时刻真正工作的Director节点是哪一个，所以在前端两台Director上都要做图中红色标记的配置  
**方法1：利用niginx健康状况监测功能**  
可以通过设置upstream模块的backup参数实现错误提示页面的显示  
backup： 标记此处定义的server为备用机，当主节点不可用时备用机传递请求  
marks the server as a backup server. It will be passed requests when the primary servers are unavailable.  
![这里写图片描述][20151012175928254]  
下面首先测试Director提供的错误页面是否可以正常访问  
![这里写图片描述][20151012175935323]  
在手动停止RealServer上的web服务，测试访问  
![这里写图片描述][20151012180008312]  
**方法2：利用keepalived健康状况监测功能**  
将error\_page指向/usr/html/errro.html， 由于后端RealServer停止服务，nginx转发的请求无法得到响应，nginx会认为服务器错误，会直接返回error\_page  
![这里写图片描述][20151012180345299]  
编辑两台Director上keepalived的配置文件/etc/keepalived/keepalived.conf ，在virtual\_server中添加下图标记的一行内容  
![这里写图片描述][20151012180358668]

[root@DQ ~]# ansible nginx -m service -a 'name=keepalived state=restarted'

![这里写图片描述][20151012180406562]  
3、手动停止RS1&&RS2上的web服务，测试错误提示页面成功显示；之后再手动启动RS1&&RS2上的web服务，又可以正常访问web页面  
![这里写图片描述][20151012180452684]  
**Q2、如何自写监测脚本监测Nginx进程，完成维护模式切换，实现真正意义上的负载均衡高可用？**  
1、编辑两台Director上keepalived的配置文件/etc/keepalived/keepalived.conf ，在实例之外定义vrrp\_script，实例中定义track\_script来完成Nginx服务的监测  
![这里写图片描述][20151012180555365]  
2、编辑脚本/usr/lib/nginx\_pid.sh  
![这里写图片描述][20151012180602461]  
3、手动停止Director1上的nginx，而后重启keepalived，测试keepalived能否实现主备节点切换

[root@Node1 ~]# service nginx stop
    [root@DQ ~]# ansible nginx -m service -a 'name=keepalived state=restarted'

4、查看日志，切换成功  
![这里写图片描述][20151012180620196]  
**Q3、如何在vrrp事务（主备节点切换，节点故障）发生时，发送警告邮件给指定的管理员？**  
1、执行命令man keepalived.conf查看启用notify脚本的定义，当节点状态在主备间切换或失败时，分别执行相对应的脚本  
![这里写图片描述][20151012180645013]  
2、将配置文件中需要3个脚本实现的功能融合到一起，编写notify脚本，让其可以接受选项参数来完成通知管理员事务的功能  
**-m, –mode \{mm|mb\}：** 指定虚拟路由的模型，mm表示主主，mb表示主备；表示相对于同一种服务而言其VIP的工作类型；  
**-s, –service SERVICE,…：** 指定服务脚本名称，当状态切换时可自动启动、重启或关闭此服务；  
**-a, –address VIP：** 指定相关虚拟路由器的VIP地址；  
**-n, –notify \{master|backup|fault\}：** 指定通知的类型，即vrrp角色切换的目标角色；  
**-h, –help：** 获取脚本的使用帮助；  
![这里写图片描述][20151012180810091]  
![这里写图片描述][20151012180816895]  
![这里写图片描述][20151012180823703]  
![这里写图片描述][20151012180832242]  
![这里写图片描述][20151012180839195]  
3、编辑两台Director上keepalived的配置文件/etc/keepalivedkeepalived.conf，在实例中添加下图红色标记部分，调用notify.sh脚本：  
![这里写图片描述][20151012180928477]  
4、测试notify通知功能，在Node1上手动停止nginx服务，查看邮件  
![这里写图片描述][20151012180935032]  
在手动启动nginx，查看邮件，至此notify测试完成，可以看出keepalived是在很大程度上依赖于执行脚本来实现其扩展功能的HA服务  
![这里写图片描述][20151012180943701]

**附：Nginx配置**  
Nginx的代码是由一个核心和一系列的模块组成,核心主要用于提供WebServer的基本功能，以及Web和Mail反向代理的功能；还用于启用网络协议，创建必要的运行时环境以及确保不同的模块之间平滑地进行交互。不过，大多跟协议相关的功能和某应用特有的功能都是由nginx的模块实现的。这些功能模块大致可以分为事件模块、阶段性处理器、输出过滤器、变量处理器、协议、upstream和负载均衡几个类别，这些共同组成了nginx的http功能。事件模块主要用于提供OS独立的(不同操作系统的事件机制有所不同)事件通知机制如kqueue或epoll等。协议模块则负责实现nginx通过http、tls/ssl、smtp、pop3以及imap与对应的客户端建立会话。

Nginx的核心模块为Main和Events，此外还包括标准HTTP模块、可选HTTP模块和邮件模块，其还可以支持诸多第三方模块。Main用于配置错误日志、进程及权限等相关的参数，Events用于配置IO模型，如epoll、kqueue、select或poll等，它们是必备模块。

Nginx的主配置文件由几个段组成，这个段通常也被称为nginx的上下文，每个段的定义格式如下所示。需要注意的是，其每一个指令都必须使用分号(;)结束，否则为语法错误。

<section> {
        <directive> <parameters>;
    }

**配置main模块**

下面说明main模块中的几个关键参数。

*  error\_log：用于配置错误日志，可用于main、http、server及location上下文中；

语法格式为：

如果在编译nginx时使用了–with-debug选项，还可以使用如下格式打开调试功能。

要禁用错误日志，不能使用“error\_log off;”，而要使用类似如下选项：

error_log /dev/null crit;

*  timer\_resolution：用于降低gettimeofday()系统调用的次数。默认情况下，每次从kevent()、epoll、/dev/poll、select()或poll()返回时都会执行此系统调用。

语法格式为：

timer_resolution interval
    例如：timer_resolution  100ms;

*  worker\_cpu\_affinity：通过sched\_setaffinity()将worker绑定至CPU上，只能用于main上下文。

语法格式为：

worker_cpu_affinity cpumask ...
    例如：
    worker_processes     4;
    worker_cpu_affinity 0001 0010 0100 1000;

*  worker\_priority：为worker进程设定优先级(指定nice值)，此参数只能用于main上下文中，默认为0；

语法格式为：

worker_priority number

*  worker\_processes：worker进程是单线程进程。如果Nginx用于CPU密集型的场景中，如SSL或gzip，且主机上的CPU个数至少有2个，那么应该将此参数值设定为与CPU核心数相同；如果Nginx用于大量静态文件访问的场景中，且所有文件的总大小大于可用内存时，应该将此参数的值设定得足够大以充分利用磁盘带宽。此参数与Events上下文中的work\_connections变量一起决定了maxclient的值：
 *  maxclients = work\_processes \* work\_connections
 *  worker\_rlimit\_nofile：设定worker进程所能够打开的文件描述符个数的最大值。

语法格式：

worker_rlimit_nofile number

**配置Events模块**

*  worker\_connections：设定每个worker所处理的最大连接数，它与来自main上下文的worker\_processes一起决定了maxclients的值。
 *  max clients = worker\_processes \* worker\_connections

而在反向代理场景中，其计算方法与上述公式不同，因为默认情况下浏览器将打开2个连接，而nginx会为每一个连接打开2个文件描述符，因此，其maxclients的计算方法为：

*  max clients = worker\_processes \* worker\_connections/4
 *  use：在有着多于一个的事件模型IO的应用场景中，可以使用此指令设定nginx所使用的IO机制，默认为./configure脚本选定的各机制中最适用当前OS的版本。

语法格式：

一个配置示例

user nginx;
    # the load is CPU-bound and we have 16 cores
    worker_processes 16;
    error_log /var/log/nginx/error.log;
    pid /var/run/nginx.pid;
    
    events {
        use epoll;
        worker_connections 2048;
    }

**HTTP服务的相关配置**

http上下文专用于配置用于http的各模块，此类指令非常的多，每个模块都有其专用指定，具体请参数nginx官方wiki关于模块部分的说明。大体上来讲，这些模块所提供的配置指令还可以分为如下几个类别。

*  客户端类指令

如client\_body\_buffer\_size、client\_header\_buffer\_size、client\_header\_timeout和keepalive\_timeout等；

*  文件IO类指令

如aio、directio、open\_file\_cache、open\_file\_cache\_min\_uses、open\_file\_cache\_valid和sendfile等；

*  hash类指令

用于定义Nginx为某特定的变量分配多大的内存空间，如types\_hash\_bucket\_size、server\_names\_hash\_bucket\_size和variables\_hash\_bucket\_size等；

*  套接字类指令

用于定义Nginx如何处理tcp套接字相关的功能，如tcp\_nodelay(用于keepalive功能启用时)和tcp\_nopush(用于sendfile启用时)等；

**虚拟服务器相关配置**

server {
        <directive> <parameters>;
    }

用于定义虚拟服务器相关的属性，常见的指令有backlog、rcvbuf、bind及sndbuf等。

**location相关的配置**

location \[modifier\] uri \{…\} 或 location @name \{…\}

通常用于server上下文中，用于设定某URI的访问属性。location可以嵌套。

The prefix “@” specifies a named location. Such locations are not used during normal processing of requests, they are intended only to process internally redirected requests (see error\_page, try\_files). 如下面关于memcached的相关配置

server {
      location / {
        set $memcached_key $uri;
        memcached_pass     name:11211;
        default_type       text/html;
        error_page         404 @fallback;
      }
    
      location @fallback {
        proxy_pass http://backend;
      }
    }

**Nginx反向代理**

Nginx通过proxy模块实现反向代理功能。在作为web反向代理服务器时，nginx负责接收客户请求，并能够根据URI、客户端参数或其它的处理逻辑将用户请求调度至上游服务器上(upstream server)。nginx在实现反向代理功能时的最重要指令为proxy\_pass，它能够将location定义的某URI代理至指定的上游服务器(组)上。如下面的示例中，location的/uri将被替换为上游服务器上的/newuri。

location /uri {
            proxy_pass http://www.magedu.com:8080/newuri;
        }

不过，这种处理机制中有两个例外。一个是如果location的URI是通过模式匹配定义的，其URI将直接被传递至上游服务器，而不能为其指定转换的另一个URI。例如下面示例中的/forum将被代理为[http://www.magedu.com/forum][http_www.magedu.com_forum]。

location ~ ^/bbs {
            proxy_pass http://www.magedu.com;
        }

第二个例外是，如果在loation中使用的URL重定向，那么nginx将使用重定向后的URI处理请求，而不再考虑上游服务器上定义的URI。如下面所示的例子中，传送给上游服务器的URI为/index.php?page=，而不是/index。

location / {
            rewrite /(.*)$ /index.php?page=$1 break;
            proxy_pass http://localhost:8080/index;
        }

**proxy模块的指令**

proxy模块的可用配置指令非常多，它们分别用于定义proxy模块工作时的诸多属性，如连接超时时长、代理时使用http协议版本等。下面对常用的指令做一个简单说明。

**proxy\_connect\_timeout：** nginx将一个请求发送至upstream server之前等待的最大时长；  
**proxy\_cookie\_domain：**将upstream server通过Set-Cookie首部设定的domain属性修改为指定的值，其值可以为一个字符串、正则表达式的模式或一个引用的变量；  
**proxy\_cookie\_path：** 将upstream server通过Set-Cookie首部设定的path属性修改为指定的值，其值可以为一个字符串、正则表达式的模式或一个引用的变量；  
**proxy\_hide\_header：**设定发送给客户端的报文中需要隐藏的首部；  
**proxy\_pass：**指定将请求代理至upstream server的URL路径；  
**proxy\_set\_header：**将发送至upsream server的报文的某首部进行重写；  
**proxy\_redirect：**重写location并刷新从upstream server收到的报文的首部；  
**proxy\_send\_timeout：**在连接断开之前两次发送至upstream server的写操作的最大间隔时长；  
**proxy\_read\_timeout：**在连接断开之前两次从接收upstream server接收读操作的最大间隔时长；

如下面的一个示例：

proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        client_max_body_size 10m;
        client_body_buffer_size 128k;
        proxy_connect_timeout 30;
        proxy_send_timeout 15;
        proxy_read_timeout 15;

**upstream模块**

与proxy模块结合使用的模块中，最常用的当属upstream模块。upstream模块可定义一个新的上下文，它包含了一组宝岛upstream服务器，这些服务器可能被赋予了不同的权重、不同的类型甚至可以基于维护等原因被标记为down。

upstream模块常用的指令有：  
**ip\_hash：**基于客户端IP地址完成请求的分发，它可以保证来自于同一个客户端的请求始终被转发至同一个upstream服务器；  
**keepalive：**每个worker进程为发送到upstream服务器的连接所缓存的个数；  
**least\_conn：**最少连接调度算法；  
**server：**定义一个upstream服务器的地址，还可包括一系列可选参数，如：

*  weight：权重；
 *  fail\_timeout：等待请求的目标服务器发送响应的时长；
 *  down：手动标记其不再处理任何请求；
 *  backup：用于fallback的目的，所有服务均故障时才启动此服务器；
 *  max\_fails：最大失败连接次数，失败连接的超时时长由fail\_timeout指定；

例如：

upstream backend {
          server www.magedu.com weight=5;
          server www2.magedu.com:8080       max_fails=3  fail_timeout=30s;
        }

upstream模块的负载均衡算法主要有三种，轮调(round-robin)、ip哈希(ip\_hash)和最少连接(least\_conn)三种。

此外，upstream模块也能为非http类的应用实现负载均衡，如下面的示例定义了nginx为memcached服务实现负载均衡之目的。

upstream memcachesrvs {
        server 172.16.100.6:11211;
        server 172.16.100.7:11211;
    }
    
    server {
        location / {
        set $memcached_key "$uri?$args";
        memcached_pass memcachesrvs;
        error_page 404 = @fallback;
        }
    
        location @fallback {
             proxy_pass http://127.0.0.1:8080;
        }
    }

**if判断语句**

在location中使用if语句可以实现条件判断，其通常有一个return语句，且一般与有着last或break标记的rewrite规则一同使用。但其也可以按需要使用在多种场景下，需要注意的是，不当的使用可能会导致不可预料的后果。

location / {
        if ($request_method == “PUT”) {
            proxy_pass http://upload.magedu.com:8080;
        } 
    
        if ($request_uri ~ "\.(jpg|gif|jpeg|png)$") {
            proxy_pass http://imageservers;
            break;
        }
    }
    
    upstream imageservers {
        server 172.16.100.8:80 weight 2;
        server 172.16.100.9:80 weight 3;
    }

**if语句中的判断条件**

正则表达式匹配：  
**~：**与指定正则表达式模式匹配时返回“真”，判断匹配与否时区分字符大小写；  
**~\*：**与指定正则表达式模式匹配时返回“真”，判断匹配与否时不区分字符大小写；  
**!~：**与指定正则表达式模式不匹配时返回“真”，判断匹配与否时区分字符大小写；  
**!~\*：**与指定正则表达式模式不匹配时返回“真”，判断匹配与否时不区分字符大小写；

文件及目录匹配判断：  
**-f, !-f：**判断指定的路径是否为存在且为文件；  
**-d, !-d：**判断指定的路径是否为存在且为目录；  
**-e, !-e：**判断指定的路径是否存在，文件或目录均可；  
**-x, !-x：**判断指定路径的文件是否存在且可执行；

**nginx常用的全局变量**

下面是nginx常用的全局变量中的一部分，它们经常用于if语句中实现条件判断。

$args 
    $content_length
    $content_type 
    $document_root 
    $document_uri 
    $host 
    $http_user_agent 
    $http_cookie 
    $limit_rate 
    $request_body_file 
    $request_method 
    $remote_addr 
    $remote_port 
    $remote_user 
    $request_filename 
    $request_uri 
    $query_string 
    $scheme
    $server_protocol 
    $server_addr 
    $server_name 
    $server_port 
    $uri

**反向代理性能优化**

在反向代理场景中，nginx有一系列指令可用于定义其工作特性，如缓冲区大小等，给这些指令设定一个合理的值，可以有效提升其性能。

**缓冲区设定**

nginx在默认情况下在将其响应给客户端之前会尽可能地接收来upstream服务器的响应报文，它会将这些响应报文存暂存于本地并尽量一次性地响应给客户端。然而，在来自于客户端的请求或来自upsteam服务器的响应过多时，nginx会试图将之存储于本地磁盘中，这将大大降低nginx的性能。因此，在有着更多可用内存的场景中，应该将用于暂存这些报文的缓冲区调大至一个合理的值。

*  proxy\_buffer\_size size：  
    定用于暂存来自于upsteam服务器的第一个响应报文的缓冲区大小；
 *  proxy\_buffering on|off：  
    启用缓冲upstream服务器的响应报文，否则，如果proxy\_max\_temp\_file\_size指令的值为0，来自upstream服务器的响应报文在接收到的那一刻将同步发送至客户端；一般情况下，启用proxy\_buffering并将proxy\_max\_temp\_file\_size设定为0能够启用缓存响应报文的功能，并能够避免将其缓存至磁盘中；
 *  proxy\_buffers 8 4k|8k：  
    用于缓冲来自upstream服务器的响应报文的缓冲区大小；

**缓存**

nginx做为反向代理时，能够将来自upstream的响应缓存至本地，并在后续的客户端请求同样内容时直接从本地构造响应报文。

*  proxy\_cache zone|off：

定义一个用于缓存的共享内存区域，其可被多个地方调用；缓存将遵从upstream服务器的响应报文首部中关于缓存的设定，如 “Expires”、”Cache-Control: no-cache”、 “Cache-Control: max-age=XXX”、”private”和”no-store” 等，但nginx在缓存时不会考虑响应报文的”Vary”首部。为了确保私有信息不被缓存，所有关于用户的私有信息可以upstream上通过”no-cache” or “max-age=0”来实现，也可在nginx设定proxy\_cache\_key必须包含用户特有数据如$cookie\_xxx的方式实现，但最后这种方式在公共缓存上使用可能会有风险。因此，在响应报文中含有以下首部或指定标志的报文将不会被缓存。

Set-Cookie
        Cache-Control containing "no-cache", "no-store", "private", or a "max-age" with a non-numeric or 0 value
        Expires with a time in the past
        X-Accel-Expires: 0

*  proxy\_cache\_key：

设定在存储及检索缓存时用于“键”的字符串，可以使用变量为其值，但使用不当时有可能会为同一个内容缓存多次；另外，将用户私有信息用于键可以避免将用户的私有信息返回给其它用户；

*  proxy\_cache\_lock：

启用此项，可在缓存未命令中阻止多个相同的请求同时发往upstream，其生效范围为worker级别；

*  proxy\_cache\_lock\_timeout：proxy\_cache\_lock功能的锁定时长；
 *  proxy\_cache\_min\_uses：某响应报文被缓存之前至少应该被请求的次数；
 *  proxy\_cache\_path：

定义一个用记保存缓存响应报文的目录，及一个保存缓存对象的键及响应元数据的共享内存区域(keys\_zone=name:size)，其可选参数有：  
**levels：**每级子目录名称的长度，有效值为1或2，每级之间使用冒号分隔，最多为3级；  
**inactive：**非活动缓存项从缓存中剔除之前的最大缓存时长；  
**max\_size：**缓存空间大小的上限，当需要缓存的对象超出此空间限定时，缓存管理器将基于LRU算法对其进行清理；  
**loader\_files：**缓存加载器(cache\_loader)的每次工作过程最多为多少个文件加载元数据；  
**loader\_sleep：**缓存加载器的每次迭代工作之后的睡眠时长；  
**loader\_threashold：**缓存加载器的最大睡眠时长；  
例如：

proxy_cache_path  /data/nginx/cache/one levels=1 keys_zone=one:10m;
        proxy_cache_path  /data/nginx/cache/two levels=2:2 keys_zone=two:100m;
        proxy_cache_path  /data/nginx/cache/three levels=1:1:2 keys_zone=three:1000m;

*  proxy\_cache\_use\_stale：

在无法联系到upstream服务器时的哪种情形下(如error、timeout或http\_500等)让nginx使用本地缓存的过期的缓存对象直接响应客户端请求；其格式为：

用于为不同的响应设定不同时长的有效缓存时长，例如：proxy\_cache\_valid 200 302 10m;

*  proxy\_cache\_methods \[GET HEAD POST\]：

为哪些请求方法启用缓存功能；

*  proxy\_cache\_bypass string：

设定在哪种情形下，nginx将不从缓存中取数据；例如：

proxy_cache_bypass $cookie_nocache $arg_nocache $arg_comment;
    proxy_cache_bypass $http_pragma $http_authorization;

**使用示例**

http {
        proxy_cache_path  /data/nginx/cache  levels=1:2    keys_zone=STATIC:10m
                                             inactive=24h  max_size=1g;
        server {
            location / {
                proxy_pass             http://www.magedu.com;
                proxy_set_header       Host $host;
                proxy_cache            STATIC;
                proxy_cache_valid      200  1d;
                proxy_cache_valid      301 302 10m;
                proxy_cache_vaild      any 1m;
                proxy_cache_use_stale  error timeout invalid_header updating
                                       http_500 http_502 http_503 http_504;
            }
        }
    }

**压缩**

nginx将响应报文发送至客户端之前可以启用压缩功能，这能够有效地节约带宽，并提高响应至客户端的速度。通常编译nginx默认会附带gzip压缩的功能，因此，可以直接启用之。

http {
        gzip on;
        gzip_http_version 1.0;
        gzip_comp_level 2;
        gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript application/json;
        gzip_disable msie6;
    }

gzip\_proxied指令可以定义对客户端请求哪类对象启用压缩功能，如“expired”表示对由于使用了expire首部定义而无法缓存的对象启用压缩功能，其它可接受的值还有“no-cache”、“no-store”、“private”、“no\_last\_modified”、  
“no\_etag”和“auth”等，而“off”则表示关闭压缩功能。

**配置示例**  
**反向代理**

server {
            listen       80;
            server_name  www.magedu.com;
            add_header X-Via $server_addr;  
    
            location / {
                root   html;
                index  index.html index.htm;
                if ($request_method ~* "PUT") {
                    proxy_pass http://172.16.100.12;
                    break;
                }
            }
    
            location /bbs {
                proxy_pass http://172.16.100.11/;
            }
    }

此例中，对[http://www.magedu.com/bbs/][http_www.magedu.com_bbs]的请求将被转发至[http://172.16.100.11/][http_172.16.100.11]这个URL，切记最后的/不应该省去；而/匹配的URL中请求方法为“PUT”时，将被转发至[http://172.16.100.12/][http_172.16.100.12]这个URL。

另外，add\_header用于让nginx在响应给用户的报文中构造自定义首部，其使用格式为“add\_header NAME VALUE”。

可以使用curl命令对配置好的服务进行请求，以验正其效果。如：

# curl -I http://www.magedu.com/bbs/
    HTTP/1.1 200 OK
    Server: nginx/1.4.1
    Date: Tue, 14 May 2013 10:19:10 GMT
    Content-Type: text/html; charset=UTF-8
    Content-Length: 15
    Connection: keep-alive
    Last-Modified: Tue, 30 Apr 2013 09:34:09 GMT
    ETag: "186e9f-f-b4076640"
    X-Via: 172.16.100.107
    Accept-Ranges: bytes

在后端服务器172.16.100.12上装载dav模块，并开放其dav功能，而后验正文件上传效果。开放dav功能的方法如下：

首先启用如下两个模块：

LoadModule dav_module modules/mod_dav.so
    LoadModule dav_fs_module modules/mod_dav_fs.so

而后配置相应主机的目录如下所示，关键是其中的dav一行。

<Directory "/var/www/html">
        dav on
        Options Indexes FollowSymLinks
        Order allow,deny
        Allow from all
    </Directory>

接着尝试访问代理服务器：

# curl -I -T /etc/inittab http://www.magedu.com/

**启用缓存**  
http \{  
include mime.types;  
default\_type application/octet-stream;  
sendfile on;  
keepalive\_timeout 65;

proxy_cache_path /nginx/cache/first  levels=1:2   keys_zone=first:10m max_size=512m;
    
    server {
        listen       80;
        server_name  www.magedu.com;
    
        location / {
            root   html;
            index  index.html index.htm;
            if ($request_method ~* "PUT") {
                proxy_pass http://172.16.100.12;
                break;
            }
        }
    
        location /bbs {
            proxy_pass http://172.16.100.11/;
            proxy_cache first;
            proxy_cache_valid 200 1d;
            proxy_cache_valid 301 302 10m;
            proxy_cache_valid any 1m;
        }
    }

**使用upstream**  
不启用缓存

http {
        include       mime.types;
        default_type  application/octet-stream;
        sendfile        on;
        keepalive_timeout  65;
    
        upstream websrv {
            server 172.16.100.11 weight=1;
            server 172.16.100.12 weight=1;
            server 127.0.0.1:8080 backup;
        }
        server {
            listen       80;
            server_name  www.magedu.com;
    
            add_header X-Via $server_addr;
    
            location / {
                proxy_pass http://websrv;
                index  index.html index.htm;
    
                if ($request_method ~* "PUT") {
                    proxy_pass http://172.16.100.12;
                    break;
                }
            }
            error_page   500 502 503 504  /50x.html;
            location = /50x.html {
                root   html;
            }
        }
    
        server {
            listen 8080;
            server_name localhost;
            root /nginx/htdocs;
            index index.html;
        }
    }

测试效果：默认情况下，nginx对定义了权重的upstream服务器使用加权轮调的方法调度访问，因此，其多次访问应该由不同的服务器进行响应。如下所示。

# curl http://172.16.100.107/
    RS2.magedu.com
    
    # curl http://172.16.100.107/
    RS1.magedu.com

根据上面的配置，如果172.16.100.11和172.16.100.12两个upstream服务器均宕机时，将由本地监听在8080端口的虚拟主机进行响应。

# curl http://172.16.100.107/
    Sorry...

**为upstream启用缓存**

http {
        include       mime.types;
        default_type  application/octet-stream;
        sendfile        on;
        keepalive_timeout  65;
    
        proxy_cache_path /nginx/cache/first  levels=1:2   keys_zone=first:10m max_size=512m;
    
        upstream websrv {
            server 172.16.100.11 weight=1;
            server 172.16.100.12 weight=1;
            server 127.0.0.1:8080 backup;
        }
        server {
            listen       80;
            server_name  www.magedu.com;
    
            add_header X-Via $server_addr;
            add_header X-Cache-Status $upstream_cache_status;
    
            location / {
                proxy_pass http://websrv;
                proxy_cache first;
                proxy_cache_valid 200 1d;
                proxy_cache_valid 301 302 10m;
                proxy_cache_valid any 1m;
                index  index.html index.htm;
    
                if ($request_method ~* "PUT") {
                    proxy_pass http://172.16.100.12;
                    break;
                }
            }
            error_page   500 502 503 504  /50x.html;
            location = /50x.html {
                root   html;
            }
        }
    
        server {
            listen 8080;
            server_name localhost;
            root /nginx/htdocs;
            index index.html;
        }
    }

第一次访问某可缓存资源时，在本地缓存中尚未有其对应的缓存对象，因此，其一定为未命中状态。而第二次请求时，则可以直接从本地缓存构建响应报文。

# curl -I http://www.magedu.com/
    HTTP/1.1 200 OK
    Server: nginx/1.4.1
    Date: Tue, 14 May 2013 10:53:07 GMT
    Content-Type: text/html; charset=UTF-8
    Content-Length: 15
    Connection: keep-alive
    Last-Modified: Tue, 30 Apr 2013 09:34:09 GMT
    ETag: "186e9f-f-b4076640"
    Accept-Ranges: bytes
    X-Via: 172.16.100.107
    X-Cache-Status: MISS
    
    # curl -I http://www.magedu.com/
    HTTP/1.1 200 OK
    Server: nginx/1.4.1
    Date: Tue, 14 May 2013 10:53:09 GMT
    Content-Type: text/html; charset=UTF-8
    Content-Length: 15
    Connection: keep-alive
    Last-Modified: Tue, 30 Apr 2013 09:34:09 GMT
    ETag: "186e9f-f-b4076640"
    X-Via: 172.16.100.107
    X-Cache-Status: HIT
    Accept-Ranges: bytes

[http_blog.csdn.net_celeste7777_article_details_49003873]: http://blog.csdn.net/celeste7777/article/details/49003873
[http_blog.csdn.net_celeste7777_article_details_48678837]: http://blog.csdn.net/celeste7777/article/details/48678837
[20151012174530383]: /images/20220731/520df0a7c5364b01b10b7b4cae1ad9b8.png
[20151012174537259]: /images/20220731/a13cf069a0cb463e8cde63aef50f76a9.png
[20151012174703363]: /images/20220731/f96d798b2a9c487a952f11819a97238e.png
[20151012174712211]: /images/20220731/65e25710fc554facb9e3f4a676f966ee.png
[20151012174723423]: /images/20220731/e79d6b3e80bc4786b10bd0b7c9c5229d.png
[20151012174737944]: /images/20220731/d15d70bd74db4797aeabae2dbb837c91.png
[20151012174751300]: /images/20220731/78b702c5b75542a0befd89d73c629285.png
[20151012174840256]: /images/20220731/f6d327e6f4014ebd89a42f79142a8668.png
[20151012174949799]: /images/20220731/519932c4f4a1463a8eb1a92d6f6e2f8b.png
[20151012175008095]: /images/20220731/210c9bb798d04be5a12cce327cb525c0.png
[20151012175025283]: /images/20220731/70c05b0134084958ab797c97c680259f.png
[http_nginx.org_en_docs_http_load_balancing.html]: http://nginx.org/en/docs/http/load_balancing.html
[http_nginx.org_en_docs_http_ngx_http_upstream_module.html]: http://nginx.org/en/docs/http/ngx_http_upstream_module.html
[20151012175127715]: /images/20220731/cf819d7464ff41f1a83b6af9ae36b250.png
[20151012175136193]: /images/20220731/15bc0986691144bfb17514b7fdd6e113.png
[20151012175210290]: /images/20220731/a08907e79d4a4c0b9a4fe1d3a4bc72e8.png
[20151012175329982]: /images/20220731/936d9489861f40cf83787a412ae224dd.png
[20151012175401404]: /images/20220731/e73a189b8d904260bbe3e1467449a948.png
[20151012175547949]: /images/20220731/22409f3ed9604d93959d4d812f86dd6a.png
[20151012175555090]: /images/20220731/142412d9c3f440f39e4b099ad682c4fb.png
[20151012175603267]: /images/20220731/ad6fd6405f6643b8bf4d4450b59efbbf.png
[20151012175610405]: /images/20220731/f8e88783e2c5465faad0dc1c9be9b8c3.png
[20151012175617584]: /images/20220731/4690ba444b6c4623a59987787b325656.png
[20151012175637812]: /images/20220731/29d21eef1d1c433692ef0662390d302b.png
[20151012175928254]: /images/20220731/559236861e8b45dea474e1fef099a0ac.png
[20151012175935323]: /images/20220731/1604cfc92c26456b8e988f176447e5ad.png
[20151012180008312]: /images/20220731/c2b4453b0f5741abb63966af55378080.png
[20151012180345299]: /images/20220731/30cc85f73e3d439099f395b6a08bd86e.png
[20151012180358668]: /images/20220731/134cb373520d4741aa38d5957b8f2923.png
[20151012180406562]: /images/20220731/80cae1b7c6234fc3a93714bf382585f3.png
[20151012180452684]: /images/20220731/52245525f9e44bd19127a48c87a91bd4.png
[20151012180555365]: /images/20220731/6c6a0d9cf9c9480f9ee17cb312e57311.png
[20151012180602461]: /images/20220731/fe2618b11bf148f8ac92e1750b2b2d7b.png
[20151012180620196]: /images/20220731/e4396238370247e3abff1e946bddb8b6.png
[20151012180645013]: /images/20220731/7fdb1148a6f145d29a5c5dc2cf45602e.png
[20151012180810091]: /images/20220731/ae8f463a245b4a6c9b2f28a6fc808c54.png
[20151012180816895]: /images/20220731/dddf5d1fce574c3882de678229c23090.png
[20151012180823703]: /images/20220731/9303a17ba7694da5a93743c3bc1e7275.png
[20151012180832242]: /images/20220731/a2944ae34c544fc39048226dd0642be5.png
[20151012180839195]: /images/20220731/3f2de26d9d584282ae11959d02e11f84.png
[20151012180928477]: /images/20220731/2bdb9f593b7e4873852bf19e732fa006.png
[20151012180935032]: /images/20220731/e2682ce372e24d18b2f91aaa810f0f2d.png
[20151012180943701]: /images/20220731/8e0b86ff98fe4a8b9ebff59519a54e35.png
[http_www.magedu.com_forum]: http://www.magedu.com/forum
[http_www.magedu.com_bbs]: http://www.magedu.com/bbs/
[http_172.16.100.11]: http://172.16.100.11/
[http_172.16.100.12]: http://172.16.100.12/