nginx负载均衡

nginx负载均衡的5种策略

负载均衡的几种常用方式

1、轮询(默认)

每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。

upstream backserver {
    server 192.168.0.14;
    server 192.168.0.15;
}

2、weight

指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的 情况。

upstream backserver {
    server 192.168.0.14 weight=3;
    server 192.168.0.15 weight=7;
}

权重越高,在被访问的概率越大,如上例,分别是30%,70%。

3、ip_hash

上述方式存在一个问题就是说,在负载均衡系统中,假如用户在某台服务器上登录了,那么该用户第二次请求的时候,因为我们是负载均衡系统,每次请求都会重新定位到服务器集群中的某一个,那么已经登录某一个服务器的用户再重新定位到另一个服务器,其登录信息将会丢失,这样显然是不妥的。 我们可以采用ip_hash指令解决这个问题,如果客户已经访问了某个服务器,当用户再次访问时,会将该请求通过哈希算法,自动定位到该服务器。 每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。

upstream backserver {
    ip_hash;
    server 192.168.0.14:88;
    server 192.168.0.15:80;
}

4、fair(第三方)

按后端服务器的响应时间来分配请求,响应时间短的优先分配。

upstream backserver {
    server server1;
    server server2;
    fair;
}

5、url_hash(第三方)

按访问url的hash结果来分配请求,使每个url定向到同一个(对应的)后端服务器,后端服务器为缓存时比较有效。

upstream backserver {
    server squid1:3128;
    server squid2:3128;
    hash $request_uri;
    hash_method crc32;
}

在需要使用负载均衡的server中增加

proxy_pass http://backserver/; 
upstream backserver{ 
    ip_hash; 
    server 127.0.0.1:9090 down; (down 表示单前的server暂时不参与负载) 
    server 127.0.0.1:8080 weight=2; (weight 默认为1.weight越大,负载的权重就越大) 
    server 127.0.0.1:6060; 
    server 127.0.0.1:7070 backup; (其它所有的非backup机器down或者忙的时候,请求backup机器) 
}

max_fails :允许请求失败的次数默认为1.当超过最大次数时,返回proxy_next_upstream 模块定义的错误

fail_timeout:max_fails次失败后,暂停的时间

配置实例:

#user  nobody;

worker_processes  4;
events {
# 最大并发数
worker_connections  1024;
}
http{
    # 待选服务器列表
    upstream myproject{
        # ip_hash指令,将同一用户引入同一服务器。
        ip_hash;
        server 125.219.42.4 fail_timeout=60s;
        server 172.31.2.183;
    }

    server{
        # 监听端口
        listen 80;
        # 根目录下
        location / {
        # 选择哪个服务器列表
            proxy_pass http://myproject;
        }

    }
}

针对负载均衡集群中的session解决方案的总结

在日常运维工作中,当给Web站点使用负载均衡之后,必须面临的一个重要问题就是Session的处理办法,无论是PHP、Python、Ruby还是Java语言环境,只要使用服务器保存Session,在做负载均衡时都需要考虑Session的问题。

通常面临的问题

  • 从用户端来解释,就是当一个用户第一次访问被负载均衡代理到后端服务器A并登录后,服务器A上保留了用户的登录信息;当用户再次发送请求时,
  • 根据负载均衡策略可能被代理到后端不同的服务器,例如服务器B,由于这台服务器B没有用户的登录信息,所以导致用户需要重新登录。这对用户
  • 来说是不可忍受的。所以,在实施负载均衡的时候,我们必须考虑Session的问题。

  • 在负载均衡中,针对Session的处理,一般有以下几种方法:

  • 1)Session会话保持(案例:Nginx、Haproxy)
  • 2)Session会话复制(案例:Tomcat)
  • 3)Session会话共享(案例:Memcached、Redis)

1、Session会话保持

对于Nginx可以选用Session保持的方法实行负载均衡,nginx的upstream目前支持5种方式的分配方式,其中有两种比较通用的Session解决方法,ip_hash和url_hash。 注意:后者不是官方模块,需要额外安装。

