Nginx 反向代理、负载均衡、页面缓存、URL重写及读写分离具体解释[通俗易懂]

大纲

一、前言

二、环境准备

三、安装与配置Nginx

四、Nginx之反向代理

五、Nginx之负载均衡

六、Nginx之页面缓存

七、Nginx之URL重写

八、Nginx之读写分离

注。操作系统为 CentOS 6.4 x86_64 , Nginx 是版本号是最新版的1.4.2，所以实验用到的软件请点击这里下载：http://yunpan.cn/QXIgqMmVmuZrm

一、前言

       在前面的几篇博文中我们主要解说了Nginx作为Webserver知识点，基本的知识点有nginx的理论具体解释、nginx作为webserver的操作解说、nginx作为LNMP架构的解说。不清楚的博友能够回头看看。在这一篇博客中我们主要解说。 nginx的反向代理、负载均衡、缓存、URL重写以及读写分离具体解释。好了，以下我们来具体说一说。

二、环境准备

1. 操作系统

• CentOS 6.4 x86_64

2.软件版本号

• Nginx 1.4.2

3.实验拓扑

注，实验拓扑见下文。

4.安装yum源

5.各节点时间同步

6.关闭防火墙与SELinux

三、安装Nginx

1.解压

2.新建nginx用户与组

3.准备编译配置文件

4.编译并安装

5.为nginx提供SysV init脚本

6.为此脚本赋予运行权限

7.加入至服务管理列表，并让其开机自己主动启动

8.启动nginx

9.查看一下port

10.測试一下

好了，Nginx安装与配置就到这里。以下我们来说一说Nginx的反向代理。

四、Nginx之反向代理

在配置nginx反向代理之间我们得先准备两台測试server，Web1与Web2。

1.安装httpd

2.提供測试页面

3.启动httpd服务

4.測试一下

5.简单说一下。正向代理与反向代理

(1).正向代理的概念

       正向代理。也就是传说中的代理,他的工作原理就像一个跳板，简单的说。我是一个用户，我訪问不了某站点，可是我能訪问一个代理server。这个代理server呢，他能訪问那个我不能訪问的站点，于是我先连上代理server，告诉他我须要那个无法訪问站点的内容，代理server去取回来。然后返回给我。

从站点的角度，仅仅在代理server来取内容的时候有一次记录，有时候并不知道是用户的请求，也隐藏了用户的资料。这取决于代理告不告诉站点。

       结论就是。正向代理 是一个位于client和原始server(origin server)之间的server。为了从原始server取得内容，client向代理发送一个请求并指定目标(原始server)，然后代理向原始server转交请求并将获得的内容返回给client。client必需要进行一些特别的设置才干使用正向代理。

(2).反向代理的概念

继续举例:    
       例用户訪问 http://www.test.com/readme，但www.test.com上并不存在readme页面。他是偷偷从另外一台server上取回来，然后作为自己的内容返回用户，但用户并不知情。这里所提到的 www.test.com 这个域名相应的server就设置了反向代理功能。

       结论就是，反向代理正好相反，对于client而言它就像是原始server。而且client不须要进行不论什么特别的设置。

client向反向代理的命名空间(name-space)中的内容发送普通请求，接着反向代理将推断向何处(原始server)转交请求。并将获得的内容返回给client。就像这些内容原本就是它自己的一样。

(3).两者差别

从用途上来讲：

       正向代理的典型用途是为在防火墙内的局域网client提供訪问Internet的途径。正向代理还能够使用缓冲特性降低网络使用率。反向代理的典型用途是将防火墙后面的server提供给Internet用户訪问。

反向代理还能够为后端的多台server提供负载平衡。或为后端较慢的server提供缓冲服务。另外，反向代理还能够启用高级URL策略和管理技术。从而使处于不同webserver系统的web页面同一时候存在于同一个URL空间下。

从安全性来讲：

       正向代理同意client通过它訪问随意站点而且隐藏client自身，因此你必须採取安全措施以确保仅为经过授权的client提供服务。反向代理对外都是透明的，訪问者并不知道自己訪问的是一个代理。

6.nginx 代理模块

