简介
nginx负载均衡策略相对来说比较方便配置。
策略有以下几种：
1)、轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| upstream test
{
server 10.0.1.31:8080;
server 10.0.1.32:8080;
}
server
{
listen 80;
server_name www.xxxx.com;
location / {
proxy_pass http://test;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
|
2)、weight
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| upstream test
{
server 10.0.1.31:8080 down;
server 10.0.1.32:8080 weight=2;
server 10.0.1.33:8080;
server 10.0.1.34:8080 backup;
}
server
{
listen 80;
server_name www.xxxx.com;
location / {
proxy_pass http://test;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
upstream 每个设备的状态:
down 表示单前的server暂时不参与负载
weight 默认为1.weight越大，负载的权重就越大。
max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误
fail_timeout:max_fails 次失败后，暂停的时间。
backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻
|
3)、ip_hash
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| upstream test {
server 127.0.0.1:8080 ;
server 127.0.0.1:9090 ;
ip_hash;
}
server
{
listen 80;
server_name www.xxxx.com;
location / {
proxy_pass http://test;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
|
4)、第三方插件
关于第三方插件，可以自行了解一下， 本文不做赘述
负载均衡导致的问题
在实际应用中，负载均衡肯定不会只用于静态页面，更多的是页面的交互，这样一来session会话的保持变成了负载均衡的问题所在。
session的保持主要可以使用三种方式
1、会话保持
对于Nginx可以选用Session保持的方法实行负载均衡，nginx的upstream目前支持5种方式的分配方式，其中有两种比较通用的Session解决方法，ip_hash和url_hash。注意：后者不是官方模块，需要额外安装。
ip_hash
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，达到了Session保持的方法。此种方法实现在上面有说明。
它的缺点是
负载未实现真正意义的均衡：由于使用了Session保持，很显然就无法保证负载绝对的均衡。
会话丢失可能性较大：如果后端有服务器宕机，那么这台服务器的Session丢失，被分配到这台服务请求的用户还是需要重新登录。
2、会话复制
会话复制在Tomcat上得到了支持，它是基于IP组播（multicast）来完成Session的复制，Tomcat的会话复制分为两种：
全局会话复制：利用Delta Manager复制会话中的变更信息到集群中的所有其他节点。
非全局复制：使用Backup Manager进行复制，它会把Session复制给一个指定的备份节点。
可以参考Tomcat官方文档，主要是因为会话复制不适合大的集群。不推荐生产服务器使用此种方式。
3、会话共享
共享就意味着借用第三方缓存来对seesion进行存储，后端服务器可根据存储来判断会话的正确性。
缓存的方式较多，比较常用的方法是redis缓存，redis是key-value的内存性数据库，吞吐量极高，在一定的内存下，除非并发数极高，否则很难达到redis的吞吐极限。
使用redis作为session缓存，直接将会话信息存储到redis中，服务端以高效率读取redis中session，实现了负载均衡情况下seesion的会话保持。它的性能决定了它的瓶颈较高，
一般情况下足够使用。
