Nginx流程图：
下面来解释一波详细过程，
当客户端发送一个请求时，这个请求首先会进入 server里面，这个就相当于main方法，是一个入口，请求的地址寻去找对应server里的 server_name 和端口号, server_name 是一个url地址，nginx会根据这个url找到对应的location，再通过location里配置的 proxy_pass找到对应的upsteam，upsteam再通过各种负载均衡算法，将请求分配至相应的web app。(location里也可以不配置proxy_pass,直接指向web app。) 如果没有upsteam，则会找到相应的静态虚拟站点，通过location里的root的路径。
规则： http模块可包含多个server，server可包含多个location，一个location对应一个upsteam，location里也可以不配置proxy_pass,直接指向web app。Proxy_pass 可以指向一个upsteam或者一个具体的url，例如：http://www.baidu.com;
upsteam 负载均衡算法
1、默认算法(轮询、轮询+权重),weight 就是权重参数， 不添加这个属性，则8080 和8081轮询处理请求，加了以后会按照权重进行处理，也就是8080每处理2次，8081就处理1次。如下图配置
upsteam demo{
server 127.0.0.1:8080 weight 2;
server 127.0.0.1:8081 weight 1;
}2、ip_hash算法，基于Hsah算法，可用于保持session跨域一致，但是，通过ip_hash算法后，同一ip地址，通过ip地址取模，都会指向一个tomcat，不同的ip地址取模后值是不一样的，所以会指向不同的tomcat，算法实现： Has(client%2)=index 得到一个index索引，取模定位是第几个服务器，从0开始。但是有一个弊端，一个ip只能访问这个据群众这一个服务器了，如果这个服务器挂掉了，那么绑定这个服务器的ip就都不能访问了，所以nginx负载均衡做的很好但是session就很弱，而且一般生产不会使用nginx那中ip绑定的。太浪费资源。(顺便记录下可以保持session一致的方案
二、使用redis缓存，保存在redis里，进行session管理，
三、Tomcat做会话同步
会话同步只适合小客户量的配置。如果访问用户特别多的话就不行了。一个用户访问一台服务器就要将一个session复制给其他的服务器。如果访问量特别多复制的就特别多。来回同步session会影响服务器的效率，同时也会占用服务器的内存。最终可能 会导致服务器宕机。
)，代码如下,只需添加一行代码即可：
upsteam demo{
ip_hash;
server 127.0.0.1:8080 weight 2;
server 127.0.0.1:8081 weight 1;
}3、fair 算法，就近原则，比以上两种智能的算法，此种算法可以依据页面大小和加载时间长短进行智能的负载均衡，也就是根据后端服务器响应时间长短精确的请求分配，也就是相应时间短的优先分配。Nginx本身是不支持fail的，如果需要使用这种调度算法，必须要下载Nginx的upsteam_fai，
暂无代码，后续补充4、url_has算法，静态文件缓存，非官方的，必须下载第三方，模块儿Nginx的hash软件包，Hash(url) node_count= index 存放图片，根据图片的后缀地址来取模，确定存放在哪一个服务器上，极大的节约了存储空 间。
upsteam参数
upstream {
server 反向服务地址，加 端口，
weight 权重比，
max_fails =2 失败多少次，认为主机已经挂掉，则踢出，默认为2
fail_timeout 踢出后重新探测时间，健康检查
backup 备用服务器，其他服务器全部挂掉了这个才启用，也不会为其他 服务器做备份
max_conns 允许最大连接（Nginx连接到tomcat的最大连接数，默认是1W）
slow_start 当节点恢复，不立即加入。
}