http 代理官方中文文档：http://www.howtocn.org/nginx:nginx%E6%A8%A1%E5%9D%97%E5%8F%82%E8%80%83%E6%89%8B%E5%86%8C%E4%B8%AD%E6%96%87%E7%89%88:standardhttpmodules:httpproxy

说明：代理模块的指令有非常多我这里仅仅解说重要的proxy_pass，想了解很多其它代理指令请參考官方中文文档。

这个模块能够转发请求到其它的server。

HTTP/1.0无法使用keepalive（后端server将为每一个请求创建而且删除连接）。nginx为浏览器发送HTTP/1.1并为后端server发送HTTP/1.0，这样浏览器就能够为浏览器处理keepalive。

   
例如以下例：

注意，当使用http proxy模块（甚至FastCGI），全部的连接请求在发送到后端server之前nginx将缓存它们，因此，在測量从后端传送的数据时，它的进度显示可能不对。

实验拓扑：

7.配置http反向代理

指令说明：proxy_pass

语法：proxy_pass URL
默认值：no      
使用字段：location, location中的if字段      
这个指令设置被代理server的地址和被映射的URI，地址能够使用主机名或IP加port号的形式，比如：proxy_pass http://localhost:8000/uri/;

8.又一次载入一下配置文件

9.測试一下

注，大家能够看到，当我们訪问192.168.18.208时。被代理又一次定向到Web1上。

10.查看一下Webserver日志

注，大家能够看到我们这里的客户的IP全是。nginx代理server的IP，并非真实client的IP。以下我们改动一下，让日志的IP显示真实的client的IP。

11.改动nginx配置文件

指令说明：proxy_set_header

语法：proxy_set_header header value
默认值： Host and Connection
使用字段：http, server, location
这个指令同意将发送到被代理server的请求头又一次定义或者添加一些字段。这个值能够是一个文本，变量或者它们的组合。proxy_set_header在指定的字段中未定义时会从它的上级字段继承。

12.又一次载入一下配置文件

13.測试并查看日志

注，大家能够看到日志记录的还是代理的IP。没有显示真实client的IP，为什么呢？我们来看一下httpd的配置文件。

14.查看并改动httpd配置文件

[root@web1 ~]# vim /etc/httpd/conf/httpd.conf

注，大家能够这里记录日志的參数还是%h，以下我们改动一下參数。

注，这是改动后的參数。将h%改动为%{X-Real-IP}i，好的以下我们再来測试一下。

15.重新启动并測试

注，大家能够看到如今的日志里记录的IP地址就是真实的client地址了。好了。到这里Nginx代理后端一台server就演示到这里，以下我们继续说。

五、Nginx之负载均衡

注，大家能够看到。因为我们站点是发展初期，nginx仅仅代理了后端一台server，但因为我们站点名气大涨訪问的人越来越多一台server实在是顶不住。于是我们加了多台server，那么多台server又怎么配置代理呢，我们这里以两台server为案例，为大家做演示。

1.upstream 负载均衡模块说明

案例：

以下设定负载均衡的server列表。

       upstream是Nginx的HTTP Upstream模块。这个模块通过一个简单的调度算法来实现clientIP到后端server的负载均衡。

在上面的设定中，通过upstream指令指定了一个负载均衡器的名称test.net。这个名称能够随意指定，在后面须要用到的地方直接调用就可以。

2.upstream 支持的负载均衡算法

Nginx的负载均衡模块眼下支持4种调度算法，以下进行分别介绍，当中后两项属于第三方调度算法。

 

• 轮询（默认）。每一个请求按时间顺序逐一分配到不同的后端server，假设后端某台server宕机，故障系统被自己主动剔除，使用户訪问不受影响。Weight 指定轮询权值，Weight值越大，分配到的訪问机率越高。主要用于后端每一个server性能不均的情况下。

• ip_hash。每一个请求按訪问IP的hash结果分配，这样来自同一个IP的訪客固定訪问一个后端server，有效攻克了动态网页存在的session共享问题。

