面试题：什么是负载均衡？常见的负载均衡策略有哪些？

文章目录

一、负载均衡
二、负载均衡模型分类
三、CDN负载均衡
四、LVS负载均衡
- 4.1 LVS 支持的三种模式
- - 4.1.1 DR 模式
  - 4.1.2 TUN 模式
  - 4.1.3 NAT 模式
- 4.2 LVS 基于 Netfilter 的框架实现
五、负载均衡策略是什么
六、常用负载均衡策略图解
- 6.1 轮询
- 6.2 加权轮询
- 6.3 最少连接数
- 6.4 最快响应
- 6.5 Hash 法
七、用健康探测来保障高可用
- 7.1 HTTP 探测
- 7.2 TCP 探测
- 7.3 UDP 探测

一、负载均衡

负载均衡是云计算的基础组件，是网络流量的入口，其重要性不言而喻。

什么是负载均衡呢？

将用户请求或者说流量通过负载均衡器，按照某种负载均衡算法把流量均匀地分散到后端的多个服务器上，接收到请求的服务器可以独立的响应请求，以期望的规则分摊到多个操作单元上进行执行，达到负载分担的目的。并通过它可以实现横向扩展（scale out），将冗余的作用发挥为高可用。

二、负载均衡模型分类

从应用场景上来说，常见的负载均衡模型有全局负载均衡和集群内负载均衡，从产品形态角度来说，又可以分为硬件负载均衡和软件负载均衡。

全局负载均衡一般通过 DNS 实现，通过将一个域名解析到不同 VIP，来实现不同的 Region 调度能力。

硬件负载均衡器常见的有 F5、A10、Array，它们的优缺点都比较明显，优点是功能强大，有专门的售后服务团队，性能比较好；缺点是缺少定制的灵活性，维护成本较高。

现在的互联网更多的思路是通过软件负载均衡来实现，这样可以满足各种定制化需求，常见的软件负载均衡有 LVS、Nginx、Haproxy。

对于用户配置的四层监听，LVS 后面会直接挂载用户 ECS，七层用户监听 ECS 则挂载在 Tengine 上。四层监听的流量直接由 LVS 转发到 ECS，而七层监听的流量会经过 LVS 到 Tenigine 再到用户 ECS。

每一个 Region 里都会有多个可用区，达到主备容灾目的，每一个集群里都有多台设备，第一是为了提升性能，第二也是基于容灾考虑。

上图为高性能负载均衡控制管理概要图，SLB 产品也有 SDN 概念，转发和控制是分离的，用户所有配置通过控制台先到控制器，通过集中控制器转换将用户配置推送到不同设备上，每台设备上都有 Agent 接收控制器下发的需求。

通过本地转换成 LVS 和 Tengine 能够识别的配置，这个过程支持热配置，不影响用户转发，不需要 reload 才能使新配置生效。

三、CDN负载均衡

四、LVS负载均衡

4.1 LVS 支持的三种模式

早期 LVS 支持以下三种模式：DR 模式、TUN 模式、NAT 模式

4.1.1 DR 模式

DR 模式经过 LVS 之后，LVS 会将 MAC 地址更改、封装 MAC 头，内层 IP 报文不动。

报文经过 LVS 负载均衡查找到 RS 之后，将源 MAC 头改成自己的，目的 MAC 改成 RS 地址，MAC 寻址是在二层网络里，对网络部署有一定的限定，在大规模分布式集群部署里，这种模式的灵活性没有办法满足需求。

4.1.2 TUN 模式

TUN 模式走在 LVS 之后，LVS 会在原有报文基础上封装 IP 头，到了后端 RS 之后，RS 需要解开 IP 报文封装，才能拿到原始报文。

不管是 DR 模式还是 TUN 模式，后端 RS 都可以看到真实客户源 IP，目的 IP 是自己的 VIP，VIP 在 RS 设备上需要配置，这样可以直接绕过 LVS 返回给用户。

TUN 模式问题在于需要在后端 ECS 上配置解封装模块，在 Linux 上已经支持这种模块，但是 Windows 上还没有提供支持，所以会对用户系统镜像选择有限定。

