客户端发送多个请求到服务器,服务器处理请求,有一些可能要与数据库进行交互,服务器处理完之后,将结果返回给客户端。
这种架构对于早期的系统相对单一,并发请求相对少的情况下,是比较合适的,成本也低,但是随着信息数量的不断增长,访问和数据量的飞速增长,以及业务系统的复杂度增加,这种架构会造成服务器相应客户端的请求日益缓慢,并发量特别大的时候,还容易造成服务器直接崩溃。很明显这是因为服务器性能的瓶颈造成的问题,那么如何解决这种情况呢？
我们首先想到的是升级服务器的配置,如提高CPU执行频率,加大内存等提高机器的物理性能来解决此问题,但是我们知道摩尔定律的日益失效,硬件性能的提升,已经不能满足日益提升的需求
上面的分析我们去掉了增加服务器物理配置来解决问题的方法,也就是说纵向解决问题的办法行不通了,那么很想增加服务器的数量呢?这时候集群的概念产生了,单个服务器解决不了,我们增加服务器数量,然后将请求分发到各个服务器上,将原先的请求集中到单个服务器上的情况,改为将请求分发到多个服务器上,将负载分发到不同服务器上,也就是我们所说的负载均衡

Nginx配置负载均衡

  • 准备两台tomcat服务器

  • 在http块中配置 upstream [自定义访问名称] { server host:port;server host2:port;server host3:port;} 配置完成之后我们在location块中配置proxy_pass http://[自定义访问名称]

  • 图片配置查看

随着互联网信息的爆炸性信息的不断增长,负载均衡(load balanced),已经不再是个陌生的话题,顾名思义,负载均衡既是将负载分摊到不同的服务单元,既保证服务的可用性,有保证相应足够快,给用户很好的体验,快速增长的访问量和数据流量催生了各式各样的负载均衡产品,Nginx就是其中一个,而且Nginx提供了几种分配策略(方式)

策略

  • 轮询策略(默认的策略)

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

  • weight(权重)

    • weight代表权重,默认为1权重越高被分配的客户端越多

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

      • 配置图片

  • ip_hash

    • 每个请求按访问IP的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决Session的问题,就是根据用户的Ip来判断访问哪个服务器,后面访问的话也会一直访问第一次的那个服务器

    • 配置图片

  • fair(第三方)

    • nginx需要集成才能使用

    • 安装后端服务器的响应时间来分配请求,响应时间短的优先分配

    • 配置图片