星空

人生不仅有眼前的苟且,还有诗和远方.

0%

nginx负载均衡策略

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的会话保持。它的性能决定了它的瓶颈较高,
一般情况下足够使用。