负载均衡

最新推荐文章于 2024-08-22 15:10:07 发布

何同学coding

最新推荐文章于 2024-08-22 15:10:07 发布

阅读量376

点赞数

分类专栏： Java 文章标签：负载均衡负载均衡器 lvs nginx反向代理负载均衡算法

本文链接：https://blog.csdn.net/qq_43466788/article/details/109494645

版权

Java 专栏收录该内容

21 篇文章 1 订阅

订阅专栏

负载均衡

什么是负载均衡？

负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

负载均衡（Load Balance）其意思就是分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。

为什么要用到负载均衡？

随着网站、应用访问量的增加，一台服务器已经不能满足应用的需求，而需要多台服务器集群，这时就会用到负载均衡。

负载均衡优化了访问请求在服务器组之间的分配，消除了服务器之间的负载不平衡，从而提高了系统的反应速度与总体性能。

负载均衡可以对服务器的运行状况进行监控，及时发现运行异常的服务器，并将访问请求转移到其它可以正常工作的服务器上，从而提高服务器组的可靠性采用了负均衡器器以后，可以根据业务量的发展情况灵活增加服务器，系统的扩展能力得到提高，同时简化了管理。

负载均衡、分布式和集群之间的关系？

集群：同一个业务，部署在多个服务器上。
分布式：一个业务分拆成多个子业务，或者本身就是不同的业务，部署在不同的服务器上。
集群和分布式的实现都需要负载均衡。
简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。
举例：就比如访问一个网站，访问的人多了，他可以做一个群集，前面放一个均衡服务器，后面几台服务器完成同一业务，如果有业务访问的时候，响应服务器看哪台服务器的负载不是很重，就将给哪一台去完成，并且一台服务器垮了，其它的服务器可以顶上来。分布式的每一个节点，都完成不同的业务，一个节点垮了，那这个业务可能就失败了。

负载均衡是怎么实现的？

随着业务量的提高，现有网络的各个核心部分访问量和数据流量的快速增长，其处理能力和计算强度也相应地增大，使得单一的服务器设备根本无法承担。在此情况下，如果扔掉现有设备去做大量的硬件升级，这样将造成现有资源的浪费，而且如果再面临下一次业务量的提升时，这又将导致再一次硬件升级的高额成本投入，甚至性能再卓越的设备也不能满足当前业务量增长的需求。

负载均衡技术通过设置虚拟服务器IP（VIP），将后端多台真实服务器的应用资源虚拟成一台高性能的应用服务器，通过负载均衡算法，将用户的请求转发给后台内网服务器，内网服务器将请求的响应返回给负载平衡器，负载平衡器再将响应发送到用户，这样就向互联网用户隐藏了内网结构，阻止了用户直接访问后台（内网）服务器，使得服务器更加安全，可以阻止对核心网络栈和运行在其它端口服务的攻击。并且负载均衡设备（软件或硬件）会持续的对服务器上的应用状态进行检查，并自动对无效的应用服务器进行隔离，实现了一个简单、扩展性强、可靠性高的应用解决方案，解决了单台服务器处理性能不足，扩展性不够，可靠性较低的问题。

一台机器不能满足，则增加两台或者多台机器，共同承担访问压力。

负载平衡最重要的一个应用是利用多台服务器提供单一服务。

项目中常用的负载均衡有四层负载均衡和七层负载均衡。

四层负载均衡与七层负载均衡

四层负载均衡：

四层负载均衡基于IP和端口的方式实现网络的负载均衡，具体实现为对外提供一个虚拟IP和端口接收所有用户的请求，然后根据负载均衡配置和负载均衡策略将请求发送给真实的服务器。

七层负载：

七层负载均衡基于URL等资源来实现应用层基于内容的负载均衡，具体实现为通过虚拟的URL或主机名接收所有用户的请求，然后将请求发送给真实的服务器。

对比

