| 作者：江夏
| 知乎：https://www.zhihu.com/people/1024-paper-96
| GitHub：https://github.com/JiangXia-1024?tab=repositories
| 博客地址：https://blog.csdn.net/qq_41153943
| 掘金：https://juejin.cn/post/6986279448853086216
| 公众号：1024笔记
本文大概11088字,读完共需25分钟
什么是负载均衡
负载均衡（Load balance，LB），是一种计算机技术，用来在多个计算机（计算机集群）、网络连接、CPU、磁盘驱动器或其他资源中分配负载，以达到最优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。
通俗点理解有点类似于常说的一句话，一碗水端平。如果我们只有一个碗，那么无论有多少水，那么我们只能装一碗水。在单服务器的应用场景，碗就是服务器，而水就是流量。所以我们知道，一旦水（流量）过大时，一个碗肯定是不够用的。这时候就需要多来几个碗（服务器）来支撑更多的水（流量）。但是不能让这个碗接的水满满的，而有的碗没有水，或者水少，水就是负载，而这种就是负载不均衡了。负载均衡就是为了让所有碗里的水都尽量一样多，不至于让有的服务器压力大，而有的服务器压力小甚至用不上。
那么我们知道尽管有很多的碗，能够装得下足够多的水，但是这么多碗，哪个先用，哪个后用呢？这时候我们可以想象以前读书的时候的洗衣池，一个池子上面有n个水龙头，这时候每个水龙头下都放这一个碗，这样就能够保证这些碗基本是同时被使用到的，而这种就是分布式服务器集群的基本概念了。
那么这些碗如何能够达到负载均衡呢？因为会有有得水龙头流量大，有得水龙头流量小的情况，这样的话流量大的地方的碗的负载压力就大。那么这时候，如果我们把所有的碗都打通，然后再用一个水管把他们连起来，这样是不是就能够基本保证，所有的碗的水都一样多了？因为水多的碗里面的水也很流到水少的碗里。这样就能够达到负载均衡的目的了。这里面用来连接碗之间的水管就是连通器的概念，但是连通器其实只是用于解决服务器之间的通信问题，其并不是减轻服务器性能的算法。负载均衡就是通过分流算法，合理的分摊服务器压力，达到服务器性能的最大优化。但是这里也不能简单地理解为分配给所有实际服务器一样多的工作量，因为不同的服务器在硬件配置、网络带宽的不同，导致它们具体的承载能力也不相同，这里的“均衡”，其实就是尽可能地使得所有的服务器都不要过载，并且能够最大程序地发挥作用。
总结：负载均衡（Load Balance），就是是将负载（工作任务，访问请求）进行平衡、分摊到多个操作单元（服务器，组件）上进行执行，用来解决高性能，单点故障（高可用），扩展性（水平伸缩）的场景需求！
几种常见的负载均衡方案
1、HTTP重定向
当我们向web服务器发送一个请求后，web服务器可以通过http响应头信息中的Location标记来返回一个新的URL，然后浏览器需要继续请求这个新的URL，完成自动跳转。
HTTP重定向协议实现负载均衡大概工作原理如下图：
HTTP重定向服务器是一台普通的应用服务器，其唯一个功能就是根据用户的HTTP请求计算出一台真实的服务器地址，并将该服务器地址写入HTTP重定向响应中（重定向响应状态码为302）返回给用户浏览器。用户浏览器在获取到响应之后，根据返回的信息，重新发送一个请求到真实的服务器上。如上图所示，当用户请求访问某个网址，通过DNS服务器解析到IP地址为10.100.1.100，即HTTP重定向服务器的IP地址。然后重定向服务器根据负载均衡算法算出真实的服务器地址为10.100.1.104并返回给用户浏览器，用户浏览器得到返回后重新对10.100.1.104发起了请求，完成自动跳转。
这种 HTTP重定向负载均衡方案的优点是比较简单，但是也存在一些缺点：
1、性能较差
浏览器需要请求两次才能完成一次访问。同时，重定向服务器本身的处理能力有可能成为瓶颈，整个集群的伸缩性规模有限；使用HTTP返回码302重定向，有可能使搜索引擎判断为SEO作弊，降低搜索排名。
2、吞吐率限制
主站点服务器的吞吐率平均分配到了被转移的服务器。现假设使用RR（Round Robin）调度策略，子服务器的最大吞吐率为1000reqs/s，那么主服务器的吞吐率要达到3000reqs/s才能完全发挥三台子服务器的作用，那么如果有100台子服务器，那么主服务器的吞吐率可想而知得有大？相反，如果主服务的最大吞吐率为6000reqs/s，那么平均分配到子服务器的吞吐率为2000reqs/s，而现子服务器的最大吞吐率为1000reqs/s，因此就得增加子服务器的数量，增加到6个才能满足。
3、重定向访问深度不同
有的重定向一个静态页面，有的重定向相比复杂的动态页面，那么实际服务器的负载差异是不可预料的，而主站服务器却一无所知。因此整站使用重定向方法做负载均衡不太好。
需要权衡转移请求的开销和处理实际请求的开销，前者相对于后者越小，那么重定向的意义就越大，例如下载。你可以去很多镜像下载网站试下，会发现基本下载都使用了Location做了重定向。
因此在实际应用中很少使用这种负载均衡方案来部署。
2、DNS负载均衡
DNS（Domain Name System）是因特网的一项服务，它作为域名和IP地址相互映射的一个分布式数据库，能够使人更方便的访问互联网。DNS负责提供域名解析服务，当访问某个站点时，实际上首先需要通过该站点域名的DNS服务器来获取域名指向的IP地址，在这一过程中，DNS服务器完成了域名到IP地址的映射，同样，这样映射也可以是一对多的，这时候，DNS服务器便充当了负载均衡调度器，它就像http重定向转换策略一样，将用户的请求分散到多台服务器上，但是它的实现机制完全不同。
利用DNS工作原理处理负载均衡的工作原理图大致如下：
在DNS系统中有一个比较重要的的资源类型叫做主机记录也称为A记录，A记录是用于名称解析的重要记录，它将特定的主机名映射到对应主机的IP地址上。如果你有一个自己的域名，那么要想别人能访问到你的网站，你需要到特定的DNS解析服务商的服务器上填写A记录，过一段时间后，别人就能通过你的域名访问你的网站了。
通过上面的原理图可以看出，在DNS服务器中应该配置了多个A记录，如：
www.1024.com IN A 10.100.1.101;
www.1024.com IN A 10.100.1.102;
www.1024.com IN A 10.100.1.103;
www.1024.com IN A 10.100.1.104;
因此，每次域名解析请求都会根据对应的负载均衡算法计算出一个不同的IP地址并返回，这样A记录中配置多个服务器就可以构成一个集群，并可以实现负载均衡。上图中，用户请求www.1024.com，DNS根据A记录和负载均衡算法计算得到一个IP地址10.100.1.104，并返回给浏览器，浏览器根据该IP地址，访问真实的物理服务器10.100.1.104。所有这些操作对用户来说都是透明的，用户可能只知道www.1024.com这个域名。
基于DNS负载均衡和http重定向的负载均衡相比，它完全节省了所谓的主站点，也可以说DNS服务器充当了主站点。但不同的是，作为调度器，DNS服务器本身的性能是足够的。因为DNS记录可以被用户浏览器或者互联网接入服务商的各级DNS服务器缓存，只有当缓存过期后才会重新向域名的DNS服务器请求解析。也就是说DNS不存在上面说到的http重定向的吞吐率限制，在理论上是可以无限增加实际服务器的数量。
DNS域名解析负载均衡具有以下的一些优点：
1、将负载均衡的工作交给DNS，省去了网站管理维护负载均衡服务器的麻烦。
2、技术实现比较灵活、方便，简单易行，成本低，使用于大多数TCP/IP应用。
3、对于部署在服务器上的应用来说不需要进行任何的代码修改即可实现不同机器上的应用访问。
4、服务器可以位于互联网的任意位置。
5、同时许多DNS还支持基于地理位置的域名解析，即会将域名解析成距离用户地理最近的一个服务器地址，这样就可以加速用户访问，改善性能。
但是它也有一定的缺点，比如：
1、动态DNS：在每次IP地址变更时，需要及时更新DNS服务器。但是因为缓存，所以存在一定的延迟。
2、策略的局限性。如果无法将HTTP请求的上下文引入到调度策略中，而在前面介绍的基于HTTP重定向的负载均衡系统中，调度器工作在HTTP层面，它可以充分理解HTTP请求后根据站点的应用逻辑来设计调度策略，比如根据请求不同的URL来进行合理的过滤和转移。
3、如果要根据实际服务器的实时负载差异来调整调度策略，这需要DNS服务器在每次解析操作时分析各服务器的健康状态，对于DNS服务器来说，这种自定义开发存在较高的门槛，更何况大多数站点只是使用第三方DNS服务。
4、DNS记录缓存，各级节点的DNS服务器不同程序的缓存会让人很难弄清楚。
5、没有用户能直接看到DNS解析到了哪一台实际服务器，给服务器运维人员的调试带来了不便。
6、不能够按服务器的处理能力来分配负载。DNS负载均衡采用的是简单的轮询算法，不能区分服务器之间的差异，不能反映服务器当前运行状态，所以其的负载均衡效果并不是太好。
其实大型网站总是部分使用DNS域名解析，将其作为第一级负载均衡手段，即通过域名解析得到的一组服务器并不是实际提供服务的物理服务器，而是同样提供负载均衡服务器的内部服务器，这组内部负载均衡服务器再进行负载均衡，请请求发到真实的服务器上，最终完成请求。
基于以上几点，DNS服务器并不能很好地完成工作量均衡分配，所以是否选择基于DNS的负载均衡方式取决于实际场景和业务的需要。
三、反向代理负载均衡
反向代理（Reverse Proxy）应该是平常听到最多的了，因为几乎所有主流的Web服务器都热衷于支持基于反向代理的负载均衡。它的核心工作就是转发HTTP请求。
有反向代理肯定就有正向代理，在说反向代理之前先来说说正向代理。
这里的代理可以理解为就是一个代表、一个渠道。正向代理是针对客户端而言的。客户端想访问一个网站，但上不了网，可是客户端却能访问一个叫做代理服务器的东西，代理服务器可以帮助客户端上网。客户端先将请求发给代理服务器，代理服务器再将请求转发给网站，网站的响应结果先发给代理服务器，然后再由代理服务器转发给客户端。
可以理解正向代理就是指代理服务器帮助客户端上网。
随着网站业务不断发展，用户规模越来越大，由于复杂的网络环境，不同地区的用户访问网站时，速度差别也极大。有研究表明，网站访问延迟和用户流失率正相关，网站访问越慢，用户越容易失去耐心而离开。为了提供更好的用户体验，留住用户，网站需要加速网站访问速度。其中一个方法就是加反向代理服务器。
传统代理服务器位于浏览器一侧，代理浏览器将HTTP请求发送到互联网上，而反向代理服务器位于网站机房一侧，代理网站Web服务器接收HTTP请求。和传统代理服务器可以保护浏览器安全一样，反向代理服务器也具有保护网站安全的作用，来自互联网的访问请求必须经过代理服务器，相当于在Web服务器和可能的网络攻击之间建立了一个屏障。
除了安全功能，代理服务器也可以通过配置缓存功能加速Web请求。当用户第一次访问静态内容的时候，静态内容就被缓存在反向代理服务器上，这样当其他用户访问该静态内容的时候，就可以直接从反向代理服务器返回，加速Web请求响应速度，减轻Web服务器负载压力。
事实上，有些网站会把动态内容也缓存在代理服务器上，比如维基百科及某些博客论坛网站，把热门词条、帖子、博客缓存在代理服务器上加速用户访问速度，当这些动态内容有变化时，通过内部通知机制通知反向代理缓存失效，反向代理会重新加载最新的动态内容再次缓存起来。
此外，反向代理也可以实现负载均衡的功能，而通过负载均衡构建的应用集群可以提高系统总体处理能力，进而改善网站高并发情况下的性能。
相比前面的HTTP重定向和DNS解析，反向代理的调度器扮演的是用户和实际服务器中间人的角色：反向代理方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。
1、任何对于实际服务器的HTTP请求都必须经过调度器
2、调度器必须等待实际服务器的HTTP响应，并将它反馈给用户（前两种方式不需要经过调度反馈，是实际服务器直接发送给用户）
特性：
1、调度策略丰富。例如可以为不同的实际服务器设置不同的权重，以达到能者多劳的效果。
2、对反向代理服务器的并发处理能力要求高，因为它工作在HTTP层面。
3、反向代理服务器进行转发操作本身是需要一定开销的，比如创建线程、与后端服务器建立TCP连接、接收后端服务器返回的处理结果、分析HTTP头部信息、用户空间和内核空间的频繁切换等，虽然这部分时间并不长，但是当后端服务器处理请求的时间非常短时，转发的开销就显得尤为突出。例如请求静态文件，更适合使用前面介绍的基于DNS的负载均衡方式。
4、反向代理服务器可以监控后端服务器，比如系统负载、响应时间、是否可用、TCP连接数、流量等，从而根据这些数据调整负载均衡的策略。
5、反射代理服务器可以让用户在一次会话周期内的所有请求始终转发到一台特定的后端服务器（粘滞会话），这样的好处一是保持session的本地访问，二是防止后端服务器的动态内存缓存的资源浪费。
Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器。
官方网站下载地址：
https://nginx.org/en/download.html
选择合适版本下载
下载后解压，双击nginx.exe文件即可启动nginx。
启动后浏览器输入：
http://localhost
出现以下页面，则nginx启动成功
或者进入nginx解压的目录，输入命令行：nginx也可以启动nginx。
停止nginx有两种方式：
命令行进入nginx根目录，执行如下命令，停止服务器：
# 强制停止nginx服务器，如果有未处理的数据，丢弃
E:\nginx\nginx-1.20.1>nginx -s stop
#如果有未处理的数据，等待处理完成之后停止
E:\nginx\nginx-1.20.1>nginx -s quit
nginx服务器的配置信息主要集中在nginx.conf这个配置文件中。
该文件主要由6个部分组成：
main：用于进行nginx全局信息的配置
events：用于nginx工作模式的配置
http：用于进行http协议信息的一些配置
server：用于进行服务器访问信息的配置
location：用于进行访问路由的配置
upstream：用于进行负载均衡的配置
篇幅有限，其具体的使用以及配置，这里暂时先不说明。
LVS-Linux Virtual Server
还有三种负载均衡，在介绍这三种负载均衡之前先聊一下**LVS。**因为这三种负载均衡模式都是和LVS有关。
LVS（Linux Virtual Server），即Linux虚拟服务器，它是由章文嵩博士主导的开源负载均衡项目，目前LVS已经被集成到Linux内核模块中。
从Linux2.4内核开始，其内置的Netfilter模块在内核中维护着一些数据包过滤表，这些表包含了用于控制数据包过滤的规则。可喜的是，Linux提供了iptables来对过滤表进行插入、修改和删除等操作。更加令人振奋的是，Linux2.6.x内核中内置了IPVS模块，它的工作性质类型于Netfilter模块，不过它更专注于实现IP负载均衡。IPVS的管理工具是ipvsadm，它为提供了基于命令行的配置界面，可以通过它快速实现负载均衡系统。这就是LVS。
该项目在Linux内核中实现了基于IP的数据请求负载均衡调度方案，其体系结构如下图所示：
通过上图可以发现终端互联网用户从外部访问公司的外部负载均衡服务器，终端用户的请求会发送给LVS调度器，调度器根据自己预设的算法决定将该请求发送给后端的某台Web服务器，比如，轮询算法可以将外部的请求平均分发给后端的所有服务器，终端用户访问LVS调度器虽然会被转发到后端真实的服务器，但如果真实服务器连接的是相同的存储，提供的服务也是相同的服务，最终用户不管是访问哪台真实服务器，得到的服务内容都是一样的，整个集群对用户而言都是透明的。最后根据LVS工作模式的不同，真实服务器会选择不同的方式将用户需要的数据发送到终端用户，LVS根据工作模式的不同可以分为LVS-NAT模式（IP负载均衡）、LVS-TUN模式（IP隧道）、以及LVS-DR模式（直接路由）。
四、IP负载均衡(LVS-NAT)
NAT（Network Address Translation）即网络地址转换，其作用是通过数据报头的修改，使得位于企业内部的私有IP地址可以访问外网，以及外部用用户可以访问位于公司内部的私有IP主机。
因为反向代理服务器工作在HTTP层，其本身的开销就已经严重制约了可扩展性，从而也限制了它的性能极限。而NAT服务器:它工作在传输层，它可以修改发送来的IP数据包，将数据包的目标地址修改为实际服务器地址。其原理如下图：
由上图可知LVS负载调度器可以使用两块网卡配置不同的IP地址，eth0设置为私钥IP与内部网络通过交换设备相互连接，eth1设备为外网IP与外部网络联通。
用户通过互联网DNS服务器解析到公司负载均衡设备上面的外网地址，相对于真实服务器而言，LVS外网IP又称VIP（Virtual IP Address），用户通过访问VIP，即可连接后端的真实服务器（Real Server），而这一切对用户而言都是透明的，用户以为自己访问的就是真实服务器，但他并不知道自己访问的VIP仅仅是一个调度器，也不清楚后端的真实服务器到底在哪里、有多少真实服务器。
用户将请求发送至10.100.147.168，此时LVS将根据预设的算法选择后端的一台真实服务器（10.100.0.101~10.100.0.103），将数据请求包转发给真实服务器，并且在转发之前LVS会修改数据包中的目标地址以及目标端口，目标地址与目标端口将被修改为选出的真实服务器IP地址以及相应的端口。
最后真实的服务器将响应数据包返回给LVS调度器，调度器在得到响应的数据包后会将源地址和源端口修改为VIP及调度器相应的端口，修改完成后，由调度器将响应数据包发送回终端用户，另外，由于LVS调度器有一个连接Hash表，该表中会记录连接请求及转发信息，当同一个连接的下一个数据包发送给调度器时，从该Hash表中可以直接找到之前的连接记录，并根据记录信息选出相同的真实服务器及端口信息。
具体使用：
1、打开调度器的数据包转发选项
echo 1 > /proc/sys/net/ipv4/ip_forward
2、检查实际服务器是否已经将NAT服务器作为自己的默认网关，如果不是，如添加
route add default gw xx.xx.xx.xx
3、使用ipvsadm配置
ipvsadm -A -t 111.11.11.11:80 -s rr
添加一台虚拟服务器，-t 后面是服务器的外网ip和端口，-s rr是指采用简单轮询的RR调度策略（这属于静态调度策略，除此之外，LVS还提供了系列的动态调度策略，比如最小连接（LC）、带权重的最小连接（WLC），最短期望时间延迟（SED）等，关于LVS的调度算法最后会具体介绍）
ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.210:8000 -m
ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.211:8000 -m
添加两台实际服务器（不需要有外网ip），-r后面是实际服务器的内网ip和端口，-m表示采用NAT方式来转发数据包
运行
ipvsadm -L -n
可以查看实际服务器的状态。这样就大功告成了。
实验证明使用基于NAT的负载均衡方案。作为调度器的NAT服务器可以将吞吐率提升到一个新的高度，几乎是反向代理服务器的两倍以上，这大多归功于在内核中进行请求转发的较低开销。但是一旦请求的内容过大时，不论是基于反向代理还是NAT，负载均衡的整体吞吐量都差距不大，这说明对于一些开销较大的内容，使用简单的反向代理来搭建负载均衡系统是值考虑的。
这么强大的系统还是有它的瓶颈，那就是NAT服务器的网络带宽，包括内部网络和外部网络。当然如果你不差钱，可以去花钱去购买千兆交换机或万兆交换机，甚至负载均衡硬件设备，但是该方案花销较大。除此之外还有一个简单有效的办法就是将基于NAT的集群和前面的DNS混合使用，比如５个100Mbps出口宽带的集群，然后通过DNS来将用户请求均衡地指向这些集群，同时，你还可以利用DNS智能解析实现地域就近访问。这样的配置对于大多数业务是足够了，但是对于提供下载或视频等服务的大规模站点，NAT服务器还是不够出色。
五、直接路由(LVS-DR)
上面介绍的NAT是工作在网络分层模型的传输层（第四层），而直接路由是工作在数据链路层（第二层）。它通过修改数据包的目标MAC地址（没有修改目标IP），将数据包转发到实际服务器上，不同的是，实际服务器的响应数据包将直接发送给客户端，而不经过调度器。
在LVS（TUN）模式下，由于需要在LVS调度器与真实服务器之间创建隧道连接，这同样会增加服务器的负担。在直接路由模式中LVS依然仅承担数据的入站请求以及根据算法选出合理的真实服务器，最终由后端真实服务器负责将响应数据包发送返回给客户端。与隧道模式不同的是，直接路由模式要求调度器与后端服务器必须在同一个局域网内，VIP地址需要在调度器与后端所有的服务器间共享，因为最终的真实服务器给客户端回应数据包时需要设置源IP为VIP地址，目标IP为客户端IP，这样客户端访问的是调度器的VIP地址，回应的源地址也依然是该VIP地址（真实服务器上的VIP），客户端是感觉不到后端服务器存在的。由于多台计算机都设置了同样一个VIP地址，所以在直接路由模式中要求调度器的VIP地址是对外可见的，客户端需要将请求数据包发送到调度器主机，而所有的真实服务器的VIP地址必须配置在Non-ARP的网络设备上，也就是该网络设备并不会向外广播自己的MAC及对应的IP地址，真实服务器的VIP对外界是不可见的，但真实服务器却可以接受目标地址VIP的网络请求，并在回应数据包时将源地址设置为该VIP地址。调度器根据算法在选出真实服务器后，在不修改数据报文的情况下，将数据帧的MAC地址修改为选出的真实服务器的MAC地址，通过交换机将该数据帧发给真实服务器。整个过程中，真实服务器的VIP不需要对外界可见。
1、网络设置
假设由一台负载均衡调度器，两台实际服务器，购买三个外网ip，一台机一个，三台机的默认网关需要相同，最后再设置同样的ip别名，这里假设别名为10.10.120.193。这样一来，将通过10.10.120.193这个IP别名来访问调度器，你可以将站点的域名指向这个IP别名。
2、将ip别名添加到回环接口上
这是为了让实际服务器不要去寻找其他拥有这个IP别名的服务器，在实际服务器中运行：
另外还要防止实际服务器响应来自网络中针对IP别名的ARP广播，为此还要执行：
echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce
echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore
echo "1" > /proc/sys/net/ipv4/conf/all/arp_announce
配置完了就可以使用ipvsadm配置LVS-DR集群了
ipvsadm -A -t 10.10.120.193:80 -s rr
ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.210:8000 -g
ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.211:8000 -g
-g 就意味着使用直接路由的方式转发数据包
LVS-DR 相较于LVS-NAT的最大优势在于LVS-DR不受调度器宽带的限制，例如假设三台服务器在WAN交换机出口宽带都限制为10Mbps，只要对于连接调度器和两台实际服务器的LAN交换机没有限速，那么，使用LVS-DR理论上可以达到20Mbps的最大出口宽带，因为它的实际服务器的响应数据包可以不经过调度器而直接发往用户端啊，所以它与调度器的出口宽带没有关系，只能自身的有关系。而如果使用LVS-NAT，集群只能最大使用10Mbps的宽带。所以，越是响应数据包远远超过请求数据包的服务，就越应该降低调度器转移请求的开销，也就越能提高整体的扩展能力，最终也就越依赖于WAN出口宽带。
总的来说，LVS-DR适合搭建可扩展的负载均衡系统，不论是Web服务器还是文件服务器，以及视频服务器，它都拥有出色的性能。前提是你必须为服务器购买一系列的合法IP地址。
六、IP隧道(LVS-TUN)
在LVS（NAT）模式的集群环境中，由于所有的数据请求及响应的数据包都需要经过LVS调度器转发，如果后端服务器的数量大于10台，则调度器就会成为整个集群环境的瓶颈。因为响应数据包中包含有客户需要的具体数据，所以数据请求包往往远小于响应数据包的大小所以LVS-TUN模式就是将请求与响应数据分离，让调度器仅处理数据请求，而让真实服务器响应数据包直接返回给客户端。
基于IP隧道的请求转发机制：将调度器收到的IP数据包封装在一个新的IP数据包中，转交给实际服务器，然后实际服务器的响应数据包可以直接到达用户端。目前Linux大多支持，可以用LVS来实现，称为LVS-TUN，与LVS-DR不同的是，实际服务器可以和调度器不在同一个WANt网段，调度器通过IP隧道技术来转发请求到实际服务器，所以实际服务器也必须拥有合法的IP地址。
总体来说，LVS-DR和LVS-TUN都适合响应和请求不对称的Web服务器，如何从它们中做出选择，取决于你的网络部署需要，因为LVS-TUN可以将实际服务器根据需要部署在不同的地域，并且根据就近访问的原则来转移请求，所以有类似这种需求的，就应该选择LVS-TUN。
LVS负载均衡调度算法
不管实际应用中采用的是上面三种模式的哪种模式，调度算法进行调度的策略与算法都是LVS的核心技术，LVS在内核中主要实现了以下十种调度算法。
1.轮询调度
轮询调度（Round Robin 简称’RR’）算法就是按依次循环的方式将请求调度到不同的服务器上，该算法最大的特点就是实现简单。轮询算法假设所有的服务器处理请求的能力都一样的，调度器会将所有的请求平均分配给每个真实服务器。
2.加权轮询调度
加权轮询（Weight Round Robin 简称’WRR’）算法主要是对轮询算法的一种优化与补充，LVS会考虑每台服务器的性能，并给每台服务器添加一个权值，如果服务器A的权值为1，服务器B的权值为2，则调度器调度到服务器B的请求会是服务器A的两倍。权值越高的服务器，处理的请求越多。
3.最小连接调度
最小连接调度（Least Connections 简称’LC’）算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态的调度算法，它通过服务器当前活跃的连接数来估计服务器的情况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1；当连接中断或者超时，其连接数减1。
（集群系统的真实服务器具有相近的系统性能，采用最小连接调度算法可以比较好地均衡负载。)
4.加权最小连接调度
加权最少连接（Weight Least Connections 简称’WLC’）算法是最小连接调度的超集，各个服务器相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员可以动态地设置服务器的权值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
5.基于局部的最少连接
基于局部的最少连接调度（Locality-Based Least Connections 简称’LBLC’）算法是针对请求报文的目标IP地址的 负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下，将相同目标IP地址的请求调度到同一台服务器，来提高各台服务器的访问局部性和Cache命中率，从而提升整个集群系统的处理能力。LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则使用’最少连接’的原则选出一个可用的服务器，将请求发送到服务器。
6.带复制的基于局部性的最少连接
带复制的基于局部性的最少连接（Locality-Based Least Connections with Replication 简称’LBLCR’）算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统，它与LBLC算法不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。按’最小连接’原则从该服务器组中选出一一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按’最小连接’原则从整个集群中选出一台服务器，将该服务器加入到这个服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。
7.目标地址散列调度
目标地址散列调度（Destination Hashing 简称’DH’）算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且并未超载，将请求发送到该服务器，否则返回空。
8.源地址散列调度U
源地址散列调度（Source Hashing 简称’SH’）算法先根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且并未超载，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法的相同，它的算法流程与目标地址散列调度算法的基本相似。
9.最短的期望的延迟
最短的期望的延迟调度（Shortest Expected Delay 简称’SED’）算法基于WLC算法。举个例子吧，ABC三台服务器的权重分别为1、2、3 。那么如果使用WLC算法的话一个新请求进入时它可能会分给ABC中的任意一个。使用SED算法后会进行一个运算
A：（1+1）/1=2 B：（1+2）/2=3/2 C：（1+3）/3=4/3 就把请求交给得出运算结果最小的服务器。
10.最少队列调度
最少队列调度（Never Queue 简称’NQ’）算法，无需队列。如果有realserver的连接数等于0就直接分配过去，不需要在进行SED运算。
参考文章：
https://blog.csdn.net/weixin_40470303/article/details/80541639
https://www.cnblogs.com/deepalley/p/12910129.html
https://www.cnblogs.com/bonelee/p/8890920.html
https://blog.51cto.com/u_14227204/2436891
相关推荐：