nginx反向代理与负载均衡
什么是正向代理？
正向代理，架设在客户机与目标主机之间，只用于代理内部网络对 Internet 的连接请求，客户机必须指定代理服务器,并将本来要直接发送到 Web 服务器上的 Http 请求发送到代理服务器中。
什么是反向代理？
反向代理服务器架设在服务器端，通过缓冲经常被请求的页面来缓解服务器的工作量，将客户机请求转发给内部网络上的目标服务器；并将从服务器上得到的结果返回给 Internet 上请求连接的客户端，此时代理服务器与目标主机一起对外表现为一个服务器。
负载均衡的作用
负载均衡：分摊到多个操作单元上进行执行，和它的英文名称很匹配。就是我们需要一个调度者，保证所有后端服务器都将性能充分发挥，从而保持服务器集群的整体性能最优，这就是负载均衡。
负载均衡这里面涉及的东西相对也是比较多的，理论就不说太多了，网上，书上很多，今天我们就利用Nginx服务器来实现一个简单的负载均衡
负载均衡算法
源地址哈希法：根据获取客户端的IP地址，通过哈希函数计算得到一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。
轮询法：将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载。
随机法：通过系统的随机算法，根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。
加权轮询法：不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重，让其处理更多的请；而配置低、负载高的机器，给其分配较低的权重，降低其系统负载，加权轮询能很好地处理这一问题，并将请求顺序且按照权重分配到后端。
加权随机法：与加权轮询法一样，加权随机法也根据后端机器的配置，系统的负载分配不同的权重。不同的是，它是按照权重随机请求后端服务器，而非顺序。
最小连接数法：由于后端服务器的配置不尽相同，对于请求的处理有快有慢，最小连接数法根据后端服务器当前的连接情况，动态地选取其中当前积压连接数最少的一台服务器来处理当前的请求，尽可能地提高后端服务的利用效率，将负责合理地分流到每一台服务器。
Nginx
俄罗斯人开发的一个高性能的 HTTP和反向代理服务器。由于Nginx 超越 Apache 的高性能和稳定性，使得国内使用 Nginx 作为 Web 服务器的网站也越来越多，其中包括新浪、网易、腾讯、搜狐等企业的一些门户网站等，在3w以上的高并发环境下，ngnix处理能力相当于apache的10倍。
Nginx在负载均衡这方面就是负载均衡的的一个组件，当然了还有Apache也属于其中的一个组件，还有很多很多。我之前看到过一篇文章，在这方面做过一个简单介绍，下篇文章我会做一个转载来进行说明。
轮询法
这个例子我就在我服务器上做了个实验，属于一个简陋版的，实际应用中负载均衡的搭建和配置是比较麻烦的，需要考虑的因素很多
先说一下，nginx来做这个静态资源代理也是非常不错的，我在这个例子中就是做了这两块的内容。一个就是nginx做静态资源代理，一个是负载均衡的实现。
由于自己试验，我手里只有两台服务器，所以负责调度分发的nginx服务器和其中一台处理服务器在一起，然后还有另一台单独的处理服务器。大概是这样：
实际上应该是这样的：
下面我们来看下Nginx的配置，是如何实现这个负载均衡的？
说明：我的一号服务器原来装了一个LNMP一键安装包，所以待会你看nginx配置文件的时候可能会发现和你得略有不同，但是没有影响，就是一些配置项。我是将每个项目的配置文件单独放置了，并没有全部配置在nginx.conf文件中。
//nginx.conf
//这样配置，我就可以在nginx.conf文件当前路径的vhost文件夹下面单独管理每个项目的配置文件了
...
...
...
include vhost/*.conf;
}//这个是文件末尾的闭合大括号
比如我有四个项目需要管理，vhost文件夹下如图：
我们现在来配置test-yii2.conf实现负载均衡。（这个文件其实很早存在的，懒得创建直接使用了）
//test-yii2.conf
upstream guwenjie_http {
server **.***.***.***:9503 weight=1;
server **.***.***.***:8811 weight=2;
}
server
{
listen 80;
#listen [::]:80 default_server ipv6only=on;
server_name test1.freephp.top;
index index.php index.html index.htm ;
root /home/wwwroot/workspace/public/static;
#error_page 404 /404.html;
# Deny access to PHP files in specific directory
#location ~ /(wp-content|uploads|wp-includes|images)/.*\.php$ { deny all; }
include enable-php.conf;
location / {
if (!-e $request_filename){
#proxy_pass http://127.0.0.1:8855;
proxy_pass http://guwenjie_http;
}
}
location /nginx_status
{
stub_status on;
access_log off;
}
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
{
expires 30d;
}
location ~ .*\.(js|css)?$
{
expires 12h;
}
location ~ /.well-known {
allow all;
}
location ~ /\.
{
deny all;
}
千万不要直接复制以上配置文件，因为其中的某些配置可能会对你的配置造成影响，大多数是不要虚理会的，我们主要解释其中几个点。
静态资源代理
我们将root 目录设置为下面所示目录，这里存放静态资源，其实他真正的存放于 127.0.0.1:8855 项目下的该目录。这里的IP本应是另一台服务器IP，为了测试就使用本机了。
那么在这种情形下，当你访问配置的域名： test1.freephp.top/index.html 文件的话，我们依然能够访问成功，并且访问到了 127.0.0.1:8855 下 static 目录下的index.html
...
...
root /home/wwwroot/workspace/public/static;
...
...
location / {
if (!-e $request_filename){
proxy_pass http://127.0.0.1:8855;
}
}
负载均衡配置
我们使用 nginx 中的 upstream模块 来实现nginx将跨越单机的限制，完成网络数据的接收、处理和转发。我们主要使用提到的转发功能进行调度分发。
我定义的 upstream 模块名称是 guwenjie_http （最好定义一个有意义的，这个就很不好 _），我配置了两个IP端口，到时候nginx分发的视乎就往这两个服务器上分发。
先来对 upstream 进行一个说明吧
//举例，以下IP，端口无效
upstream test{
server 11.22.333.11:6666 weight=1;
server 11.22.333.22:8888 down;
server 11.22.333.33:8888 backup;
server 11.22.333.44:5555 weight=2;
}
//down 表示单前的server临时不參与负载.
//weight 默觉得1.weight越大，负载的权重就越大
//backup： 其他全部的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻
后面的 weight=1，weight=2 是表示权重的意思，数字越大，权重越高，在该例中 8811 这个端口权重就是 8855 的两倍，比如三次请求，大概就是两次分发给 8811 一次分发给 8855 ，其实这个是不需要写的，upstream 模块默认就是轮询法，每个ip分发一次，设置权重（加权轮询法）的意义上面已经解释过了，可以看下。
upstream guwenjie_http {
server **.***.***.***:8855 weight=1;
server **.***.***.***:8811 weight=2;
}
...
...
root /home/wwwroot/workspace/public/static;
...
...
location / {
if (!-e $request_filename){
proxy_pass http://guwenjie_http;
}
}
源地址哈希法
什么是源地址哈希法，就是对访问用户的IP进行hash后的结果进行分配，这样每一个用户固定请求同一个后端服务器，能够解决session的问题。
直接上代码吧
upstream guwenjie_http {
ip_hash;
server **.***.***.***:8855;
server **.***.***.***:8811;
}
...
...
fair法（非官方）
这个fair表示的是按照服务器响应时间的长短来进行分发的，服务器响应时间越短的，优先分发。
upstream guwenjie_http {
server **.***.***.***:8855;
server **.***.***.***:8811;
fair;
}
...
...
说明
以上就是简单的负载均衡的实现。准确的来说，这些属于：HTTP重定向实现负载均衡。它有一个比较大的缺点，（引用：）由于不同用户的访问时间、访问页面深度有所不同，从而每个用户对各自的后端服务器所造成的压力也不同。而调度服务器在调度时，无法知道当前用户将会对服务器造成多大的压力，因此这种方式无法实现真正意义上的负载均衡，只不过是把请求次数平均分配给每台服务器罢了。
但是它确实实现了负载均衡，在一些要去并不强烈的项目中可以使用http重定向来实现均衡每台服务器压力的效果，以达到更高的并发总量。
之后，我会将看到的另一篇我自己感觉比较好的关于负载均衡分析的文章转发给大家看一下
