大白话图文结合剖析LVS原理

一、是什么

负载均衡调度器。那么和nginx区别是啥？

• 首先nginx是七层的，lvs是四层的（网络七层，不是此篇重点，不多BB）
• nginx每个请求都需要与客户端握手，且服务端返回响应后需要经过nginx转发到客户端，也就是请求和响应都需要经过nginx
• lvs不需要和客户端握手，就是一个转发器，请求来了我就转发到后面真实服务器，LVS的DR模式，可以直接让后端真实服务器的响应打回到客户端，而不需要再次经过LVS一次。

二、那还要nginx干嘛？

首先我认为lvs和nginx是可以共存的。而不是单打独斗，当然单打独斗也没毛病，但是不存在替代互斥的关系。

lvs跟nginx一起用的场景，我是这么理解的：只有并发极其大的情况下才需要lvs， 并发太大，nginx可能压力会大（因为他每次都需要和client握手），这时候nginx前面挂一层lvs来帮nginx减轻负担，然后nginx做tomcat等容器的负载均衡。各自展现各自的优点，共同办事。
nginx后面三个tomcat等容器集群，挂了一台，nginx会自动放弃掉这台，将请求打到其他机器。而lvs不行，lvs发现这台挂了，请求还会给他，这时候就会造成不友好的情况，所以结合使用，各自发挥各自的优点。

上面那段话看得懂的话就不用看下面这堆详细的解释，但个人建议看下，万一你不会呢？

nginx用来做http的反向代理，通过配置upsteam实现http请求的负载均衡异步转发。如果一个服务器请求失败，立即切换到其他服务器，直到请求成功或者最后一台服务器失败为止。简直就是集群的利器。

lvs采用的是同步请求转发的策略。

同步转发？？？异步转发？？？

同步转发是在lvs服务器接收到请求之后，立即redirect到一个后端服务器，由客户端直接和后端服务器建立连接。而不是客户端和lvs进行握手建立连接。

异步转发是nginx与客户端建立连接，保持客户端连接的同时，发起一个相同内容的新请求到后端，等后端返回结果给nginx后，再由nginx将后端返回的结果返回给客户端。

小结：nginx是所有的请求和响应流量都会经过nginx；而lvs是仅请求流量经过lvs的网络，响应流量由后端服务器的网络返回给客户端。

所以并发极大的情况下，nginx的网络带宽就成了一个巨大的瓶颈。

但是仅仅使用lvs作为负载均衡的话，一旦后端接受到请求的服务器出了问题，那么这次请求就失败了。但是如果在lvs的后端在添加一层nginx（多个），每个nginx后端再有几台应用服务器，那么结合两者的优势，既能避免单nginx的流量集中瓶颈，又能避免单lvs时一锤子买卖的问题（nginx转发失败后会找下一台服务器继续转发请求）。

三、LVS术语

• DS：Director Server。前端负载均衡的服务器。比如LVS等。
• RS：Real Server。后端真实的工作服务器，比如tomcat等。
• VIP：Virtual IP。虚拟IP，是客户端请求的目标的IP地址，比如LVS集群，肯定多个IP，但是客户端只会请求其中一个固定IP，这个就是VIP。
• DIP：Director Server IP，一般用于和后端真实的工作服务器通信的。
• RIP：Real Server IP，后端真实的工作服务器的IP。
• CIP：Client IP，客户端IP，通常直接和VIP交互。

CIP -> VIP -> DIP -> RIP

四、三种模型

不多BB，全在图上了。

0、补充：路由器

1、D-NAT

2、DR

解决D-NAT的请求响应都走DS，造成瓶颈问题。DR只有请求走DS，响应直接打到client，不在经过DS。
LVS DR原理等流程都在图上了。

3、TUN

4、三种模型对比

• 是否需要VIP和realserver在同一网段

DR模式因为只修改包的MAC地址，需要通过ARP广播找到realserver，所以VIP和realserver必须在同一个网段，也就是说DR模式需要先确认这个IP是否只能挂在这个LVS下面；其他模式因为都会修改目的地址为realserver的IP地址，所以不需要在同一个网段内

• 三种模式的性能比较

DR模式、IP TUN模式都是在包进入的时候经过LVS，在包返回的时候直接返回给client；所以二者的性能比NAT高
但TUN模式更加复杂，所以性能不如DR
性能比较：DR>TUN>NAT

五、LVS负载均衡算法

• 轮叫调度 rr

均等地对待每一台服务器，不管服务器上的实际连接数和系统负载

• 加权轮叫 wrr

调度器可以自动问询真实服务器的负载情况，并动态调整权值

• 最少链接 lc

动态地将网络请求调度到已建立的连接数最少的服务器上，如果集群真实的服务器具有相近的系统性能，采用该算法可以较好的实现负载均衡

• 加权最少链接 wlc

调度器可以自动问询真实服务器的负载情况，并动态调整权值，带权重的谁不干活就给谁分配，机器配置好的权重高

• 基于局部性的最少连接调度算法 lblc

这个算法是请求数据包的目标 IP 地址的一种调度算法，该算法先根据请求的目标 IP 地址寻找最近的该目标 IP 地址所有使用的服务器，如果这台服务器依然可用，并且有能力处理该请求，调度器会尽量选择相同的服务器，否则会继续选择其它可行的服务器

• 复杂的基于局部性最少的连接算法 lblcr

记录的不是要给目标 IP 与一台服务器之间的连接记录，它会维护一个目标 IP 到一组服务器之间的映射关系，防止单点服务器负载过高。

• 目标地址散列调度算法 dh

该算法是根据目标 IP 地址通过散列函数将目标 IP 与服务器建立映射关系，出现服务器不可用或负载过高的情况下，发往该目标 IP 的请求会固定发给该服务器。

• 源地址散列调度算法 sh

与目标地址散列调度算法类似，但它是根据源地址散列算法进行静态分配固定的服务器资源。

• 最少期望延迟 sed

不考虑非活动链接，谁的权重大，优先选择权重大的服务器来接收请求，但权重大的机器会比较忙

• 永不排队 nq

无需队列，如果有realserver的连接数为0就直接分配过去

参考连接

六、个人公众号

微信公众号【Java码农社区】