4.1.3 NAT 模式

NAT 模式用户访问的是 VIP，LVS 查找完后会将目的 IP 做 DNAT 转换，选择出 RS 地址。

因为客户端的 IP 没变，在回包的时候直接向公网真实客户端 IP 去路由，NAT 的约束是因为 LVS 做了 DNAT 转换，所以回包需要走LVS，把报文头转换回去。

由于 ECS 看到的是客户端真实的源地址，我们需要在用户 ECS 上配置路由，将到 ECS 的默认路由指向 LVS 上，这对用户场景也做了限制。

4.2 LVS 基于 Netfilter 的框架实现

Netfilter 是 Linux 提供的网络开放平台，基于该平台可以开发自己的业务功能模块，早期好多安全厂商都是基于 Netfilter 做一些业务模型实现。

这种模型比较灵活，但通用模型里更多的是兼容性考虑，路径会非常长;而且通用模型中没办法发挥多核特性，目前 CPU 的发展更多是向横向扩展。

我们经常见到多路服务器，每路上有多少核，早期通用模型对多核支持并不是特别友善，在多核设计上有些欠缺，导致我们在通用模型上做一些应用开发时的扩展性是有限的，随着核的数量越来越多，性能不增反降。

五、负载均衡策略是什么

正如上图所示的这样，由一个独立的统一入口来收敛流量，再做二次分发的过程就是负载均衡，它的本质和分布式系统一样，是分治。在软件系统中为了避免流量分摊不均，造成局部节点负载过大（如 CPU 吃紧等），所以引入一个独立的统一入口来做类似的工作。在软件系统中的负载均衡的背后是策略在起作用，而策略的背后是由某些算法或者说逻辑来组成的。负载均衡，也有很多算法或者说逻辑在支撑着这些策略，也有静态和动态之分。

六、常用负载均衡策略图解

下面来罗列一下日常工作中最常见的 5 种策略。

6.1 轮询

这是最常用也最简单策略，平均分配，人人都有、一人一次。大致的代码如下：

int  globalIndex = 0;   //注意是全局变量，不是局部变量。

try{
    return servers[globalIndex];
} finally {
    globalIndex++;
    if (globalIndex == 3)
        globalIndex = 0;
}

6.2 加权轮询

在轮询的基础上，增加了一个权重的概念。权重是一个泛化后的概念，可以用任意方式来体现，本质上是一个能者多劳思想。

比如，可以根据宿主的性能差异配置不同的权重。大致的代码如下：

int matchedIndex = -1;
int total = 0;

for (int i = 0; i < servers.Length; i++)
{
      servers[i].cur_weight += servers[i].weight;//①每次循环的时候做自增（步长=权重值）
      total += servers[i].weight;//②将每个节点的权重值累加到汇总值中
      if (matchedIndex == -1 || servers[matchedIndex].cur_weight < servers[i].cur_weight) //③如果 当前节点的自增数 > 当前待返回节点的自增数，则覆盖。
      {
            matchedIndex = i;
      }
}
servers[matchedIndex].cur_weight -= total;//④被选取的节点减去②的汇总值，以降低下一次被选举时的初始权重值。
return servers[matchedIndex];

这段代码的过程如下图的表格。"()"中的数字就是自增数，即代码中的 cur_weight。

值得注意的是，加权轮询本身还有不同的实现方式，虽说最终的比例都是 2：1：2。

但是在请求送达的先后顺序上可以有所不同。比如「5-4，3，2-1」和上面的案例相比，最终比例是一样的，但是效果不同。

「5-4，3，2-1」更容易产生并发问题，导致服务端拥塞，且这个问题随着权重数字越大越严重。

例子：10：5：3 的结果是「18-17-16-15-14-13-12-11-10-9，8-7-6-5-4，3-2-1」

6.3 最少连接数

这是一种根据实时的负载情况，进行动态负载均衡的方式。维护好活动中的连接数量，然后取最小的返回即可。大致的代码如下：

var matchedServer = servers.orderBy(e => e.active_conns).first();
matchedServer.active_conns += 1;
return matchedServer;

//在连接关闭时还需对active_conns做减1的动作。