nginx双机负载均衡配置,nginx负载均衡搭建两台服务器，一台挂起，另一台正常开启，但是打不开网页，显示404报错

nginx双机负载均衡配置,nginx负载均衡搭建两台服务器，一台挂起，另一台正常开启，但是打不开网页，显示404报错详细介绍

本文目录一览： Nginx多台服务器实现负载均衡

Nginx负载均衡服务器： IP：192.168.0.4（Nginx-Server）
Web服务器列表：
Web1: 192.168.0.5（Nginx-Node1/Nginx-Web1）
Web2:192.168.0.7（Nginx-Node2/Nginx-Web2）

实现目的：用户访问Nginx-Server时，通过Nginx负载均衡到Web1和Web2服务器。

配置注释如下：

创建文件夹准备存放配置文件

启动负载均衡服务器192.168.0.4（Nginx-Server）

创建文件夹用于存放web页面

编辑内容如下：

启动192.168.0.5（Nginx-Node1/Nginx-Web1）

创建文件夹用于存放web页面

编辑内容如下：

启动192.168.0.7（Nginx-Node2/Nginx-Web2）

Nginx实现负载均衡

实现负载均衡可有以下算法：
Nginx实现负载均衡的原理是利用Http重定向实现负载均衡
rpm 安装方式nginx配置文件地址 /etc/nginx/conf.d 目录下面，配置文件内容结构如下：
修改完配置文件以后，还需要输入重新加载配置命令：
我们从官网上面看一下负载均衡配置案例，然后根据案例配置去对每项参数进行解释，案例如下( 注意：以下模块内容必须放在http模块下 )：
从上面这个案例Nginx会作如下执行，默认情况下，请求使用 加权循环平衡法。 在上面的示例中，每 7 个请求将按如下方式分配： 5个请求去 backend1.example.com 向第二台和第三台服务器分别发送一个请求。 如果在与服务器通信过程中发生错误，请求将 被传递到下一个服务器，依此类推，直到所有的功能 服务器将被尝试。 如果无法从任何服务器获得成功的响应， 客户端将收到与最后一个服务器通信的结果。
语法：
parameters类别：
商业版本需要付费的其他属性这里就不阐述了
1）轮训策略：
upstream模块默认的负载均衡策略是轮训策略，它会依次在服务列表进行分发
2）加权策略：
容器会根据server设置的权重进行请求分配，例如server1 weight=5 ，server2 weight=2 将会使得每 7 个请求将按如下方式分配server1 5个请求，server2两个请求。
3）Ip哈希策略：
其中请求 根据客户端 IP 地址在服务器之间分布，确保来自同一客户端的请求将始终 传递到同一服务器。使用方法是在upstream模块下面添加ip_hash;
4）最少连接数策略(least_conn)：
指定组应使用负载平衡方法，其中请求 传递给活动连接数最少的服务器， 考虑到服务器的权重。 如果有多个这样的服务器，它们会依次尝试使用 加权循环平衡法。
5）扩展策略（需要安装插件）：
还有一些其他需要付费的策略这里就不进行阐述了，比如：最少时间策略（ least_time）、随机策略等。

几种Nginx实现负载均衡的方式

