nginx负载均衡具体实现策略及场景

轮询

轮询是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所在地址

   }

1

2

3

4

哈希

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

 

假如用户是在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所在地址

   }

1

2

3

4

5

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

版权声明：本文内容转发自阿里云社区，由阿里云实名注册用户自发贡献！版权归原作者所有。本站不拥有其著作权，亦不承担相应法律责任。如果您发现本文中有涉嫌抄袭的内容，请联系站内客服，本站将立刻删除涉嫌侵权内容。