会话保持的缺点:

  • 1) 会话保持看似解决了Session同步的问题,但是却带来的一些其它方面的问题:
  • 2)负载不均衡了:由于使用了Session保持,很显然就无法保证负载绝对的均衡。
  • 3)没有彻底解决问题:如果后端有服务器宕机,那么这台服务器的Session丢失,被分配到这台服务请求的用户还是需要重新登录。

2、Session会话保持

既然,我们的目标是所有服务器上都要保持用户的Session,那么将每个应用服务器中的Session信息复制到其它服务器节点上是不是就可以呢? 这就是Session的第二中处理办法:会话复制。

会话复制在Tomcat上得到了支持,它是基于IP组播(multicast)来完成Session的复制,Tomcat的会话复制分为两种:

  • 1)全局会话复制:利用Delta Manager复制会话中的变更信息到集群中的所有其他节点。
  • 2)非全局复制:使用Backup Manager进行复制,它会把Session复制给一个指定的备份节点。

不过,这里不准备来解释会话复制的Tomcat配置,如果有需求可以参考Tomcat官方文档,主要是因为会话复制不适合大的集群。根据生产的实践案例, 在集群超过6个节点之后就会出现各种问题,不推荐生产使用。

3、Session会话共享

既然会话保持和会话复制都不完美,那么我们为什么不把Session放在一个统一的地方呢,这样集群中的所有节点都在一个地方进行Session的存取就可以解决问题。

Session存放到哪里?

对于Session来说,肯定是频繁使用的,虽然你可以把它存放在数据库中,但是真正生产环境中我更推荐存放在性能更快的分布式KV数据中, 例如:Memcached和Redis。

PHP设置Session共享

如果使用的是PHP那么恭喜你,配置非常的简单。PHP通过两行配置就可以把Session存放在Memcached或者Redis中,当然你要提前配置好他们。修改php.ini:

使用Memcache存储Session session.save_handler = memcache session.save_path = "tcp://192.168.56.11:11211"

使用Redis存储Session session.save_handler = redis session.save_path ="tcp://localhost:6379"

提醒:别忘了给PHP安装memcache或者redis插件。

使用缓存保持Session

对于简单的缓存会话: 可以设置SESSION_ENGINE 为”django.contrib.sessions.backends.cache”。此时会话数据将直接存储在你的缓存中。然而,缓存数据将可能不会持久: 如果缓存填满或者缓存服务器重启,缓存数据可能会被清理掉。

若要持久的缓存数据: 可以设置SESSION_ENGINE为”django.contrib.sessions.backends.cached_db”。它的写操作使用缓存,对缓存的每次写入都将再写入到数据库。对于 读取的会话,如果数据不在缓存中,则从数据库读取。两种会话的存储都非常快,但是简单的缓存更快,因为它放弃了持久性。大部分情况下,cached_db后端已经足够快,但是如果你需要榨干最后一点的性能,并且接受会话数据丢失的风险,那么你可使用cache而不是cached_db

使用文件保存Session 使用文件保存Session不再我们的讨论之类,因为很难进行共享,PHP默认也是将Session存放在/tmp目录下。

4、简单总结:

  • 会话保持的缺点:负载不均衡;没有彻底解决问题.
  • 会话复制的缺点:集群超过6个节点就会出现一系列的问题.
  • 会话共享:会话数据共享在Nosql(Redis)数据库中分享。

配置:

access_log  /data/log/yongle.com.log;
error_log  /data/log/yongle.com.error;
upstream yongle.com {
      server 127.0.0.1:8081;
      server 127.0.0.1:8082;
      server 127.0.0.1:8083;
      server 127.0.0.1:8084;
      server 127.0.0.1:8085;
}
server {
        listen       80;
        server_name yongle.com;

        location / {
                proxy_pass         http://yongle.com;
                proxy_set_header   Host             $host;
                proxy_set_header   X-Real-IP        $remote_addr;
                proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        }
}

server {
        listen       8085;
        server_name  yongle.com;
        root  /data/wwwroot/aaa/;
        location / {
            index  index.html index.htm;
        }
}

results matching ""

    No results matching ""

    results matching ""

      No results matching ""