语法规则

在Nginx虚拟主机中，我们配置了server中的server_name，这样我们这个虚拟主机就会对应处理该域名或IP的请求，如下：

一般我们请求后面还有跟有路径参数，如：www.kami.com/a/b/c 之类的，其实后面所接的 /a/b/c 之类的，就是由我们配置中的 Location 去进行处理，其语法规则如下：location [=|~|~*|^~]/uri/{…}

首先我们可以大致分为两大类：普通匹配和正则匹配。Nginx首先会进行普通匹配，然后才是正则匹配。其中正则匹配又分为精确匹配以及最大前缀匹配。

---

精确匹配

那么什么是精确匹配呢？就是我们的等号 = ，这里我们来以例子为例，首先我们在Nginx目录下的html中新增几个html文件用于测试。

这里我们进行添加html测试文件，内容很简单，就是在页面显示 a页面、b页面、c页面 … 字样

然后我们来设置一个location的精确匹配，我们在上次的基础下直接进行设置，如下：

这里我们简单介绍一个root的意思，就是我们下图中的location匹配中之后，就会进行其中进行执行，其路径就是 root+location路径，下图即为：html/a.html，在该路径下找到了则显示，否则为404错误。

root

另外这里我们发现location路径上必须加上详细的文件名（包括后缀，因为我们匹配中后需要root+location路径，进行查找文件的 ），这样显得过于麻烦，我们可以使用 rewrite 进行url的重定向，如下：

rewrite

另外我们 rewrite 后面并不只可以接break，还有另外一个常见的有 redirect ，这个和break有什么不同呢？就是break对于浏览器来说是不透明的，你是不会只知道其实访问的路径已经变了，浏览器中的地址不会有任何变化，而redirect对于浏览器来说是透明的，我们在浏览器中会看到路径的变化。

---

最大前缀匹配

普通匹配除了精确匹配，还有就是最大前缀匹配。可以用无前缀，即为空格 表示，这个匹配成功之后，在处理完还会去正则匹配处理

另外如果使用 ^~ ，而 url 以某个常规字符串开头，理解为匹配 url 路径即可。Nginx不对url做编码处理，因此请求为 /static/20%/a ，可以被规则 ^~ /static/ /a 匹配到（注意是空格）。而^~如果把这个前缀用于一个常规字符串,那么告诉Nginx如果路径匹配成功，那么就不进行正则匹配

那么最大前缀是什么意思呢？就是比如 www.kami.com/a.html 这个请求，即可以被 / 所匹配，也可以被 /a.html 匹配，那么就按匹配路径最长location进行处理。

下图我们访问的 /a/b/c/d ，其中我们配置的两个location都是可以匹配上的，这里它就选择了最长匹配路径的location进行处理的

注意： 这里我们特别要注意的是，我们无前缀的，即空格的 location 处理完之后，其实并没有就直接结束了，这里在处理完了之后，还会去匹配正则，如果匹配到了正则，则有正则再进行进一步处理，这个下面会进行解释。

---

正则匹配

~ 表示区分大小写，~* 表示不区分大小写

在正则匹配的location中，Nginx会找到第一个正则匹配上的location进行处理，下面的就不会进行处理了，所以正则匹配规则会受到定义的先后顺序的影响，我们在写正则匹配的location一定要注意其顺序，否则有些正则可能会一直不会被匹配。

上图中的配置，第二个正则的location就一直不会被匹配，因为总会被它前面的所匹配到，下面就不会进行执行了。

---

这里还要说一说在上述提到未演示的问题，就是普通匹配（非精确匹配）到处理完成后，还会进行正则匹配，然后再进一步处理，如下：

访问www.kami.com/a/b，首先肯定会被 /a 匹配到，应该可以显示 a.html，但是接下来他又会被正则 ~* /a 所匹配到，所以最终会显示 c.html，如果没有被正则匹配到，才会显示 a.html

另外还有 !~ 表示区分大小写不匹配，!~* 表示不区分大小写不匹配

---

最后我们在来说一下上述提到过的root，它会以root路径加上location路径去访问文件，如果找到的话就显示，否则404

其实原来还有一行的，如下，就是我们的欢迎页面，删除了也影响不大

其中的rewrite上述中我们也介绍过了，这里主要想再介绍一个alias，主要给目录取别名，使用alias路径替换掉location路径


这里使用了alias，我们就可以在访问路径前面加上一个/test，如果是使用的root，那么这样访问肯定会报404错误

---

另外还有一个 set ，主要是设值使用，如下，即我们把 a 的值设置为 8

---

反向代理

我们在虚拟机中，把Tomcat服务也启动起来，Tomcat是有许多自带的实例的，如下

这里我们就使用Nginx来代理上述这个网址，在Nginx进行如下设置：

---

负载均衡

如下图，我们可以配置两个服务器，在其中部署相同的项目，然后Nginx如下配置，我们访问www.kami.com/examples下的网页就会被负载均衡

其默认机制为轮询，配置了多台服务器，每访问一次就会切换一台服务器进行处理，每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

另外我们可以给不同的服务器指定权重，指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况，如果服务器down时暂时不参与负载，如下：

这样我们130服务器处理2个请求，131服务器处理一个请求，所有的请求会按照该比例进行分配处理。

但是按照上述轮询的方式，我们会发现一个问题，就是session的问题，这里我们就可以使用 ip_hash 来进行处理，每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

当设置了ip_hash时，其配置的weight就不生效了。