nginx负载均衡、负载均衡策略/方式（轮询、权重、ip_hash）session共享问题

1.1负载均衡结构

1.1.1负载均衡概念

负载均衡是当有高并发(100万请求)请求访问服务器时,nginx作为入口服务器,先接受请求,然后经过 负载均衡的逻辑,将100万请求,"平均"分配到不同集群节点(负载均衡)。

1.1.2结构图

请求集中访问到nginx,nginx通过计算负载均衡的逻辑,实现后端均衡发送请求.

2.1负载均衡方式/策略

2.1.1轮询

依次按照顺序访问后端的每一个服务器,按照这个计算,相当于平均分配请求给所有集群节点--物理均衡。

• 准备一个upstream的虚拟域名,保管后端服务器的详细信息

  //定义后台服务器的信息,list列表
  upstream ouservers {
       server 127.0.0.1:8093;
       server 127.0.0.1:8093;
       server 127.0.0.1:8293;
  }

  upstream的配置,会在nginx启动时加载成为一个内存的list对象

       元素有3个分别是8093 8193 8293,负载均衡的计算都是通过这个list完成的

• 在server中使用proxy_pass指向这个新创建的upstream名称ouservers,如果找到该proxy_pass,nginx会进行替换。

//案例   www.pp.com 访问nginx
//让nginx处理这个请求
server {
    listen 80;
    server_name www.pp.com;
    //正则表达式，匹配当前所有静态资源路径
    location / {
    root static;
    //默认使用首页，如果使用/ 在访问时，可以添加默认首页
    index index.html;
    }
    location /user {
    //实现转发功能，请求转发给后端8093 root是静态数据，proxy_pass动态数据
    proxy_pass http://ouservers;
    }
    location /order {
    //实现转发功能，请求转发给后端8093 root是静态数据，proxy_pass动态数据
    proxy_pass http://ouservers;
    }
    location /hello {
    proxy_pass http://ouservers;
    }
}

• 测试轮询

保存nginx.conf文件,重新加载/重新启动，即在nginx家目录总执行nginx -s reload

访问：http://www.pp.com/hello?name=王翠花

• 流程分析

请求地址:http://www.pp.com/hello

|进入nginx

|找到server

|匹配location /hello

|proxy_pass ouservers

|找到upstream中叫做ouservers的list列表

|从中计算轮询算法,拿到一个具体的服务器 127.0.0.1:8093

|将proxy_pass ouservers替换掉

响应地址:http://localhost:8093(8193/8293)/hello

2.1.2权重

总是按照物理均衡分配并发,有时候不满足实际情况.按照情况通过占用比例的分配均衡逻辑就是权 重,权衡比重。

例如：有三个服务节点8091、8092和8093其中一个服务节点的配置是 8 核 8G，另外两个节点的配置是 4 核 4G，那么如果使用轮询的方式来平均分配请求的话，8 核 8G 的节点分到的请求数量和 4 核 4G 的一样多，就不能发挥性能上的优势。

• 基于轮询完成

upstream ppservers {
     server 127.0.0.1:8091;
     server 127.0.0.1:8091;
     server 127.0.0.1:8091;
     server 127.0.0.1:8091;
     server 127.0.0.1:8091;
     server 127.0.0.1:8091;
     server 127.0.0.1:8092;
     server 127.0.0.1:8093;
}

• 权重关键字

可以在upstream的轮训基础上添加权重的关键字。

weight ：权重值整数

down ：该server不可访问

upstream testservers {
     server 127.0.0.1:8091 weight=10;
     server 127.0.0.1:8092 weight=5;
     server 127.0.0.1:8093 weight=1;
}

2.1.3ip_hash

主要是为了解决session集群共享问题。

• session会话技术

客户端访问服务器时,会根据需求(getSession()方法调用).生成一个服务器的session对象对应这个客 户端浏览器的cookie的sessionid值.保存客户端前后访问的状态。

• session登录功能

单机时代的web容器,可以使用session,因为没有共享问题,利用session实现同一个客户端会话的状态 读写,登录功能中,第一次登录,存储user信息,后续访问可以拿到user信息.

•  session共享

使用集群中的session,由于是多个web容器,每个之间的session不互通,所以使用session会话会在集 群结构时失效,例如登录逻辑,会频繁失败,重新登录。

•  解决session共享方案

○ 共享session

实时让web容器,通信相互保存读写session数据。

缺点:内存浪费严重。

○ ip_hash黏着

客户端ip地址不变,访问固定后端服务器。

缺点:可能导致后端某个服务器的访问压力有倾斜。

○ 第三方容器

将本来应该存储在session的数据,存储在第三方容器中（redis）。后续跟进...