• fair。这是比上面两个更加智能的负载均衡算法。

  此种算法能够根据页面大小和载入时间长短智能地进行负载均衡，也就是根据后端server的响应时间来分配请求，响应时间短的优先分配。Nginx本身是不支持fair的。假设须要使用这样的调度算法。必须下载Nginx的upstream_fair模块。

• url_hash。

  此方法按訪问url的hash结果来分配请求，使每一个url定向到同一个后端server。能够进一步提高后端缓存server的效率。

  Nginx本身是不支持url_hash的，假设须要使用这样的调度算法，必须安装Nginx 的hash软件包。

3.upstream 支持的状态參数

在HTTP Upstream模块中，能够通过server指令指定后端server的IP地址和port，同一时候还能够设定每一个后端server在负载均衡调度中的状态。经常使用的状态有：      

• down，表示当前的server临时不參与负载均衡。

• backup。预留的备份机器。当其它全部的非backup机器出现问题或者忙的时候。才会请求backup机器，因此这台机器的压力最轻。

• max_fails。同意请求失败的次数，默觉得1。当超过最大次数时。返回proxy_next_upstream 模块定义的错误。

• fail_timeout，在经历了max_fails次失败后，暂停服务的时间。max_fails能够和fail_timeout一起使用。

注，当负载调度算法为ip_hash时。后端server在负载均衡调度中的状态不能是weight和backup。

4.实验拓扑

5.配置nginx负载均衡

注，upstream是定义在server{ }之外的，不能定义在server{ }内部。定义好upstream之后，用proxy_pass引用一下就可以。

6.又一次载入一下配置文件

7.測试一下

注，大家能够不断的刷新浏览的内容，能够发现web1与web2是交替出现的。达到了负载均衡的效果。

8.查看一下Web訪问server日志

Web1:

Web2:

先改动一下，Webserver记录日志的格式。

接着，再訪问多次。继续查看日志。

注，大家能够看到，两台server日志都记录是192.168.18.138訪问的日志，也说明了负载均衡配置成功。

9.配置nginx进行健康状态检查

• max_fails，同意请求失败的次数。默觉得1。

  当超过最大次数时。返回proxy_next_upstream 模块定义的错误。

• fail_timeout，在经历了max_fails次失败后，暂停服务的时间。

  max_fails能够和fail_timeout一起使用，进行健康状态检查。

10.又一次载入一下配置文件

11.停止server并測试

注，大家能够看到。如今仅仅能訪问Web2，再又一次启动Web1，再次訪问一下。

注，大家能够看到。如今又能够又一次訪问。说明nginx的健康状态查检配置成功。但大家想一下，假设不幸的是全部服务器都不能提供服务了怎么办，用户打开页面就会出现出错页面，那么会带来用户体验的减少。所以我们能不能像配置LVS是配置sorry_server呢，答案是能够的。但这里不是配置sorry_server而是配置backup。

12.配置backupserver

13.又一次载入配置文件

14.关闭Webserver并进行測试

注。大家能够看到，当全部server都不能工作时。就会启动备份server。好了，backupserver就配置到这里，以下我们来配置ip_hash负载均衡。

15.配置ip_hash负载均衡

• ip_hash，每一个请求按訪问IP的hash结果分配。这样来自同一个IP的訪客固定訪问一个后端server，有效攻克了动态网页存在的session共享问题。（一般电子商务站点用的比較多）

注。当负载调度算法为ip_hash时，后端server在负载均衡调度中的状态不能有backup。（有人可能会问，为什么呢？大家想啊，假设负载均衡把你分配到backupserver上。你能訪问到页面吗？不能，所以了不能配置backupserver）

16.又一次载入一下server

17.測试一下

注，大家能够看到。你不断的刷新页面一直会显示的民Web2，说明ip_hash负载均衡配置成功。以下我们来统计一下Web2的訪问连接数。

18.统计Web2的訪问连接数

注。你不断的刷新。连接数会越来越多。

好了，nginx的负载均衡就所有演示到这里以下我们来说一说，页面缓存。

六、Nginx之页面缓存

1.指令说明

proxy_cache_path

