1、LVS调度算法概述
LVS 根据后端服务器的负载，或其他的计算的标准，判断挑选哪台 RS 来进行请求处理。调度算法主要分为”静态调度算法“、”动态调度算法“。
静态调度算法： RR、WRR、SH、DH
静态：仅根据算法本身进行调度，不考虑后端实际负载情况（起点公平）
动态调度算法： LC、WLC、SED、NQ、LBLC、LBLCR
动态：根据算法及 RS 节点负载状态进行调度，较小的 RS 将被调度（保证结果公平）
2、LVS-静态调度算法
2.1、rr-调度算法
2.1.1、功能
RR：round robin 轮询调度算法，将每一次用户的请求，轮流分配给 Real Server节点。
2.1.2、配置方法
ipvsadm -E -t 192.168.87.200:80 -s rr
2.2、wrr调度算法
2.2.1、功能
WRR：weighted round robin 加权轮询调度算法，根据服务器的硬件情况、以及处理能力，为每台服务器分配不同的权值，使其能够接受相应权值的请求。
2.2.2、配置方法
ipvsadm -E -t 192.168.10.200:80 -s wrr
ipvsadm -e -t 192.168.10.200:80 -r 192.168.10.129:80 -g -w 5
ipvsadm -e -t 192.168.10.200:80 -r 192.168.10.130:80 -g -w 1
2.3、SH调度算法
2.3.1、功能
SH：Source Hashing 源地址 hash 调度算法，将请求的源 IP 地址进行 Hash 运算，得到一个具体的数值，同时对后端服务器进行编号，按照运算结果将请求分发到对应编号的服务器上。
1、可以实现不同来源IP的请求进行负载分发；
2、同时还能实现相同来源IP的请求始终被派发至某一台特定的节点；
2.3.2、配置方法
ipvsadm -E -t 192.168.87.200:80 -s sh
2.4、DH调度算法
2.4.1、功能
DH：destination hash 目标地址 hash 将客户端的请求，始终发往同一个 RS 。应用场景： LVS-cache-源站 ，始终调度到指定的 cache ，加速用户体验。
2.4.2、配置方法
ipvsadm -E -t 172.16.1.100:80 -s dh
3、LVS-动态调度算法
3.1、LC调度算法
3.1.1、功能
LC：Least-Connection 最少连接数调度算法，哪台 RS 连接数少就将请求调度至哪台 RS 。
算法： Overhead = ( Active * 256 + Inactive仅连接 ) 一个活动连接相当于256个非活动连接
3.1.2、存在的问题点
L通过LC调度算法会发现，大部分请求会被RealServer1、RealServer2性能差的节点处理;
因为，LC调度算法是谁的连接少就调度给谁，没有考虑到后端主机的性能;
3.2、WLC调度算法
3.2.1、功能
WLC：Weighted Least-Connection 加权最小连接数（默认调度算法），在服务器性能差异较大的情况下，采用“加权最少链接”调度算法优化负载均衡性能，权值较高的 RS 节点，
将承受更多的连接；负载均衡可以自动问询 RS 节点服务器的负载状态，通过算法计算当前连接数最少的节点，而后将新的请求调度至该节点。
算法： Overhead =（ Active * 256 + Inactive ）/Weight
3.2.2、存在的问题点
1、如果是刚搭建LVS，第一次连接，那往哪里调度呢?-->(谁是第一个添加的后端RS就调度给谁)
2、如果第一个添加的RS权重是2，那么他优先响应，是不是就不太合理了。
3、假设有3台节点，权重分别为1，2，3，连接数分别为10，20，30，新请求可能被调度到任何1台节点。(三者计算结果一致。)
3.3、SED调度算法
SED：Shortest Expected Delay 最短期望延迟，尽可能让权重高的优先接收请求，不再考虑非活动状态，把当前处于活动状态的数目+1，通过算法计算当前连接数最少的节点，而后将新的请求调度至该节点。
算法：在WLC基础上改进， Overhead = （ACTIVE+1）*256/Weight
3.4、NQ调度算法
NQ：Never Queue 永不排队/最少队列调度
原理： SED 算法由于某台服务器的权重较小，比较空闲，甚至接收不到请求，而权重大的服务器会很忙，而 NQ 算法是说不管权重多大都会被分配到请求。简单来说，就是无需队列，如果有台 Real Server 的连接数为0会直接分配过去，后续采用 SED 算法。
算法： Overhead = （ACTIVE+1）*256/Weight
3.5、LBLC调度算法
3.5.1、功能
LBLC：Locality-Based Least-Connection 动态目标地址 hash 调度算法，解决 DH调度算法负载不均衡。
应用场景： LVS-cache-源站 ，此前 DH 算法始终调度到后端 Cache1 节点，会造成Cache1 负载过高， LBLC 会根据负载均衡动态调度到后端其他 Cache 节点。
3.5.2、存在的问题点
客户端1请求优酷独家资源
1.LVS通过LBLC调度算法将请求转发给Cache1节点
2.Cache1节点没有数据，则会请求源站集群，获取
3.Cache1节点会将数据直接返回给用户
客户端2请求优酷独家资源
1.LVS检查发现Cache1节点压力过大，会将请求转发给Cache2节点
2.由于Cache2节点没有数据，则会请求源站获取资源
3.Cache2节点会将数据直接返回给用户
问题:
如果大量的用户请求，由于Cache1节点压力过大，则被调度到Cache2节点，Cache2节点没有缓存，岂不是又得缓存一次?
3.6、LBLCR调度算法
3.6.1、功能
LBLCR： Locality-Based Least-Connection with Replication 带复制功能的LBLC算法，解决LBLC负载不均衡的问题，从负载重的复制到负载轻的RS。
应用场景： LVS-cache-源站 ，此前 LBLC 算法始终调度到后端 Cache1 节点，会造成Cache1 负载过高，会根据负载均衡动态调度到后端其他 Cache 节点，同时也会将缓
存数据同步一份至 Cache1、Cache2 节点。
3.6.2、解决的问题
客户端1请求优酷独家资源
1.LVS通过LBLCR调度算法将请求转发给Cache1节点
2.Cache1节点没有数据，则会请求源站集群获取数据
3.Cache1节点会将缓存的数据直接返回给用户
4.Cache1节点会将缓存数据同步至Cache2节点、 Cache3节点
客户端2请求优酷独家资源
1.LVS检查发现Cache1节点压力过大，会将请求调度至Cache2或Cache3节点
2.Cache2、Cache3节点已经有Cache1同步的缓存数据
3.所以无论被客户端被调度到哪个节点处理，都能直接将数据返回给用户，而无需在次请求源站