nginx有5种负载均衡的策略：
1、轮询；
2、权重；
3、ip_hash；
4、fair；
5、url_hash。
以上。
Nginx中常见的几种负载均衡方式：
1、轮询（Nginx自带、默认）
该策略是Nginx默认的负载均衡策略，每一个客户端请求按时间顺序轮流分配到不同的服务器上，如果后端服务不可以用，会自动过滤掉。
upstream my_test_server {
server 192.168.0.100:8080;
server 192.168.0.101:8080;
}
2、weight 权重（Nginx自带）
weight代表权重的意思，用于指定轮询的几率，默认权重都是1.可以手动设置调整，权重越高，被分配的次数越多，weight权重和访问比例是成正比的，用于解决后端服务器性能不均衡时，调整访问比例。
upstream my_test_server {
server 192.168.0.100:8080 weight=1;
server 192.168.0.101:8080 weight=2;
server 192.168.0.102:8080 weight=3;
}
3、ip_hash（Nginx自带）
ip_hash是将每个请求按照访问ip的hash结果进行分配，这种方式可以保证同一个用户会固定访问一个后端服务器。优点：可以保证session会话，解决服务器之间session不能共享的问题。
upstream my_test_server {
ip_hash;
server 192.168.0.100:8080;
server 192.168.0.101:8080;
}
4、least_conn（Nginx自带）
将请求转发给连接数较少的后端服务器。每个后端服务器配置可能不同，处理的请求也有可能不同，对于处理的请求有快有慢，least_conn是根据后端服务器的连接情况，动态的选择连接数量较少的一台服务器来处理当前的请求。
upstream my_test_server {
least_conn;
server 192.168.0.100:8080;
server 192.168.0.101:8080;
}
5、fair（第三方）
fair是按照服务器端的响应时间来分配请求，响应时间短的服务器优先分配。第三方的负载均衡策略需要安装第三方的插件。
upstream my_test_server {
fair;
server 192.168.0.100:8080;
server 192.168.0.101:8080;
}
6、url_hash（第三方）
url_hash是根据url的hash结果进行分配请求，每一个url会固定到同一个服务器上，配合缓存使用，可以减少不必要的下载和资源时间的浪费。每次同一个url请求到达同一个服务器上，第一次加载后放入缓存，后面再次请求，直接取缓存资源。如果不采用url_hash，可能会导致请求到达不同的服务器，资源出现重新加载的情况。第三方的负载均衡策略需要安装第三方的插件。
upstream my_test_server {
hash $request_uri;
server 192.168.0.100:8080;
server 192.168.0.101:8080;
}

如何安装nginx负载均衡配置详解

负载均衡
先来简单了解一下什么是负载均衡，单从字面上的意思来理解就可以解释N台服务器平均分担负载，不会因为某台服务器负载高宕机而某台服务器闲置的情况。那么负载均衡的前提就是要有多台服务器才能实现，也就是两台以上即可。
测试环境
由于没有服务器，所以本次测试直接host指定域名，然后在VMware里安装了三台CentOS。
测试域名 ：a.com
A服务器IP ：192.168.5.149 （主）
B服务器IP ：192.168.5.27
C服务器IP ：192.168.5.126
部署思路
A服务器做为主服务器，域名直接解析到A服务器（192.168.5.149）上，由A服务器负载均衡到B服务器（192.168.5.27）与C服务器（192.168.5.126）上。
域名解析
由于不是真实环境，域名就随便使用一个a.com用作测试，所以a.com的解析只能在hosts文件设置。
打开：C:WindowsSystem32driversetchosts
在末尾添加
192.168.5.149 a.com
保存退出，然后启动命令模式ping下看看是否已设置成功
从截图上看已成功将a.com解析到192.168.5.149IP
A服务器nginx.conf设置
打开nginx.conf，文件位置在nginx安装目录的conf目录下。
在http段加入以下代码
upstream a.com {
server 192.168.5.126:80;
server 192.168.5.27:80;
}