语法：proxy_cache_path path [levels=number] keys_zone=zone_name:zone_size [inactive=time] [max_size=size];  
默认值：None  
使用字段：http  
指令指定缓存的路径和一些其它參数，缓存的数据存储在文件里，而且使用代理url的哈希值作为keyword与文件名称。

levels參数指定缓存的子文件夹数，比如：

文件名称类似于：

levels指定文件夹结构，能够使用随意的1位或2位数字作为文件夹结构，如 X, X:X,或X:X:X 比如: “2”, “2:2”, “1:1:2“，可是最多仅仅能是三级文件夹。  
全部活动的key和元数据存储在共享的内存池中，这个区域用keys_zone參数指定。

one指的是共享池的名称，10m指的是共享池的大小。  
注意每个定义的内存池必须是不反复的路径，比如：

假设在inactive參数指定的时间内缓存的数据没有被请求则被删除，默认inactive为10分钟。一个名为cache manager的进程控制磁盘的缓存大小，它被用来删除不活动的缓存和控制缓存大小，这些都在max_size參数中定义，当眼下缓存的值超出max_size指定的值之后，超过其大小后最少使用数据（LRU替换算法）将被删除。

内存池的大小依照缓存页面数的比例进行设置，一个页面（文件）的元数据大小依照操作系统来定，如FreeBSD/i386下为64字节。FreeBSD/amd64下为128字节。

proxy_cache

语法：proxy_cache zone_name;  
默认值：None  
使用字段：http, server, location  
设置一个缓存区域的名称。一个同样的区域能够在不同的地方使用。  
在0.7.48后，缓存遵循后端的”Expires”, “Cache-Control: no-cache”, “Cache-Control: max-age=XXX”头部字段，0.7.66版本号以后，”Cache-Control:“private”和”no-store”头相同被遵循。

nginx在缓存过程中不会处理”Vary”头。为了确保一些私有数据不被全部的用户看到。后端必须设置 “no-cache”或者”max-age=0”头，或者proxy_cache_key包括用户指定的数据如$cookie_xxx。使用cookie的值作为proxy_cache_key的一部分能够防止缓存私有数据，所以能够在不同的location中分别指定proxy_cache_key的值以便分开私有数据和公有数据。

 
缓存指令依赖代理缓冲区(buffers)，假设proxy_buffers设置为off，缓存不会生效。

proxy_cache_valid

语法：proxy_cache_valid reply_code [reply_code …] time;  
默认值：None  
使用字段：http, server, location  
为不同的应答设置不同的缓存时间，比如：

为应答代码为200和302的设置缓存时间为10分钟，404代码缓存1分钟。  
假设仅仅定义时间：

那么仅仅对代码为200, 301和302的应答进行缓存。

 
相同能够使用any參数不论什么应答。

2.定义一个简单nginx缓存server

3.新建缓存文件夹

4.又一次载入一下配置文件

5.以下我们来測试一下（谷歌浏览器）

注，大家用谷歌浏览器測试的时候，能够按F12调用开发工具，选择Network选项，我们能够看到，Response Headers。在这里我们能够看到。我们请求的是否是缓存，但如今还看不到，以下我们来配置一下。再来測试。

6. 缓存变量说明

$server_addr

server地址，在完毕一次系统调用后能够确定这个值，假设要绕开系统调用，则必须在listen中指定地址而且使用bind參数。

$upstream_cache_status

0.8.3版本号中其值可能为：

• MISS 未命中

• EXPIRED – expired。

  请求被传送到后端。

• UPDATING – expired。

  因为proxy/fastcgi_cache_use_stale正在更新，将使用旧的应答。

• STALE – expired。因为proxy/fastcgi_cache_use_stale。后端将得到过期的应答。

• HIT 命中

7.又一次载入一下配置文件

8.測试一下

注，从图中我们能够看到，我们訪问的server是192.168.18.208，缓存命中。大家能够看到是不是非常直观啊。

以下我们看一下缓存文件夹。

9.查看一下缓存文件夹

注。缓存文件夹里确实有缓存文件。好了。nginx缓存配置就到这边了，很多其它配置请依据须要看配置文档。以下我们来说一下，URL重写。

七、Nginx之URL重写

1.URL重写模块（Rewrite）

摘要

