程序员的nginx技能包(6)——负载均衡具体实现策略及场景

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/woshisangsang/article/details/86763099

背景

上篇讲了负载均衡详细的实现方法,其实已经基本够用了,但是还有一些更为复杂的负载均衡策略配置,今天结合使用场景介绍下。

轮询

轮询是nginx默认的负载均衡实现方式,此时会将没给请求按时间顺序分配到对应server,如下所示:

    upstream balance1{
        server 47.104.61.1;#tomcat1所在地址
        server 47.104.61.2;#tomcat2所在地址
    }

对服务器的请求会按顺序分配到47.104.61.1和47.104.61.2。

这种方式下,如果47.104.61.1挂掉了,没事,47.104.61.2还能提供服务。这个nginx能自动检测出。所谓的双机热备,这就是很好的实现方式。所以对应的架构可为:

图片描述

权重

上面架构在一些公司就出现问题了,由于历史原因,tomcat1所在服务器性能强大,tomcat2所在服务器性能比较垃圾(内存低、带宽低、响应慢),这样tomcat1其实性能都没发挥出来,tomcat2都快要累死了。

这时候也不着急,配置下轮询权重就是了,如下所示,80%的请求由tomcat1处理,20%tomcat2处理,完美。

    upstream balance1{
        server 47.104.61.1 weight:8;#tomcat1所在地址
        server 47.104.61.2 weight:2;#tomcat2所在地址
    }

哈希

上面的架构还是有问题啊,如果是需要用户登录之后反复操作的系统,例如商城。

假如用户是在tomat1登录的,然后系统用session保存了登录用户的信息。

结果用户第二个请求发送到了tomcat2,此时悲剧了,tomcat2认为用户没登录。

没关系,nginx已经考了到了这种情况,直接使用哈希策略,此时nginx会自动识别访问者的ip,然后通过哈希算法分配一个固定的服务器给该访问者,所以对同一个用户来说,每次访问都是由一个服务器响应了。

配置如下:

    upstream balance1{
	    ip_hash;#如此简单的配置就能产生重大作用
        server 47.104.61.1 weight:8;#tomcat1所在地址
        server 47.104.61.2 weight:2;#tomcat2所在地址
    }

后端无状态下负载均衡策略的使用

现在都讲究后端无状态,啥是无状态,简单理解就是后端没有session,用户的请求也不用每次都固定到后端一个服务器上。

那如何来识别用户是否登录呢。

此处举个简单的例子,假设咱们的系统是用户商城。

用户登录成功后,咱们生成一个UUID与用户编号一起存到数据库中,标志着会话开始。

用户在前端拿到UUID后,后续每次请求都携带UUID到达后端。

后端通过拦截器,看看UUID是否合法(数据库中存在且不超时),不合法的请求不响应即可。

当然在现实程序中,这种频繁访问数据的场景放到数据库中速度太慢,对数据库拖累严重。

所以可以放到缓存数据库如redis中,这样速度就大大加快了。

此时负载均衡策略的制定就很自由了,因为nginx重启非常迅速,后端接口又没有状态,我们可以通过监控看各个服务器的负载情况,然后动态的调整权重即可。

当所有服务器都不堪忍受的时候,加服务器,然后重新配置nginx即可,完全不会影响业务正常运作。

猜你喜欢

转载自blog.csdn.net/woshisangsang/article/details/86763099