共计 1360 个字符，预计需要花费 4 分钟才能阅读完成。
高可用的工程系统一定要做流量的负载均衡，软件可做负载均衡位置：DNS，代码中，应用层。DNS 受缓存影响；代码中二次转发；基于应用层负载均衡调度的多服务器解决方法也存在一些问题。第一，系统处理开销特别大，致使系统的伸缩性有限。当请求到达负载均衡调度器至处理结束时，调度器需要进行四次从核心到用户空间或从用户空间到核心空间的上下文切换和内存复制；需要进行二次 TCP 连接，一次是 从用户到调度器，另一次是从调度器到真实服务器；需要对请求进行分析和重写。这些处理都需要不小的CPU、内存和网络等资源开销，且处理时间长。所构成系 统的性能不能接近线性增加的，一般服务器组增至 3 或 4 台时，调度器本身可能会成为新的瓶颈。所以，这种基于应用层负载均衡调度的方法的伸缩性极其有限。第 二，基于应用层的负载均衡调度器对于不同的应用，需要写不同的调度器。nginx 主要是基于 HTTP 协议，若对于 FTP、Mail、POP3 等应用，都需要重写调度器。当然四层也无法做业务相关的负载均衡。
IP 层
LVS
针对高可伸缩、高可用网络服务的需求，我们给出了基于 IP 层和基于内容请求分发的负载平衡调度解决方法，并在 Linux 内核中实现了这些方法，将一组服务器构成一个实现可伸缩的、高可用网络服务的虚拟服务器。
官方：http://www.linuxvirtualserver…
逻辑架构
三种 IP 转发实现方式
1.NAT 换目标地址，回来再换一次
2.IP 管道。在 VIP 前加真实 IP。回去直接去掉真实 IP
3. 直接路由。加 MAC 地址找到对应机器。回去直接去掉 MAC 地址（局域网中）
4.fullnat
全部转为内网（内网负载均衡只能是 fullnat）
cip 客户端地址 rip 真实服务器地址 lip 本地地址 SNAT 来源地址转换
部署
vip 这个是提前申请好放到池子里面的，业务现申请直接使用某个 vip，外网 lvs 一般一个集群是 250 个 vip，内网 lvs 是 520 个
每台 LVS 机器都有所有的 VIP 配置（通过 OSPF 一个 VIP 可以有 8 台副本），把所有 VIP 的 IP 都配在机器上。用 OSPF 实现相同 IP 随机分配流量
负载均衡算法
轮叫调度（Round-Robin Scheduling）
加权轮叫调度（Weighted Round-Robin Scheduling）
最小连接调度（Least-Connection Scheduling）记录服务器连接数。会有一段时长的 TCP_WAIT
加权最小连接调度（Weighted Least-Connection Scheduling）
基于局部性的最少链接（Locality-Based Least Connections Scheduling）请求 IP 最近使用服务器 + 服务器未超载，用于 cache
带复制的基于局部性最少链接（Locality-Based Least Connections with Replication Scheduling）LBLC+LCS. 性能和 cache 的折中
目标地址散列调度（Destination Hashing Scheduling）
源地址散列调度（Source Hashing Scheduling）
DGW
dpdk+fullnat 的 LVS
dpdk: 加速数据包处理软件，取代传统的 Linux 内核态驱动（https://blog.csdn.net/zhaoxin…）