四层负载均衡和七层负载均衡的最大差别是：
四层负载均衡只能针对IP地址和端口上的数据做统一的分发，而七层负载均衡能根据消息的内容做更加详细的有针对性的负载均衡。我们通常使用LVS等技术实现基于Socket的四层负载均衡，使用Nginx等技术实现基于内容分发的七层负载均衡，比如将以“/user/***”开头的URL请求负载到单点登录服务器，而将以“/business/***”开头的URL请求负载到具体的业务服务器。

四层负载均衡：

在这里插入图片描述

七层负载均衡：

在这里插入图片描述

四层负载均衡

四层负载均衡主要通过修改报文中的目标地址和端口来实现报文的分发和负载均衡。
以TCP为例，负载均衡设备在接收到第1个来自客户端的SYN请求后，会根据负载均衡配置和负载均衡策略选择一个最佳的服务器，并将报文中的目标IP地址修改为该服务器的IP直接转发给该服务器。TCP连接的建立（即三次握手过程）是在客户端和服务器端之间完成的，负载均衡设备只起到路由器的转发功能。
四层负载均衡常用的软硬件：

F5：硬件负载均衡器，功能完备，价格昂贵。
LVS：基于IP+端口实现的四层负载软件，常和Keepalive配合使用。
Nginx：同时实现四层负载和七层负载均衡，带缓存功能，可基于正则表达式灵活转发。

七层负载均衡

七层负载均衡又叫作“内容负载均衡”，主要通过解析报文中真正有意义的应用层内容，并根据负载均衡配置和负载均衡策略选择一个最佳的服务器响应用户的请求。
七层应用负载可以使整个网络更智能化，七层负载均衡根据不同的数据类型将数据存储在不同的服务器上来提高网络整体的负载能力。比如将客户端的基本信息存储在内存较大的缓存服务器上，将文件信息存储在磁盘空间较大的文件服务器上，将图片视频存储在网络I/O能力较强的流媒体服务器上。在接收到不同的客户端的请求时从不同的服务器上获取数据并将其返回给客户端，提高客户端的访问效率。
七层负载均衡常用的软件如下：

HAProxy：支持七层代理、会话保持、标记、路径转移等。
Nginx：同时实现四层负载和七层负载均衡，在HTTP和Mail协议上功能比较好，性能与HAProxy差不多。
Apache：使用简单，性能较差。

负载均衡算法

不同的负载均衡算法适用于不同的应用场景：

轮询均衡（Round Robin）
权重轮询均衡（Weighted Round Robin）
随机均衡（Random）
权重随机均衡（Weighted Random）
响应速度均衡（Response Time）
最少连接数均衡（Least Connection）
处理能力均衡
DNS响应均衡（Flash DNS）
散列算法均衡
IP地址散列
URL散列。

轮询均衡

轮询均衡指将客户端请求轮流分配到1至N台服务器上，每台服务器均被均等地分配一定数量的客户端请求。轮询均衡算法适用于集群中所有服务器都有相同的软硬件配置和服务能力的情况下。

权重轮询均衡

权重轮询均衡指根据每台服务器的不同配置及服务能力，为每台服务器都设置不同的权重值，然后按照设置的权重值轮询地将请求分配到不同的服务器上。
例如，服务器A的权重值被设计成3，服务器B的权重值被设计成3，服务器C的权重值被设计成4，则服务器A、B、C将分别承担30%、30%、40%的客户端请求。
权重轮询均衡算法主要用于服务器配置不均等的集群中。

随机均衡

随机均衡指将来自网络的请求随机分配给内部的多台服务器，不考虑服务器的配置和负载情况。

权重随机均衡

权重随机均衡算法类似于权重轮询算法，只是在分配请求时不再轮询发送，而是随机选择某个权重的服务器发送。

响应速度均衡

负载均衡设备对内部各服务器发出一个探测请求（例如 Ping），然后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客户端的服务请求。
此种均衡算法能较好的反映服务器的当前运行状态，但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间，而不是客户端与服务器间的最快响应时间。

最少连接数均衡

最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡更加符合实际情况，负载更加均衡。
此种均衡算法适合长时处理的请求服务，如 FTP。

处理能力均衡

此种均衡算法将把服务请求分配给内部中处理负荷（根据服务器 CPU 型号、CPU 数量、内存大小
及当前连接数等换算而成）最轻的服务器，由于考虑到了内部服务器的处理能力及当前网络运行
状况，所以此种均衡算法相对来说更加精确，尤其适合运用到第七层（应用层）负载均衡的情况
下。

DNS响应均衡

在此均衡算法下，分处在不同地理位置的负载均衡设备收到同一个客户端的域名解析请求，并在同一时间内把此域名解析成各自相对应服务器的 IP 地址并返回给客户端**，则客户端将以最先收到的域名解析 IP 地址来继续请求服务，而忽略其它的 IP 地址响应**。在种均衡策略适合应用在全局负载均衡的情况下，对本地负载均衡是没有意义的。

散列算法均衡

散列算法均衡指通过一致性散列算法和虚拟节点技术将相同参数的请求总是发送到同一台服务器，该服务器将长期、稳定地为某些客户端提供服务。在某个服务器被移除或异常宕机后，该服务器的请求基于虚拟节点技术平摊到其他服务器，而不会影响集群整体的稳定性。

IP地址散列

通过管理发送方 IP 和目的地 IP 地址的散列，将来自同一发送方的分组(或发送至同一目的地的分组)统一转发到相同服务器的算法。当客户端有一系列业务需要处理而必须和一个服务器反复通信时，该算法能够以流(会话)为单位，保证来自相同客户端的通信能够一直在同一服务器中进行处理。

URL散列

通过管理客户端请求 URL 信息的散列，将发送至相同 URL 的请求转发至同一服务器的算法。

LVS的原理及应用

LVS 是什么？
LVS（Linux Virtual Server）是一个虚拟的服务器集群系统，采用IP负载均衡技术将请求均衡地转移到不同的服务器上执行，且通过调度器自动屏蔽故障服务器，从而将一组服务器构成一个高性能、高可用的虚拟服务器。整个服务器集群的结构对用户是透明的，无须修改客户端和服务器端的程序，便可实现客户端到服务器的负载均衡。
LVS 是干嘛的？

LVS 属于实现负载均衡集群的软件方案。

LVS有多种模式，在不同的模型下，LVS实现负载均衡的方式也不同。

（a）LVS NAT模式
（b）LVS DR模式
（c）LVS TUN模式
（d）LVS FULLNAT模式

LVS的原理

LVS由前端的负载均衡器（Load Balancer, LB）和后端的真实服务器（Real Server, Real Server）群组成，在真实服务器间可通过局域网或广域网连接。
LVS的这种结构对用户是透明的，用户只需要关注作为LB的虚拟服务器（Virtual Server），而不需要关注提供服务的真实服务器群。
在用户的请求被发送给虚拟服务器后，LB根据设定的包转发策略和负载均衡调度算法将用户的请求转发给真实服务器，真实服务器再将用户请求的结果返回给用户。
实现LVS的核心组件有负载均衡调度器、服务器池和共享存储。

（1）负载均衡调度器（Load Balancer/Director）：是整个集群对外提供服务的入口，通过对外提供一个虚拟IP来接收客户端请求。在客户端将请求发送到该虚拟IP后，负载均衡调度器会负责将请求按照负载均衡策略发送到一组具体的服务器上。
（2）服务器池（Server Pool）：服务器池是一组真正处理客户端请求的真实服务器，具体执行的服务有WEB、MAIL、FTP和DNS等。
（3）共享存储（Shared Storage）：为服务器池提供一个共享的存储区，使得服务器池拥有相同的内容，提供相同的服务。
在接收LVS内部数据的转发流程前，这里先以表6-3介绍LVS技术中常用的一些名词，以让我们更好地理解LVS的工作原理。

LVS技术中常用的一些名词：

缩写	名称	说明
CIP	客服端IP（Client IP Address）	用户记录发送给集群的源IP地址
VIP	虚拟IP（Virtual IP Address）	用于Director对外提供服务的IP地址
DIP	Director IP	Director用于连接内外网络的IP地址，即负载均衡器上的IP地址
RIP	真实IP（Real Server的IP Address）	集群中真实服务器的物理 IP 地址
LIP	LVS内部IP（Local IP Address）	LVS集群的内部通信IP

LVS的IP负载均衡技术是通过IPVS模块实现的。IPVS是LVS集群系统的核心软件，被安装在Director Server上，同时在Director Server上虚拟出一个IP地址。用户通过这个虚拟的IP地址访问服务器。这个虚拟的IP地址一般被称为LVS的VIP，即Virtual IP。访问的请求首先经过VIP到达负载调度器，然后由负载调度器从真实服务器列表中选取一个服务节点响应用户的请求。

LVS数据转发

LVS的数据转发流程是LVS设计的核心部分：
在这里插入图片描述
（1）PREROUTING链接收用户请求：客户端向PREROUTING链发送请求。
（2）INPUT链转发：在PREROUTING链通过RouteTable列表发现请求数据包的目的地址是本机时，将数据包发送给INPUT链。
（3）IPVS检查：IPVS检查INPUT链上的数据包，如果数据包中的目的地址和端口不在规则列表中，则将该数据包发送到用户空间的ipvsadm。ipvsadm主要用于用户定义和管理集群。
（4）POSTROUTING链转发：如果数据包里面的目的地址和端口都在规则里面，那么将该数据包中的目的地址修改为事先定义好的真实服务器地址，通过FORWARD将数据发送到POSTROUTING链。
（5）真实服务器转发：POSTROUTING链根据数据包中的目的地址将数据包转发到真实服务器。

LVS NAT模式

NAT模式通过对请求报文和响应报文的地址进行改写完成对数据的转发。
实现流图：

缩写	名称	说明
CIP	客服端IP（Client IP Address）	用户记录发送给集群的源IP地址
VIP	虚拟IP（Virtual IP Address）	用于Director对外提供服务的IP地址
DIP	Director IP	Director用于连接内外网络的IP地址，即负载均衡器上的IP地址
RIP	真实IP（Real Server的IP Address）	集群中真实服务器的物理 IP 地址

（1）客户端将请求报文发送到LVS，请求报文的源地址是CIP（Client IP Address，客户端IP），目标地址是VIP（Virtual IP Address，虚拟IP）。
（2）LVS在收到报文后，发现请求的IP地址在LVS的规则列表中存在，则将客户端请求报文的目标地址VIP修改为RIP（Real-server IP Address，后端服务器的真实IP），并将报文发送到具体的真实服务器上。
（3）真实服务器在收到报文后，由于报文的目标地址是自己的IP，所以会响应该请求，并将响应报文返回给LVS。
（4）LVS在收到数据后将此报文的源地址修改为本机IP地址，即VIP，并将报文发送给客户端。

NAT模式特点：

1）NAT 技术将请求的报文和响应的报文都需要通过 LB 进行地址改写，因此网站访问量比较大的时候 LB 负载均衡调度器有比较大的瓶颈，一般要求最多之能 10-20 台节点
2）只需要在 LB 上配置一个公网 IP 地址就可以了。
3）每台内部的 real server 服务器的网关地址必须是调度器 LB 的内网地址。
4）NAT 模式支持对 IP 地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。

NAT模式的优点：

集群中的物理服务器可以使用任何支持 TCP/IP 操作系统，只有负载均衡器需要一个合法的 IP 地址。

NAT模式的缺点：

扩展性有限。当服务器节点（普通 PC 服务器）增长过多时,负载均衡器将成为整个系统的瓶颈，因为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时，大量的数据包都交汇在负载均衡器那，速度就会变慢！

LVS DR模式

LVS DR（Direct Routing）模式用直接路由技术实现，通过改写请求报文的MAC地址将请求发送给真实服务器。
LVD DR模式是局域网中经常被用到的一种模式。
实现流图：

在这里插入图片描述
（1）客户端将请求发送给LVS，请求报文的源地址是CIP，目标地址是VIP。
（2）LVS在收到报文后，发现请求在规则中存在，则将客户端请求报文的源MAC地址改为自己的DIP（Direct IP Address，内部转发IP）的MAC地址，将目标MAC改为RIP的MAC地址，并将此包发送给真实服务器。
（3）真实服务器在收到请求后发现请求报文中的目标MAC是自己，就会将此报文接收下来，在处理完请求报文后，将响应报文通过lo（回环路由）接口发送给eth0网卡，并最终发送给客户端。

注意：需要设置 lo 接口的 VIP 不能响应本地网络内的 arp 请求。

总结：

1）通过在调度器 LB 上修改数据包的目的 MAC 地址实现转发。注意源地址仍然是 CIP，目的地址仍然是 VIP 地址。
2）请求的报文经过调度器，而 Real Server 响应处理后的报文无需经过调度器 LB，因此并发访问量大时使用效率很高（和 NAT 模式比）。
3）因为 DR 模式是通过 MAC 地址改写机制实现转发，因此所有 Real Server 节点和调度器 LB 只能在一个局域网里面。
4）Real Server 主机需要绑定 VIP 地址在 LO 接口（掩码 32 位）上，并且需要配置 ARP 抑制。
5）Real Server 节点的默认网关不需要配置成 LB，而是直接配置为上级路由的网关，能让 Real Server 直接出网就可以。
6）由于 DR 模式的调度器仅做 MAC 地址的改写，所以调度器 LB 就不能改写目标端口，那么 Real Server 服务器就得使用和 VIP 相同的端口提供服务。
7）直接对外的业务比如 WEB 等，Real Server 的 IP 最好是使用公网 IP。对外的服务，比如数据库等最好使用内网 IP。

DR模式优点：
1）和 TUN（隧道模式）一样，负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户端。与 VS-TUN 相比，VS-DR 这种实现方式不需要隧道结构，因此可以使用大多数操作系统做为物理服务器。
2）DR 模式的效率很高，但是配置稍微复杂一点，因此对于访问量不是特别大的公司可以用haproxy/nginx取代。日1000-2000W PV或者并发请求1万一下都可以考虑用haproxy/nginx。
DR模式缺点：
所有 Real Server 节点和调度器 LB 只能在一个局域网里面。

LVS TUN模式

TUN（IP Tunneling）通过IP隧道技术实现。
LVS TUN模式常用于跨网段或跨机房的负载均衡。
报文转发流程：

在这里插入图片描述
（1）客户端将请求发送给前端的LVS，请求报文的源地址是CIP，目标地址是VIP。
（2）LVS在收到报文后，发现请求在规则里中存在，则将在客户端请求报文的首部再封装一层IP报文，将源地址改为DIP，将目标地址改为RIP，并将此包发送给真实服务器。
（3）真实服务器在收到请求报文后会先拆开第1层封装，因为发现里面还有一层IP首部的目标地址是自己lo接口上的VIP，所以会处理该请求报文，并将响应报文通过lo接口发送给eth0网卡，并最终发送给客户端。
注意：需要设置 lo 接口的 VIP 不能在共网上出现。

总结：
1）TUNNEL 模式必须在所有的 Real Server 机器上面绑定 VIP 的 IP 地址
2）TUNNEL 模式的 vip ------>Real Server 的包通信通过 TUNNEL 模式，不管是内网和外网都能通信，所以不需要 lvs vip 跟 Real Server 在同一个网段内。
3）TUNNEL 模式 Real Server 会把 packet 直接发给 client 不会给 lvs 了
4）TUNNEL 模式走的隧道模式，所以运维起来比较难，所以一般不用。
TUN模式优点：

负载均衡器只负责将请求包分发给后端节点服务器，而 Real Server 将应答包直接发给用户。所以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的请求量，这种方式，一台负载均衡器能够为很多 Real Server 进行分发。而且跑在公网上就能进行不同地域的分发。

缺点：
隧道模式的 Real Server 节点需要合法 IP，这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议，服务器可能只局限在部分 Linux 系统上。

LVS FULLNAT模式

无论是DR模式还是NAT模式，都要求LVS和真实服务器在同一个VLAN下，否则LVS无法作为真实服务器的网关，因此跨VLAN的真实服务器无法接入。同时，在流量增大、真实服务器水平扩容时，单点LVS会成为瓶颈。
FULLNAT能够很好地解决LVS和真实服务器跨VLAN的问题，在跨VLAN问题解决后，LVS和真实服务器不再存在VLAN上的从属关系，可以做到多个LVS对应多个真实服务器，解决水平扩容的问题
FULLNAT的原理是在NAT的基础上引入Local Address IP（内网IP地址），将CIP→VIP转换为LIP→RIP，而LIP和RIP均为IDC内网IP，可以通过交换机实现跨VLAN通信
FULLNAT的具体实现流程：

在这里插入图片描述
（1）客户端将请求发送给LVS的DNAT，请求报文的源地址是CIP，目标地址是VIP。
（2）LVS在收到数据后将源地址CIP修改成LIP（Local IP Address, LVS的内网IP），将目标地址VIP修改为RIP，并将数据发送到真实服务器。多个LIP在同一个IDC数据中心，可以通过交换机跨VLAN通信。
（3）真实服务器在收到数据包并处理完成后，将目标地址修改为LIP，将源地址修改为RIP，最终将这个数据包返回给LVS。
（4）LVS在收到数据包后，将数据包中的目标地址修改为CIP，将源地址修改为VIP，并将数据发送给客户端。

FULLNAT 主要的思想是把网关和其下机器的通信，改为了普通的网络通信，从而解决了跨 VLAN 的问题。采用这种方式，LVS 和 RS 的部署在 VLAN 上将不再有任何限制，大大提高了运维部署的便利性。

Keepalive

Keepalive 起初是为 LVS 设计的，专门用来监控 LVS 各个服务节点的状态，后来加入了 VRRP 的功能，因此除了 LVS，也可以作为其他服务（nginx，haproxy）的高可用软件。
VRRP 是 virtual router redundancy protocal（虚拟路由器冗余协议）的缩写。VRRP 的出现就是为了解决静态路由出现的单点故障，它能够保证网络可以不间断的稳定的运行。所以 Keepalive 一方面具有 LVS cluster node healthcheck 功能，另一方面也具有 LVS director failover。

Nginx反向代理与负载均衡

一般的负载均衡软件如LVS实现的功能只是对请求数据包的转发和传递，从负载均衡下的节点服务器来看，接收到的请求还是来自访问负载均衡器的客户端的真实用户；而反向代理服务器在接收到用户的访问请求后，会代理用户重新向节点服务器（Web服务器、文件服务器、视频服务器）发起请求，反向代理服务器和节点服务器做具体的数据交互，最后把数据返回给客户端用户。
在节点服务器看来，访问的节点服务器的客户端就是反向代理服务器，而非真实的网站访问用户，具体原理如图：

在这里插入图片描述

upstream_module

ngx_http_upstream_module 是负载均衡模块，可以实现网站的负载均衡功能即节点的健康检查，upstream 模块允许 Nginx 定义一组或多组节点服务器组，使用时可通过 proxy_pass 代理方式把网站的请求发送到事先定义好的对应 Upstream 组的名字上。
常用的upstream配置如下：

upstream 模块内参数	参数说明
weight	服务器权重
max_fails	Nginx 尝试连接后端主机失败的此时，这是值是配合 proxy_next_upstream、fastcgi_next_upstream 和 memcached_next_upstream 这三个参数来使用的。当 Nginx接收后端服务器返回这三个参数定义的状态码时，会将这个请求转发给正常工作的的后端服务器。如 404、503、503,max_files=1
fail_timeout	max_fails 和 fail_timeout 一般会关联使用，如果某台 server 在 fail_timeout 时间内出现了max_fails 次连接失败，那么 Nginx 会认为其已经挂掉，从而在 fail_timeout 时间内不再去请求它，fail_timeout 默认是 10s，max_fails 默认是 1，即默认情况只要是发生错误就认为服务器挂了，如果将 max_fails 设置为 0，则表示取消这项检查
backup	表示当前 server 是备用服务器，只有其它非 backup 后端服务器都挂掉了或很忙才会分配请求给它
down	标志服务器永远不可用，可配合 ip_hash 使用

具体的upstream定义如下：

 upstream lvsServer{
 server 191.168.1.11 weight=5 ;
 server 191.168.1.22:82;
 server example.com:8080 max_fails=2 fail_timeout=10s backup;
 #域名的话需要解析的哦，内网记得 hosts
}

proxy_pass

proxy_pass 指令属于 ngx_http_proxy_module 模块，此模块可以将请求转发到另一台服务器，在实际的反向代理工作中，会通过 location 功能匹配指定的 URI，然后把接收到服务匹配 URI 的请求通过 proyx_pass 抛给定义好的 upstream 节点池。
具体的proxy_pass定义：

location /download/ {
 proxy_pass http://192.168.1.13:9000/download/vedio/;
}
#这是前端代理节点的设置
#交给后端 upstream 为 download 的节点

如上代码定义了一个download的反向代理，在客户端请求/download时，Nginx会将具体的请求转发给proxy_pass配置的地址处理请求，这里配置的地址是http://192.168.1.13:9000/download/vedio/。

常用的proxy_pass配置

proxy模块参数	说明
proxy_next_upstream	什么情况下将请求传递到下一个 upstream
proxy_limite_rate	限制从后端服务器读取响应的速率
proyx_set_header	设置 http 请求 header 传给后端服务器节点，如：可实现让代理后端的服务器节点获取访问客户端的这是 ip
client_body_buffer_size	客户端请求主体缓冲区大小
proxy_connect_timeout	代理与后端节点服务器连接的超时时间
proxy_send_timeout	后端节点数据回传的超时时间
proxy_read_timeout	设置 Nginx 从代理的后端服务器获取信息的时间，表示连接成功建立后，Nginx 等待后端服务器的响应时间
proxy_buffer_size	设置缓冲区大小
proxy_buffers	设置缓冲区的数量和大小
proyx_busy_buffers_size	用于设置系统很忙时可以使用的 proxy_buffers 大小，推荐为proxy_buffers*2
proxy_temp_file_write_size	指定 proxy 缓存临时文件的大小