这个模块同意使用正則表達式重写URI（需PCRE库）。而且能够依据相关变量重定向和选择不同的配置。假设这个指令在server字段中指定，那么将在被请求的location确定之前运行，假设在指令运行后所选择的location中有其它的重写规则，那么它们也被运行。

假设在location中运行这个指令产生了新的URI，那么location重新确定了新的URI。这种循环能够最多运行10次，超过以后nginx将返回500错误。

指令

break

语法：break  
默认值：none  
使用字段：server, location, if  
完毕当前设置的规则，停止运行其它的重写指令。  
演示样例：

if

语法：if (condition) { … }  
默认值：none  
使用字段：server, location  
注意：在使用if指令之前请查看if is evil page而且尽量考虑用try_files取代。

 
推断一个条件，假设条件成立，则后面的大括号内的语句将运行，相关配置从上级继承。  
能够在推断语句中指定下列值：

• 一个变量的名称；不成立的值为：空字符传”“或者一些用“0”開始的字符串。

• 一个使用=或者!=运算符的比較语句。

• 使用符号~*和~模式匹配的正則表達式：

• ~为区分大写和小写的匹配。

• ~*不区分大写和小写的匹配（firefox匹配FireFox）。

• !~和!~*意为“不匹配的”。

• 使用-f和!-f检查一个文件是否存在。

• 使用-d和!-d检查一个文件夹是否存在。

• 使用-e和!-e检查一个文件，文件夹或者软链接是否存在。

• 使用-x和!-x检查一个文件是否为可运行文件。

正則表達式的一部分能够用圆括号。方便之后依照顺序用$1-$9来引用。

 
演示样例配置：

内置变量$invalid_referer用指令valid_referers指定。

return

语法：return code  
默认值：none  
使用字段：server, location, if  
这个指令结束运行配置语句并为client返回状态代码，能够使用下列的值：204，400。402-406，408。410, 411, 413, 416与500-504。此外，非标准代码444将关闭连接而且不发送不论什么的头部。

rewrite

语法：rewrite regex replacement flag  
默认值：none  
使用字段：server, location, if  
依照相关的正則表達式与字符串改动URI，指令依照在配置文件里出现的顺序运行。

 
能够在重写指令后面加入标记。  
假设替换的字符串以http://开头，请求将被重定向，而且不再运行多余的rewrite指令。

 
尾部的标记(flag)能够是下面的值：

• last – 完毕重写指令，之后搜索对应的URI或location。

• break – 完毕重写指令。

• redirect – 返回302暂时重定向。假设替换字段用http://开头则被使用。

• permanent – 返回301永久重定向。

注意假设一个重定向是相对的（没有主机名部分）。nginx将在重定向的过程中使用匹配server_name指令的“Host”头或者server_name指令指定的第一个名称。假设头不匹配或不存在。假设没有设置server_name，将使用本地主机名，假设你总是想让nginx使用“Host”头。能够在server_name使用“*”通配符（查看http核心模块中的server_name）。

比如：

可是假设我们将其放入一个名为/download/的location中。则须要将last标记改为break，否则nginx将运行10次循环并返回500错误。

假设替换字段中包括參数。那么其余的请求參数将附加到后面。为了防止附加，能够在最后一个字符后面跟一个问号：

注意：大括号（{和}）。能够同一时候用在正則表達式和配置块中，为了防止冲突，正則表達式使用大括号须要用双引號（或者单引號）。比如要重写下面的URL：

为:

则使用下面正則表達式（注意引號）：

假设指定一个“？”在重写的结尾。Nginx将丢弃请求中的參数。即变量$args。当使用$request_uri或$uri&$args时能够在rewrite结尾使用“？”以避免nginx处理两次參数串。

 
在rewrite中使用$request_uri将www.example.com重写到example.com：

相同，重写仅仅对路径进行操作，而不是參数，假设要重写一个带參数的URL，能够使用下面取代：

注意$args变量不会被编译。与location过程中的URI不同（參考http核心模块中的location）。

rewrite_log

语法：rewrite_log on | off  
默认值：rewrite_log off  
使用字段：server, location, if  
变量：无  
启用时将在error log中记录notice 标记的重写日志。

