Nginx负载均衡

为什么选择负载均衡

现有网络的各个核心部分随着业务量的提高，访问量和数据流量的快速增长，其处理能力和计算强度也相应地增大，使得单一的服务器设备根本无法承担。仅仅是升级硬件的话抛开成本不谈，效果也不见得一定好，因为业务是不断增长的，单纯的升级硬件解决不了性能的问题

针对此情况而衍生出来的一种廉价有效透明的方法以扩展现有网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性的技术就是负载均衡（Load Balance）。

负载均衡方式

• 轮询（默认）

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

  upstream backserver {
      server 192.168.0.14;
      server 192.168.0.15;
  }
  

• 按权重weight分配

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

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

• ip_hash

  每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

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

• url_hash(第三方)

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

  下面我来用自己的电脑和服务器做测试

  1.本地nginx http配置

  upstream timeMachine.com {
      server 49.100.142.92:8001  weight=3;
      server 49.100.142.92:520   weight=1;
  }
  

  timeMachine.com要与下面server配置中location下的proxy_pass一样

  49.100.142.92是我个人的服务器 8001端口是eoliner文档项目 520是一个canvas项目

  2.本地nginx server配置

  server {
      listen 80;
      server_name api.upstream.com;
  
       location / {
          proxy_pass http://timeMachine.com;
          proxy_redirect default;
       }
  
  }
  

  这里的域名server_name api.upstream.com只是在hosts文件配置了一下

  我们在本地浏览器多次访问api.upstream.com，测试结果是出现不同的项目，其中8001端口出现的次数较520端口多