nginx负载均衡配置及常见负载均衡策略

nginx负载均衡基本配置

负载均衡的意思，指的就是，当你后台有很多服务器的时候，有的性能好，有的性能差一些，怎么把传递过来的请求，比较合理的分配给这些服务器，就是负载均衡需要解决的问题。
nginx负载均衡配置
在proxy_pass后面配置，随便起个名字，然后，在upstream中配置后台服务器，默认是轮询模式，也就是挨个轮流。

http {
    upstream aaaa {
    ##默认是轮询模式
        server 127.0.0.1:80;
        server 127.0.0.2:80;
    }
    server {
        listen 80;
        server_name www.domain.com;
        location / { 
 		##为upstream起个名字，比如aaaa
            proxy_pass http://aaaa;
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

负载均衡常见策略

1. 加权重weight
   比如，第一个服务器的权重是10，第二个是1，那么，分配到第一个的概率就是分配到第二个的10倍

http {
    upstream aaaa {
    ##默认是轮询模式
        server 127.0.0.1:80 weight=10;
        server 127.0.0.2:80 weight=1;
    }
    server {
        listen 80;
        server_name www.domain.com;
        location / { 
 		##为upstream起个名字，比如aaaa
            proxy_pass http://aaaa;
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

2. down
   可以暂时关闭某个服务器

http {
    upstream aaaa {
    ##默认是轮询模式
        server 127.0.0.1:80 weight=10 down;
        server 127.0.0.2:80 weight=1;
    }
    server {
        listen 80;
        server_name www.domain.com;
        location / { 
 		##为upstream起个名字，比如aaaa
            proxy_pass http://aaaa;
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

3. backup
   备用服务器，正常情况下不会用，别人都不行的时候，会临时顶上去

http {
    upstream aaaa {
    ##默认是轮询模式
        server 127.0.0.1:80 weight=10;
        server 127.0.0.2:80 weight=1 backup;
    }
    server {
        listen 80;
        server_name www.domain.com;
        location / { 
 		##为upstream起个名字，比如aaaa
            proxy_pass http://aaaa;
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

4 ip_hash
轮询和weight最大的问题，就是不能长期稳定的连接在同一台服务器上，如果是需要读取cookie或者session的情况，就不太适合了，因此，ip_hash就是用ip地址去通过hash算法映射到服务器上，同一个ip总是映射到相同服务器上。
但是一般不会用ip_hash，因为某些情况下，ip并不能保持一直不变，比如手机，走到不同的移动基站，ip会变。
5 least_conn
最少连接数，其实也不合理，会打破weight的权限设置，同时，如果新添加一台服务器，新服务器没初始化完成时，就会接到大量任务，导致速度缓慢。
6 fair
需要下载第三方插件，根据服务器响应时间转发请求。
会造成流量倾斜，会被网络速度影响较大。
7 url_hash
是根据请求资源的路径来进行hash计算，保持回话，定向流量转发，相同的url必定指向相同的服务器。
但是url_hash也并不适合维持会话，比如，登录时候是一个服务器，此时登陆成功，session和cookie已经写在这个服务器上了，然后请求了其他资源，可能又会映射到其他服务器上了，session和cookie就拿不到了。所以，url_hash更多是针对固定资源的，对于固定资源，根据url_hash去固定的服务器拿，比较合适。

总结

其实上面的各种策略，往往最简单的轮询反而是最好用的，那，如何解决会话的问题呢？
往往一般情况下，session会统一存在一个特定的服务器上，无论nginx讲任务映射到那台服务器上，这台服务器都会去这个特定的服务器上拿session，这个特定的服务器，往往就是一个redis服务器。

token

高并发状态，往往是通过token来校验和保存客户信息。
Token 是在服务端产生的。如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回 Token 给前端。前端可以在每次请求的时候带上 Token 证明自己的合法地位。如果这个 Token 在服务端持久化（比如存入数据库），那它就是一个永久的身份令牌。
token可以解决哪些问题呢？
1 Token 完全由应用管理，所以它可以避开同源策略
2 Token 可以避免 CSRF 攻击(http://dwz.cn/7joLzx)
3 Token 可以是无状态的，可以在多个服务间共享