server{
listen 80;
server_name a.com;
location / {
proxy_pass http://a.com;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
保存重启nginx
B、C服务器nginx.conf设置
打开nginx.confi，在http段加入以下代码
server{
listen 80;
server_name a.com;
index index.html;
root /data0/htdocs/www;
}
保存重启nginx
测试
当访问a.com的时候，为了区分是转向哪台服务器处理我分别在B、C服务器下写一个不同内容的index.html文件，以作区分。
打开浏览器访问a.com结果，刷新会发现所有的请求均分别被主服务器（192.168.5.149）分配到B服务器（192.168.5.27）与C服务器（192.168.5.126）上，实现了负载均衡效果。
B服务器处理页面
C服务器处理页面
假如其中一台服务器宕机会怎样？
当某台服务器宕机了，是否会影响访问呢？
我们先来看看实例，根据以上例子，假设C服务器192.168.5.126这台机子宕机了（由于无法模拟宕机，所以我就把C服务器关机）然后再来访问看看。
访问结果：
我们发现，虽然C服务器（192.168.5.126）宕机了，但不影响网站访问。这样，就不会担心在负载均衡模式下因为某台机子宕机而拖累整个站点了。
如果b.com也要设置负载均衡怎么办？
很简单，跟a.com设置一样。如下：
假设b.com的主服务器IP是192.168.5.149，负载均衡到192.168.5.150和192.168.5.151机器上
现将域名b.com解析到192.168.5.149IP上。
在主服务器(192.168.5.149)的nginx.conf加入以下代码：
upstream b.com {
server 192.168.5.150:80;
server 192.168.5.151:80;
}

server{
listen 80;
server_name b.com;
location / {
proxy_pass http://b.com;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
保存重启nginx
在192.168.5.150与192.168.5.151机器上设置nginx，打开nginx.conf在末尾添加以下代码：
server{
listen 80;
server_name b.com;
index index.html;
root /data0/htdocs/www;
}
保存重启nginx
完成以后步骤后即可实现b.com的负载均衡配置。
主服务器不能提供服务吗？
以上例子中，我们都是应用到了主服务器负载均衡到其它服务器上，那么主服务器本身能不能也加在服务器列表中，这样就不会白白浪费拿一台服务器纯当做转发功能，而是也参与到提供服务中来。
如以上案例三台服务器：
A服务器IP ：192.168.5.149 （主）
B服务器IP ：192.168.5.27
C服务器IP ：192.168.5.126
我们把域名解析到A服务器，然后由A服务器转发到B服务器与C服务器，那么A服务器只做一个转发功能，现在我们让A服务器也提供站点服务。
我们先来分析一下，如果添加主服务器到upstream中，那么可能会有以下两种情况发生：
1、主服务器转发到了其它IP上，其它IP服务器正常处理；
2、主服务器转发到了自己IP上，然后又进到主服务器分配IP那里，假如一直分配到本机，则会造成一个死循环。
怎么解决这个问题呢？因为80端口已经用来监听负载均衡的处理，那么本服务器上就不能再使用80端口来处理a.com的访问请求，得用一个新的。于是我们把主服务器的nginx.conf加入以下一段代码：
server{
listen 8080;
server_name a.com;
index index.html;
root /data0/htdocs/www;
}
重启nginx，在浏览器输入a.com:8080试试看能不能访问。结果可以正常访问
既然能正常访问，那么我们就可以把主服务器添加到upstream中，但是端口要改一下，如下代码：
upstream a.com {
server 192.168.5.126:80;
server 192.168.5.27:80;
server 127.0.0.1:8080;
}
由于这里可以添加主服务器IP192.168.5.149或者127.0.0.1均可以，都表示访问自己。
重启Nginx，然后再来访问a.com看看会不会分配到主服务器上。

关于Nginx负载均衡目录同步问题

近期外包接单，做了一个简单的系统，本以为如此简单一个Tomcat就足以满足，结果客户要求需要两台服务器负载均衡，之前负载均衡都是由专门的人负责，第一次自己实现Nginx，走了不少弯路。

由于项目组有附件上传的功能，没有专门的文件服务器，将附件都存放在了ROOT底下，负载均衡后发现经常找不到图片，明显是因为两台服务器资源不同步的问题造成的，于是开始研究服务器目录同步，使用Rsync+Sersync实现目录同步，具体步骤：

1：制定两台服务器中的一台为主服务器（安装软件rsync+sersync，但是不需要启动rsync），另一台为从服务器(安装软件rsync，需要启动rsync)

2：从服务器安装完rsync需要对/etc/rsyncd.conf 进行配置：

uid = root ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?#拥有目录权限用户

gid = root ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?#拥有目录权限的组

use chroot = no ? ? ? ? ? ? ? ? ? ? ? ? #内网使用可以不用配置

max connections = 200 ? ? ? ? ? ? ?#最大连接数 ?

timeout = 300 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? #超时时间

pid file = /var/run/rsyncd.pid ? ? ? ? ? ? ?#启动进程写入此PID文件

lock file = /var/run/rsyncd.lock ? ? ? ? ? ?#lock文件来配合最大连接数参数

log file = /var/log/rsyncd.log ? ? ? ? ? ? ? #日志文件

ignore errors = yes ? ? ? ? ? ? ? ? ? ? ? ? #忽略I/O错误

read only = false ? ? ? ? ? ? ? ? ? ? ? ? ? #允许读写 ? ? ?

list = false ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?#不列出列表

hosts allow = 192.168.1.0/24 ? ? ? ? ? ? ? ?#允许网段

hosts deny = * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?#拒绝其他网段

auth users = users ? ? ? ? ? ? ? ? ? ? ? ? ?#认证用户

secrets file = /opt/app/rsyncd/auth.pass ? ?#密码文件

[web] ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? #同步目录

path = /backup/web

设置?/opt/app/rsyncd/auth.pass文件格式为user:password

给?/opt/app/rsyncd/auth.pass添加600权限 chmod 600??/opt/app/rsyncd/auth.pass

启动rsync? rsnyc --daemon

3：主服务器部署

主服务器安装完sersync后需要配置confxml.xml，在sersync的安装目录下

? ?
<!---->

? ?
<!---->

? ?

? ? ?

? ? ?

? ? ? ?

? ? ? ?

? ? ? ?

?

? ?

?

? ? ? ? ? ?

? ? ? ?

? ? ? ?

? ?

启动sersync :/opt/soft/sersync/sersync/sersync2 -d -r -o /opt/soft/sersync/sersync/confxml.xml

location ~ .*\.(gif|jpg|jpeg|png|flv|mp3)$ { #静态

? ? ? ? ? proxy_pass http://192.168.1.12:80/;

? ? ? ? }

13《Nginx 入门教程》Nginx负载均衡(下)

这一小节中，我们将实战 Nginx 的四层和七层负载均衡功能。条件有限，使用一台公网主机，在上面搭建好 Nginx 服务。公网 IP 为 180.76.152.113。

首先会进行简单的四层负载均衡实验，不会涉及多种负载均衡算法，只使用默认的 Round-Robin算法。在后续的七层负载均衡实验中，会重点测试不同的负载均衡策略，完成相关实验。

首先在 nginx.conf 中添加如下 stream 指令块配置:

上述配置用端口3000和3001模拟两个上游服务器，然后在 upstream 指令块中指定这两个上游服务器的地址，同时给第一个设置权重为2。由于默认采用的是加权的 Round-Robin 算法，默认服务器的权重为1。设置为2，表明3次请求中，2次会转发到3000端口，一次会转发到3001端口，下面的测试也验证了这一点。

和四层的配置其实差不多，在七层中除了测试最基本的，我们还将测试前面提到的几种负载均衡策略，进一步熟悉 Nginx 中的负载均衡配置。

在 nginx.conf 中添加如下的 http 指令块:

上述配置中，我们用8000，8001和8002三个端口模拟了3个上游服务器，默认使用轮询负载均衡算法，而且三个的权重均为1。进行如下的 http 请求操作，可以看到 Nginx 转发 http 请求会均匀地分配到3个服务器上。

我们打开 ip_hash 指令的注释，这个时候默认是使用客户端的 ip 地址作为 hash 的 key，然后重启 Nginx 服务并进行如下的命令行操作：

接下来，注释 ip_hash 指令，我们打开 hash user_$arg_username 这行配置的注释， hash 指令可以让我们根据我们设置的 key 进行 hash，然后根据 hash 值选择上游的服务器。具体测试参看下面的 Linux 命令：

这里我们可以看到，在请求中带上 username 参数，Nginx 中配置的 hash 算法会根据请求中带的 username 参数作为 key 去进行 hash，然后在根据 hash 结果映射上游服务器。username 相同时，选择的上游服务器肯定是一样的，只有在 username 的值发生变化时，返回的响应才可能有变化。

今天我们完成了几个测试实验，主要是针对 Nginx 的四层和七层的负载均衡功能进行了测试。这个功能在微服务部署中会有较多的应用。因为高流量企业为保证服务的高可用性，往往会水平扩展多个相同功能的服务，部署在多台主机上，这个时候负载均衡技术就能派上用场了，而 Nginx 提供了完善的负载均衡功能以及多种负载均衡算法，能满足大部分企业的需求，如果还不够，可以通过编写内部开发模块并集成到 Nginx，实现相应的需求。所以说 Nginx 是非常值得学习和深入研究的。

使用Nginx实现负载均衡

一、负载均衡的作用

1、转发功能

按照一定的算法【权重、轮询】，将客户端请求转发到不同应用服务器上，减轻单个服务器压力，提高系统并发量。

2、故障移除

通过心跳检测的方式，判断应用服务器当前是否可以正常工作，如果服务器期宕掉，自动将请求发送到其他应用服务器。

3、恢复添加

如检测到发生故障的应用服务器恢复工作，自动将其添加到处理用户请求队伍中。

二、Nginx实现负载均衡

1、源地址哈希法：根据获取客户端的IP地址，通过哈希函数计算得到一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。

2、轮询法：将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载。

3、随机法：通过系统的随机算法，根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。

4、加权轮询法：不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重，让其处理更多的请；而配置低、负载高的机器，给其分配较低的权重，降低其系统负载，加权轮询能很好地处理这一问题，并将请求顺序且按照权重分配到后端。

5、加权随机法：与加权轮询法一样，加权随机法也根据后端机器的配置，系统的负载分配不同的权重。不同的是，它是按照权重随机请求后端服务器，而非顺序。

6、最小连接数法：由于后端服务器的配置不尽相同，对于请求的处理有快有慢，最小连接数法根据后端服务器当前的连接情况，动态地选取其中当前积压连接数最少的一台服务器来处理当前的请求，尽可能地提高后端服务的利用效率，将负责合理地分流到每一台服务器。

三、配置说明

四、轮询

五、权重

六、iphash

七、最少链接

八、fair

九、完整代码

十、也可以使用域名

nginx负载均衡搭建两台服务器，一台挂起，另一台正常开启，但是打不开网页，显示404报错

电脑网页老打不开解决方法：
1.电脑中病毒或者中木马，或电脑系统的垃圾和网页痕迹较多，可用百度卫士全面体检电脑，用百度杀毒全盘杀毒修复电脑；
2.浏览器被设置了代理服务器导致打不开网页。设置方法流程如下：可打开IE浏览器→右上角的“工具”→连接→局域网设置→勾上“自动检测设置”→确定→确定；
3.DNS设置错误，设置流程：右击桌面的“网络”→点击“属性”→点击查看活动网络下的“连接”右边的连接→“属性”→双击“Internet 协议版本 4 （TCP/IPv4）”→选择“使用下面的DNS服务器地址”→设置首选DNS服务器为114.114.114.114，备用DNS服务器8.8.8.8（也可打电话问网络运营商询问当地“DNS"地址）；
4.网卡硬件损坏或网络本身问题，建议更换网卡或者下载驱动精灵更新网卡驱动；
5.万能方法：重装系统。

利用nginx实现Redis的负载均衡，应该怎么配置？

在项目运营时，我们都会遇到一个问题，项目需要更新时，我们可能需先暂时关闭下服务器来更新。但这可能会出现一些状况:
1.用户还在操作，被强迫终止了(我们可以看日志等没人操作的时候更新，但总可能会有万一)
2.不知道的用户可能会想网站是不是被攻击了，降低了对网站的信任程度，从而导致失去部分潜在客户，这点尤其对金融互联网公司不利。
在查了一些资料后，决定采用Tomcat + Nginx + Redis来实现负载均衡和session共享。下面记录下我的实践过程，如有错误不足之处欢迎大神指点，不喜勿喷。
1.Nginx简单介绍及开启
Nginx是一款轻量级兼备高性能的Http和反向代理服务器。所谓反向代理就是指在用户发起访问请求，由代理服务器接收，然后将请求转发给正式服务器，并且将正式服务器处理完的数据返回给客户端，此时代理服务器就表现为一个服务器。这么做看起来多经过了一步，稍显麻烦，但实则是好处多多，在下面的demo中我会将其体现出来。
首先我们去Nginx官网下载个Nginx，我这是在自己电脑上，所以当然下载的是windows版本的。下载完成后直接放在某个盘中即可，不需要安装。接下去我们打开cmd，进入nginx的目录下，输入start nginx。

我们可以看到一个窗口一闪而过，这样nginx就已经被开启了，我们在任务管理器中可以找到它的进程。
现在我们在浏览器中输入localhost。可以看到出现一个页面，虽然简陋了点，但这确确实实就是nginx的欢迎页面，就类似tomcat刚启动完成的locahost:8080的欢迎页面。
2.使用Nginx实现反向代理
现在我们搭建一个基于SpringMVC ＋Spring + Mybaties框架的maven项目，搭建过程不加以赘述。功能很简单，就是能跳转到一个页面就行了，当然也可以使用别的框架。
运行demo，我这tomcat端口是8080，在浏览器输入localhost:8080，出现我们的页面。
这时我们还是直接访问tomcat服务器的，现在我想通过nginx访问tomcat，即输入localhost就能显示我们demo的页面。
这就要我们去修改nginx的核心配置文件，在其目录下的conf文件夹下的nginx.conf文件，那么首先我们就要了解该文件中一些节点的作用。
worker_processes：工作进程个数，可配置多个
worker_connections:单个进程最大连接数
server:每一个server相当于一个代理服务器
lister:监听端口，默认80
server_name:当前服务的域名，可以有多个，用空格分隔(我们是本地所以是localhost)
location：表示匹配的路径，这时配置了/表示所有请求都被匹配到这里
index：当没有指定主页时，默认会选择这个指定的文件，可多个，空格分隔
proxy_pass：请求转向自定义的服务器列表
upstream name{ }:服务器集群名称
知道了节点作用后，我们就知道我们需要修改的文件中的server部分，这是它原有的代码，我删除了它注释部分。现在我们就能明白为什么输入localhost，
它访问的是它欢迎页面即index.html。
下面我们对这段代码进行一些小小修改。就是将请求转向我们定义的服务器。

随后在cmd中输入命令nginx -s reload即可重启nginx。
重启后，我们再输入localhost，可以看到跳转到的页面是我们demo的。
至此，反向代理已完成，这样所有请求都需经过代理服务器才能访问到正式服务器，某种程度上可以保护网站安全。
3.使用Nginx实现负载均衡
负载均衡即是代理服务器将接收的请求均衡的分发到各服务器中。
负载均衡的优势在访问量少或并发小的时候可能并不明显，且不说淘宝双11、铁道部抢票这种级别的访问量、高并发，就是一般网站的抢购活动时，也会给服务器造成很大压力，可能会造成服务器崩溃。而负载均衡可以很明显的减少甚至消除这种情况的出现，下面我们说说实现方法。
首先我们再开启一个tomcat服务器，这里区分一下就叫tomcat2吧，原先的叫tomcat1。将tomcat1上的项目，拷贝到tomcat2上，稍微修改下页面上的文字以便等下区分我们的请求被分发到了哪个tomcat上。tomcat2端口我这里为8081。在浏览器中输入localhost:8081。

服务器准备好了，我们要在server外部定义个服务器集群，即用到了上文中提到的upstream 标签。服务器集群名字取为test。
同时我们需要再修改下server，将定向的路径转到问你服务器集群上。
重启下nginx，在浏览器输入localhost，再多刷新几次，可以看到两个页面在来回切换。
这样即实现了负债均衡。假设我们服务器在运行过程中，其中一个tomcat挂了，仍然还有另一个可以访问。更新的时候也能先关闭只其中一个，轮流更新。另外还能有效缓解服务器压力，是不是很棒呢?
当然，以上nginx的配置是简单化的，实际上我们还可以配置nginx对静态资源的缓存等等，在此就不多加演示了。
4.小结
花了好些时间，总算陆陆续续要写好了，在此小结一下。
nginx作为一个反向代理服务器，能缓存我们项目的静态文件，并实现反向代理与均衡负载，可以有效减少服务器压力，即使项目不大，也可以使用。
大家另外应该都还发现了个问题，虽然这样请求能分别请求到两个tomcat上，如果是一般不需身份校检的或什么认证的方法尚可，但如果出现这类情况：
我们在tomcat1上进行了登录，这时用户session当然是存在tomcat1上的，而这时进入个人中心的请求请求到tomcat2上了，这时就会出现问题了。tomcat2会告诉你还未登录，这显然不是我们想看到的。
这就涉及到session共享了，如何让两个服务器上的session共用。我这里放到下次再说，作为码农比较忙，可能要过个好几天。另外我将这次的demo源码上传了，下次还要用，nginx配置就不传了，大家自己多动手试验。