nginx负载均衡

nginx(反向代理服务器)

正向代理

场景：在国内是无法正常使用google.com。如果想要访问google.com，可以购买一台国外的服务器a，此时你和服务器a的网络是相通的。而服务器a又跟google.com相通， 此时可以由服务器a代理你（客户端），去访问google.com。这个过程称之为正向代理，服务端（google.com）只需要知道代理服务器的ip，不需要知道客户端的ip。

示例1：

示例2：

 

结论：正向代理，是用于代理客户端的。

反向代理

场景：当一个服务器接受过多来自客户端的请求时，服务器难以处理和响应这些请求，会使得整个系统性能下降。为了解决这个难题，可以提供多台部署相同应用的服务器，让客户端的请求分别发送到不同的服务器上，这样单机服务器的压力就会降低很多，整体性能便会提升。但是有一个问题，每个服务器ip都是不同的，也就是说客户端的请求要发送到多个不同的ip上。让客户手动指定ip进行请求，这种方式很不明智。首先是客户的随机性，不知道会访问哪台服务器，其次，会造成一部分服务器压力大，一部分服务器几乎没有使用，浪费资源。因此，这里就需要一个角色去代理服务器，让客户端的请求直接发送到这个角色上，由这个角色去分发请求到不同的服务器上。
这个角色就是反向代理服务器。

 

结论：反向代理，是用于代理服务端的。

负载均衡

场景：反向代理过程中，每台服务器处理来自客户端的请求都应该是均衡的。
原理：使用一个反向代理服务器指向多台部署相同应用的服务器，客户端请求直接向反向代理服务器发起，反向代理服务器根据负载均衡机制，将请求转发到不同的应用服务器上。
负载均衡机制：

nginx提供了一下三种方法：
1）round-robin：请求以循环、轮转的方式分发到服务器
2）least-connected：下一个请求被分配到拥有最少活动连接数的服务器
3）ip-hash：使用一个哈希函数，基于客户端ip地址判断下一个请求应该被分发到哪台服务器

相关配置说明
1）循环、轮转负载均衡
round-robin：默认情况下，使用循环、轮转的方式分发请求到服务器
配置示例：

 1 http{
 2     upstream myapp{
 3         server srv1.example.com;
 4         server srv2.example.com;
 5         server srv3.example.com;
 6     }
 7     server{
 8         listen 80;
 9         location / {
10             proxy_pass http://myapp;
11         }
12     }
13 }

 

当不指定负载均衡方式时，默认以round-robin方式实现。所有请求都会被代理到myapp服务器，根据负载均衡机制分发请求。 

2）最少连接负载均衡
least-connected：当一些请求处理的时间比较长时，最少连接负载均衡能够争取到更大的公平。
配置示例：

1 upstream myapp{
2     least-conn;
3     server srv1.example.com;
4     server srv2.example.com;
5     server srv3.example.com;
6 }

 

3）基于ip地址的负载均衡 

ip-hash：采用目标地址散列调度（destination hashing scheduling）算法，根据请求的目标ip地址，作为散列键（hash key）从静态分配的散列表找出对应的服务器，若该服务器可用且未超载，则将请求发送带服务器，否则返回空。

1 upstream myapp{
2     ip-hash;
3     server srv1.example.com;
4     server srv2.example.com;
5     server srv3.example.com;
6 }

 

nginx和zookeeper协同使用场景： 

1.单纯使用nginx，会造成配置维护成本变高。
2.单点故障率增加，因为热点服务的访问量很高，如果这个服务的负载均衡服务出现问题，整个服务都会挂点