1. 什么是负载均衡
负载均衡是一种通过分发请求到多个服务器来平衡系统负载的技术。它确保每台服务器都能够充分发挥其性能，防止单个服务器过载，提高整个系统的稳定性和可用性。
2. 为什么需要负载均衡
当我们的Web服务器直接面向用户，往往要承载大量并发请求，单台服务器难以负荷，我使用多台
Web服务器组成集群，前端使用Nginx负载均衡，将请求分散的打到我们的后端服务器集群中，实
现负载的分发。那么会大大提升系统的吞吐率、请求性能、高容灾。
3. 介绍一下LVS
LVS（Linux Virtual Server）即Linux虚拟服务器，是由章文嵩博士主导的开源负载均衡项目，目前LVS已经被集成到Linux内核模块中。
该项目在Linux内核中实现了基于IP的数据请求负载均衡调度方案，其体系结构如图1所示，终端互联网用户从外部访问公司的外部负载均衡服务器，终端用户的Web请求会发送给LVS调度器，调度器根据自己预设的算法决定将该请求发送给后端的某台Web服务器，比如，轮询算法可以将外部的请求平均分发给后端的所有服务器，终端用户访问LVS调度器虽然会被转发到后端真实的服务器，但如果真实服务器连接的是相同的存储，提供的服务也是相同的服务，最终用户不管是访问哪台真实服务器，得到的服务内容都是一样的，整个集群对用户而言都是透明的。最后根据LVS工作模式的不同，真实服务器会选择不同的方式将用户需要的数据发送到终端用户，LVS工作模式分为NAT模式、DR模式、TUN模式、以及FULLNAT模式。
4. LVS的四种模式各自的原理，区别，优缺点
NAT模式（LVS-NAT）
原理：把客户端发来的数据包在负载均衡器上将目的地址封装成其中一台RS的IP地址，并发至该RS来处理,RS处理完成后把数据包发给负载均衡器,负载均衡器再把数据包的原IP地址封装成为自己的IP，将目的地址封装成客户端IP地址，然后发给客户端｡无论是进来的流量,还是出去的流量,都必须经过负载均衡器｡
- 优点：集群中的物理服务器可以使用任何支持 TCP/IP 的操作系统，只有负载均衡器需要一个合法的IP地址。
- 缺点：扩展性有限。当服务器节点（普通PC服务器）增长过多时,负载均衡器将成为整个系统的瓶颈，因为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时，大量的数据包都交汇在负载均衡器那，速度就会变慢！
IP隧道模式（LVS-TUN）
原理：由于互联网上的大多Internet服务的请求包很短小，而应答包通常很庞大，使用nat模式庞大的应答数据包也必须经过负载均衡器，这就加重了负载均衡器的负担，隧道模式就是优化这个问题的。所以隧道模式就是，把客户端发来的数据包，封装一个新的IP头标记(仅目的IP)发给RS,RS收到后,先把数据包的头解开,还原数据包,处理后,直接返回给客户端,不需要再经过负载均衡器｡注意,由于RS需要对负载均衡器发过来的数据包进行还原,所以说必须支持IPTUNNEL协议｡所以,在RS的内核中,必须编译支持IPTUNNEL这个选项
- 优点：负载均衡器只负责将请求包分发给后端节点服务器，而RS将应答包直接发给用户。所以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的请求量，这种方式，一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。
- 缺点：隧道模式的RS节点需要合法IP，这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议，服务器可能只局限在部分Linux系统上。
直接路由模式（LVS-DR）
原理：负载均衡器和RS都使用同一个IP对外服务｡但只有DR对ARP请求进行响应,所有RS对本身这个IP的ARP请求保持静默｡也就是说,网关会把对这个服务IP的请求全部定向给DR,而DR收到数据包后根据调度算法,找出对应的RS,把目的MAC地址改为RS的MAC（因为IP一致）并将请求分发给这台RS｡这时RS收到这个数据包,处理完成之后，由于IP一致，可以直接将数据返给客户，则等于直接从客户端收到这个数据包无异,处理后直接返回给客户端｡由于负载均衡器要对二层包头进行改换,所以负载均衡器和RS之间必须在一个广播域,也可以简单的理解为在同一台交换机上｡
- 优点：和TUN（隧道模式）一样，负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户端。与VS-TUN相比，VS-DR这种实现方式不需要隧道结构，因此可以使用大多数操作系统做为物理服务器。
- 不足：要求负载均衡器的网卡必须与物理网卡在一个物理段上
FULL NAT 模式
原理：FULLNAT转发数据包是类似NAT模式，IN和OUT数据包都是经过LVS；唯一的区别：后端RealServer 或者交换机不需要做任何配置。FULLNAT的主要原理是引入local address（内网ip地址），cip-vip转换为lip->rip，而 lip和rip均为IDC内网ip，可以跨vlan通讯
- cip: 客户端地址，即客户端设备的IP地址。
- vip: 虚拟IP地址，是由负载均衡器（比如LVS）提供给客户端的IP地址，客户端将请求发送到这个地址。
- lip: 局部IP地址，指负载均衡器（LVS）对请求进行转发时使用的本地IP地址。
- rip: 后端真实服务器的IP地址，即最终处理请求的实际服务器的IP地址。
在FULLNAT模式中，客户端的请求会通过负载均衡器，从客户端的角度看，它通信的对象是负载均衡器的虚拟IP地址(vip)。请求到达负载均衡器后，负载均衡器会将请求转发给后端的真实服务器，这时使用的是后端服务器的真实IP地址(rip)。在转发请求时，负载均衡器需要使用局部IP地址(lip)来保持通信。
总的来说，FULLNAT模式的原理就是通过局部IP地址，将客户端请求转发到后端真实服务器，同时隐藏了后端服务器的真实IP地址。这种方式可以确保通信的安全性并允许跨VLAN通讯。
- full nat 跟nat 相比的优点是：保证RS回包一定能够回到LVS；因为源地址就是LVS–> 不确定
- full nat 因为要更新sorce ip 所以性能正常比nat 模式下降 10%
- FULLNAT一个最大的问题是：RealServer无法获得用户IP
NAT原理图：
FULLNAT原理图：
如图所示，相比NAT模式，FullNAT多了一个Local IP，IP地址转换时，源和目的IP都改了，即SNAT+DNAT。
官方三种负载均衡技术比较总结表：
5. keepalived+nginx，keepalived+lvs+haproxy各自的优缺点适应的场景
Keepalived的作用是检测服务器的状态，如果有一台web服务器宕机，或工作出现故障，Keepalived将检测到，并将有故障的服务器从系统中剔除， 同时使用其他服务器代替该服务器的工作，当服务器工作正常后Keepalived自动将服务器加入到服务器群中， 这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的服务器。虽然Keepalived可以完成服务的主备工作，但是Keepalived还是依然有很多的限制的场景，当keepalived在公有网络架构上，往往无法直接使用。
keepalived工作在IP/TCP协议栈的IP层，TCP层，及应用层，工作原理基于VRRP协议。
VRRP(Virtual Router Redundancy Protocol)虚拟路由冗余协议是一种容错的主备模式的协议， 当网络设备发生故障时，可以不影响主机之间通信情况下进行设备切换，并且相对用户时切换过程时透明的。
- 网络层(layer 3)：Keepalived会定期向服务器群中的服务器发送一个ICMP的数据包，（既我们平时用的Ping程序）, 如果发现某台服务的IP地址没有激活，Keepalived便报告这台服务器失效，并将它从服务器群中剔除。
- 传输层(layer 4)：Keepalived以TCP端口的状态来决定服务器工作正常与否，如web server的服务端口一般是80， 如果Keepalived检测到80端口没有启动，则Keepalived将把这台服务器从服务器群中剔除。
- 应用层(layer 5)：只要针对应用上的一些探测方式，如URL的get请求，或者对nginx脚本检测等； 可以根据用户自定义添加脚本针对特定的服务进行状态检测，当检测结果与用户设定不一致，则把这台服务器从服务器群中剔除。
keepalived+nginx:
- 优点：nginx 是一款高性能的web服务器，支持反向代理、负载均衡等功能，可以有效地分发流量和提高系统的稳定性；keepalived 可以实现高可用性，当主节点故障时自动切换到备节点。
- 缺点：对于负载均衡来说，nginx 的功能相对较简单，对于复杂的负载均衡场景可能不够灵活、可定制性较差。
适用场景：适用于对负载均衡要求不高的场景，例如一般的web应用、代理服务、文件传输等。
keepalived+lvs:
- 优点：LVS（Linux Virtual Server）是一款基于Linux内核的高性能负载均衡软件，具有良好的扩展性和可靠性，支持多种负载均衡算法；keepalived 可以实现高可用性，当主节点故障时自动切换到备节点。
- 缺点：配置相对复杂，需要更深入的了解和掌握。
适用场景：适用于对负载均衡要求较高的场景，例如高访问量的网站、大规模集群。
keepalived+haproxy:
- 优点：haproxy 是一款高性能的负载均衡软件，具有丰富的负载均衡算法和调度算法，支持自动发现后端服务器；keepalived 可以实现高可用性，当主节点故障时自动切换到备节点。
- 缺点：相对于LVS来说，haproxy 的性能稍低，内存占用也较高。
适用场景：适用于对负载均衡要求较高，同时需要高可用性的场景，例如互联网应用、微服务架构。
总结：
- keepalived+nginx 适用于负载较轻的场景，配置简单，易于上手。
- keepalived+lvs 适用于对负载均衡要求较高的大规模场景，需要更深入的配置和管理知识。
- keepalived+haproxy 适用于对负载均衡要求较高，同时需要高可用性的场景，具有一定的灵活性和可定制性。