首先简单的介绍下修改默认的nginx conf 大概在 ~ 行 去掉前面的#号 重启nginx
#location ~ php$ {# proxy_pass #}改为 location ~ php$ { proxy_pass // : }
分别访问 出现如下图已经能够针对不同请求访问服务器了
这样当我们访问 l的时候 前端的nginx会自动进行响应 当访问 /test php的时候(这个时候nginx目录下根本就没有该文件) 但是通过上面的设置location ~ php$(表示
访问php页面test php : 的Apache进行响应
访问目录phpMyAdmin下的页面的话 : 的Apache进行响应
修改原始默认的nginx conf的server模块部分（大概在 ~ 行）
#location ~ php$ {# proxy_pass #}修改为 location ^~ /phpMyAdmin/ { proxy_pass : } location ~ php$ { proxy_pass : }
上面第一个部分location ^~ /phpMyAdmin/ 表示不使用index index
2.在配置文件nginx.conf的模块中添加服务器集群server cluster的定义。Tw.WinGWit.
upstream myCluster { server 192.168.2.3:8080 server 192.168.2.2:80 server 192.168.2.8:80 }
表示这个server cluster包含3台服务器
3.然后在server模块中定义负载均衡
location ~ .php$ { proxy_pass //myCluster proxy_redirect offproxy_set_header Host $hostproxy_set_header X-Real-IP $remote_addrproxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for}
proxy_pass //myCluster 这里的名字和上面的cluster的名字相同
配置好后，当访问页面，nginx目录下根本没有该文件，但是它会自动将其pass到myCluster定义的服务器群，分别由上述的3台服务器中的一台来做处理。
上面在定义upstream的时候每个server之后没有定义权重，表示两者均衡；如果希望某个更多响应的话，可以加weight
upstream myCluster { server 192.168.2.3:8080 weight=5server 192.168.2.2:80 server 192.168.2.8:80 }
这样表示5/7的几率访问第一个server,1/7访问第二个、第三个。另外还可以定义max_fails和fail_timeout等参数。
所以我们使用nginx的反向代理服务器reverse proxy server的功能，将其布置到多台apache server的前端。
nginx仅仅用来处理静态页面响应和动态请求的代理pass，后台的apache服务器来对前台pass过来的动态页面进行处理并返回给nginx。
说到代理，首先我们要明确一个概念，所谓代理就是一个代表、一个渠道；此时就涉及到两个角色，一个是被代理角色，一个是目标角色。
被代理角色通过这个代理访问目标角色完成一些任务的过程称为代理操作过程；如同生活中的专卖店，客人到 adidas 专卖店买了一双鞋，这个专卖店就是代理，被代理角色就是 adidas 厂家，目标角色就是用户。
说反向代理之前，我们先看看正向代理，正向代理也是大家最常接触到的代理模式，我们会从两个方面来说关于正向代理的处理模式，分别从软件方面和生活方面来解释一下什么叫正向代理。
在如今的网络环境下，我们如果由于技术需要要去访问国外的某些网站，此时你会发现位于国外的某网站我们通过浏览器是没有办法访问的。
此时大家可能都会用一个操作 FQ 进行访问，FQ 的方式主要是找到一个可以访问国外网站的代理服务器，我们将请求发送给代理服务器，代理服务器去访问国外的网站，然后将访问到的数据传递给我们！
上述这样的代理模式称为正向代理，正向代理最大的特点是客户端非常明确要访问的服务器地址；服务器只清楚请求来自哪个代理服务器，而不清楚来自哪个具体的客户端；正向代理模式屏蔽或者隐藏了真实客户端信息。
来看个示意图（我把客户端和正向代理框在一块，同属于一个环境，后面我有介绍）：
客户端必须设置正向代理服务器，当然前提是要知道正向代理服务器的 IP 地址，还有代理程序的端口。
如下图：
明白了什么是正向代理，我们继续看关于反向代理的处理方式，举例如我国的某宝网站，每天同时连接到网站的访问人数已经爆表，单个服务器远远不能满足人民日益增长的购买欲望了。
此时就出现了一个大家耳熟能详的名词：分布式部署；也就是通过部署多台服务器来解决访问人数限制的问题。
某宝网站中大部分功能也是直接使用 Nginx 进行反向代理实现的，并且通过封装 Nginx 和其他的组件之后起了个高大上的名字： Tengine 。有兴趣的童鞋可以访问 Tengine 的官网查看具体的信息
那么反向代理具体是通过什么样的方式实现的分布式的集群操作呢，我们先看一个示意图（我把服务器和反向代理框在一块，同属于一个环境，后面我有介绍）：
通过上述的图解大家就可以看清楚了，多个客户端给服务器发送的请求，Nginx 服务器接收到之后，按照一定的规则分发给了后端的业务处理服务器进行处理了。
此时请求的来源也就是客户端是明确的，但是请求具体由哪台服务器处理的并不明确了，Nginx 扮演的就是一个反向代理角色。
客户端是无感知代理的存在的，反向代理对外都是透明的，访问者并不知道自己访问的是一个代理。因为客户端不需要任何配置就可以访问。
项目场景
通常情况下，我们在实际项目操作时，正向代理和反向代理很有可能会存在同一个应用场景中，正向代理代理客户端的请求去访问目标服务器，目标服务器是一个反向单利服务器，反向代理了多台真实的业务处理服务器。
具体的拓扑图如下：
截了一张图来说明正向代理和反向代理二者之间的区别，如下图：
我们已经明确了所谓代理服务器的概念，那么接下来，Nginx 扮演了反向代理服务器的角色，它是依据什么样的规则进行请求分发的呢？不用的项目应用场景，分发的规则是否可以控制呢？
这里提到的客户端发送的、Nginx 反向代理服务器接收到的请求数量，就是我们说的负载量。请求数量按照一定的规则进行分发，到不同的服务器处理的规则，就是一种均衡规则。
所以将服务器接收到的请求按照规则分发的过程，称为负载均衡。
负载均衡在实际项目操作过程中，有硬件负载均衡和软件负载均衡两种，硬件负载均衡也称为硬负载，如 F5 负载均衡，相对造价昂贵成本较高。
但是数据的稳定性安全性等等有非常好的保障，如中国移动中国联通这样的公司才会选择硬负载进行操作。
更多的公司考虑到成本原因，会选择使用软件负载均衡，软件负载均衡是利用现有的技术结合主机硬件实现的一种消息队列分发机制。
Nginx 支持的负载均衡调度算法方式如下：
Web 服务器对比
源自： https://baijiahao.baidu.com/s?id=1652608869911988442&wfr=spider&for=pc
理解负载均衡，必须先搞清楚正向代理和反向代理。
注：
正向代理，代理的是用户。
反向代理，代理的是服务器
什么是负载均衡
当一台服务器的单位时间内的访问量越大时，服务器压力就越大，大到超过自身承受能力时，服务器就会崩溃。为了避免服务器崩溃，让用户有更好的体验，我们通过负载均衡的方式来分担服务器压力。
我们可以建立很多很多服务器，组成一个服务器集群，当用户访问网站时，先访问一个中间服务器，在让这个中间服务器在服务器集群中选择一个压力较小的服务器，然后将该访问请求引入该服务器。如此以来，用户的每次访问，都会保证服务器集群中的每个服务器压力趋于平衡，分担了服务器压力，避免了服务器崩溃的情况。
负载均衡是用反向代理的原理实现的。
1、轮询（默认）
每个请求 按时间顺序逐一分配 到不同的后端服务器，如果后端服务器down掉，能自动剔除。
upstreambackserver {server192.168.0.14server192.168.0.15}
2、weight
指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的
情况。
upstreambackserver {server192.168.0.14weight=3server192.168.0.15weight=7}
权重越高，在被访问的概率越大，如上例，分别是30%，70%。
3、上述方式存在一个问题就是说，在负载均衡系统中，假如用户在某台服务器上登录了，那么该用户第二次请求的时候，因为我们是负载均衡系统，每次请求都会重新定位到服务器集群中的某一个，那么已经登录某一个服务器的用户再重新定位到另一个服务器，其登录信息将会丢失，这样显然是不妥的。
我们可以采用ip_hash指令解决这个问题，如果客户已经访问了某个服务器，当用户再次访问时，会将该请求通过哈希算法，自动定位到该服务器。
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
upstreambackserver{ip_hashserver192.168.0.14:88server192.168.0.15:80}
4、fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
upstreambackserver {serverserver1serverserver2fair}
5、url_hash（第三方）
按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
upstream backserver { server squid1:3128 server squid2:3128 hash$request_uri hash_method crc32}123456
每个设备的状态设置为:
down 表示单前的server暂时不参与负载
weight 默认为1.weight越大，负载的权重就越大。
max_fails：允许请求失败的次数默认为1.当超过最大次数时，返回 proxy_next_upstream模块定义的错误
fail_timeout:max_fails次失败后，暂停的时间。
backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。
配置实例：
#user nobodyworker_processes4events {# 最大并发数worker_connections1024}http{# 待选服务器列表upstream myproject{# ip_hash指令，将同一用户引入同一服务器。ip_hash server125.219.42.4fail_timeout=60s server172.31.2.183 } server{# 监听端口listen80# 根目录下location / {# 选择哪个服务器列表proxy_pass http://myproject } }
摘自https://www.cnblogs.com/lcword/p/12513155.html
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）