set

语法：set variable value  
默认值：none  
使用字段：server, location, if  
指令设置一个变量并为其赋值。其值能够是文本。变量和它们的组合。  
你能够使用set定义一个新的变量，可是不能使用set设置$http_xxx头部变量的值。

uninitialized_variable_warn

语法：uninitialized_variable_warn on|off  
默认值：uninitialized_variable_warn on  
使用字段：http, server, location, if  
开启或关闭在未初始化变量中记录警告日志。  
其实，rewrite指令在配置文件载入时已经编译到内部代码中，在解释器产生请求时使用。

 
这个解释器是一个简单的堆栈虚拟机。例如以下列指令：

将被编译成下面顺序：

注意并没有关于limit_rate的代码，由于它没有提及ngx_http_rewrite_module模块，“if”块能够类似”location”指令在配置文件的同样部分同一时候存在。  
假设$slow为真，相应的if块将生效，在这个配置中limit_rate的值为10k。

 
指令：

假设我们将第一个斜杠括入圆括号，则能够降低运行顺序：

之后的顺序类似例如以下：

2.简单案例

注，因为配置文件内容较多，为了让大家看着方便，我们备份一下配置文件。打开一个新的配置文件。

准备forum文件夹与測试文件

測试一下

好了，以下我们来測试一下rewrite重写。

3.又一次载入一下配置文件

4.測试一下

注，大家能够从图中看出，status code 302指的是暂时重定向。那就说明我们rewrite重写配置成功。大家知道302是暂时重定向而301是永久重定向，那么怎么实现永久重定向呢。一般server与server之间是暂时重定向。server内部是永久重定向。

以下我们来演示一下永久重定向。

5.配置永久重定向

准备forum文件夹与測试文件

6.又一次载入一下配置文件

7.測试一下

注。大家从图中能够看到，我们訪问bbs/是直接帮我们跳转到forum/下，这样的本机的跳转就是永久重定向也叫隐式重定向。好了，rewrite重定向我们就讲到这里了，想要查询很多其它关于重定向的指令请參考官方文档。最后。我们来说一下读写分离。

八、Nginx之读写分离

1.实验拓扑

       需求分析。前端一台nginx做负载均衡反向代理，后面两台httpdserver。整个架构是提供BBS(论坛)服务，有一需求得实现读写分离，就是上传附件的功能。我们上传的附件仅仅能上传到Web1，然后在Web1上利用rsync+inotify实现附件同步，大家都知道rsync+inotify仅仅能是主向从同步，不能双向同步。所以Web1可进行写操作。而Web2仅仅能进行读操作。这就带来读写分离的需求，以下我们就来说一下，读写分离怎么实现。

2.WebDAV功能说明

       WebDAV （Web-based Distributed Authoring and Versioning） 一种基于 HTTP 1.1协议的通信协议。它扩展了HTTP 1.1。在GET、POST、HEAD等几个HTTP标准方法以外加入了一些新的方法，使应用程序可直接对Web Server直接读写，并支持写文件锁定(Locking)及解锁(Unlock)，还能够支持文件的版本号控制。这样我们就能配置读写分离功能了，以下我们来详细配置一下。

3.改动配置文件

4.又一次载入一下配置文件

5.配置httpd的WebDAV功能

注，在<Directory “/var/www/html”>下启用即可。

6.又一次启动一下httpd

7.測试一下

注。web1与web2訪问都没问题。

注，我们上传文件到，web2上时，由于web2仅仅人读功能，所以没有开户WebDAV功能。所以显示是405 Method Not Allowed。

 

注，我们在Web1开启了WebDAV功能，但我们文件夹是root文件夹是不同意apache用户上传的，所以显示的是403 Forbidden。

以下我们给apache授权，同意上传。

以下我们再来測试一下，

注，大家能够看到我们成功的上传了文件。说明nginx读写分离功能配置完毕。最后。我们来查看一下上传的文件。

好了，到这里nginx的反向代理、负载均衡、页面缓存、URL重写及读写分离就所有解说完毕。

希望大家有所收获，^_^……