对于电商平台而言，随着业务的不断发展壮大，网站访问量和数据量也随之急剧增长，该情况的产生给服务器带来了一定的负担。从用户体验层面而言，由于服务器端数据处理带来的时延，往往导致页面的响应速度过慢、操作流畅性受阻等问题。这在某种程度上甚至会潜在影响平台的成交量。提供高效率，高质量的服务成为亟待解决的问题。负载均衡策略的出现和发展成为缓解上述问题的有效途径

按层分类

数据链路层负载均衡

数据链路层的负载均衡由硬件实现，这种负载均衡一般通过修改 MAC 地址来将请求转发到相应的机器上，因为只对数据链路层做处理，因此不会修改 IP 地址，需要保证负载均衡器与处理请求的机器使用同一 IP。如果不处于同一 IP，返回给客户端的报文中的源地址就会对不上

也正是因为实际处理请求的真实物理服务器 IP 和数据请求中的目的 IP 是一致的，所以响应结果就不再需要通过负载均衡服务器进行地址交换，可将响应结果的数据包直接从真实服务器返回给用户的客户端，避免负载均衡器网卡带宽成为瓶颈，因此数据链路层的负载均衡效率是相当高的

这种负载均衡模式也常被很形象地称为直接路由

网络层负载均衡

网络层负载均衡同样是由硬件实现，主要起到转发的作用。负载均衡器通过修改 IP 来实现负载均衡，这种方式效率也非常高

修改 IP 由两种方式，一种是套娃式，即将收到的请求再包一层 Headers，原来请求中的 Headers 与 Payload 变成新请求中的 Payload，在这个新数据包的 Headers 中写入真实服务器的 IP 作为目标地址。在一般的 Linux 系统中，大部分都已经实现了拆解这种请求的算法了。因为没有修改请求中的任何东西，因此服务器可以直接返回请求给客户端，这种方式被称为 IP 隧道

另外一种方式是直接把数据包 Headers 中的目标地址改掉，修改后原本由用户发给均衡器的数据包，也会被三层交换机转发送到真实服务器的网卡上，而且因为没有经过 IP 隧道的额外包装，也就无须再拆包了。但问题是这种模式是通过修改目标 IP 地址才到达真实服务器的，如果真实服务器直接将应答包返回客户端的话，这个应答数据包的源 IP 是真实服务器的 IP，也即均衡器修改以后的 IP 地址，客户端不可能认识该 IP，自然就无法再正常处理这个应答了。因此，只能让应答流量继续回到负载均衡，由负载均衡把应答包的源 IP 改回自己的 IP，再发给客户端

应用层负载均衡

前面介绍的四层负载均衡工作模式都属于转发，即直接将承载着 TCP 报文的底层数据格式（IP 数据包或以太网帧）转发到真实服务器上，此时客户端到响应请求的真实服务器维持着同一条 TCP 通道。但工作在四层之后的负载均衡模式就无法再进行转发了，只能进行代理，此时真实服务器、负载均衡器、客户端三者之间由两条独立的 TCP 通道来维持通信

应用层负载均衡一般是由软件实现的，因为可以获取到数据包中的信息，因此可以实现更多操作，比如获取上层协议中的某个数据进行一致性哈希操作。如果做后端开发接触最多的应该是这种类型的负载均衡，会接触到的 nginx、feign、dubbo、redis 等组件都会有相关概念

按端分类

负载均衡按端分又分服务端负载均衡和客户端负载均衡，他们各自有各自的特点

服务端负载均衡

服务端负载均衡是最传统、最常见的模式。它需要一个独立的、位于客户端和后端服务器集群之间的负载均衡器（硬件或软件）

它的工作原理为所有客户端请求首先发送到一个统一的、对外的入口（负载均衡器的 IP 或域名），负载均衡器根据预设的算法从健康的服务器池中选择一台，然后将客户端的请求转发给选中的服务器

注意服务器处理完请求后，将响应返回给负载均衡器，负载均衡器再将其返回给原始的客户端。对客户端而言，它只知道负载均衡器的存在，完全感知不到后端有多少台真实的服务器

典型应用为 nginx，所有流量都经过负载均衡器，它本身可能成为瓶颈。虽然可以通过集群化来避免单点故障，但这增加了架构的复杂性，这种负载均衡也对应反向代理

客户端负载均衡

客户端负载均衡是一种更智能的模式，它将负载均衡的逻辑集成到每个客户端或一个轻量级的代理中

工作原理为，客户端首先会查询一个服务注册中心（例如：Consul, Etcd, Zookeeper，或 Nacos、Eureka 等），以获取某个服务的所有可用实例的地址列表

客户端在本地通过内置的负载均衡算法实现，客户端会从注册中心中定期拉取或者订阅获取到服务端列表，然后使用负载均衡算法来选择一个实例。然后客户端直接向选中的服务实例发送请求，不再经过任何中央代理

这种架构需要注册中心，一般分布式架构中经常使用，比如 feign、dubbo 等，对应正向代理

均衡策略与实现

负载均衡的另外一项重要职责就是选择谁来处理用户请求（本来就是为了做这个的，如果只是将用户的请求转发出去，那就不叫负载均衡了），以下是几个比较常见的负载均衡策略

轮询与随机

两个很普通的负载均衡策略

普通的轮询，轮到哪台机器哪台机器处理请求。而普通的随机均衡，则是将客户端的请求随机分配给内部的多个服务器

随机权重与加权轮询

每一台服务器都有一个设定权重，负载均衡器将所有权重进行统计得到每个服务器的服务概率，根据这个概率进行随机选择，这就是随机权重

轮询就是把请求依次分配给每个服务提供者，加权轮询就是在轮询的基础上，让更多的请求落到权重更大的服务提供者上

但是他们内部是怎么实现的呢？加权轮询基础原理是每台服务器被赋予一个权重值，权重越高分配的请求越多。按权重比例循环分配请求，而非简单轮流

基础实现步骤：

1，计算权重总和：total_weight = 3 + 2 + 1 = 6 2，维护动态计数器：每轮选择当前权重最高的服务器，如第一轮选 A 3，被选中服务器的当前权重减去总权重（A = 3 - 6 = -3），其他服务器权重累加初始权重。然后循环执行（B: 2 + 2 = 4，C: 1 + 1 = 2）

这东西叫平滑加权轮询，一些故障机器直接设置权重为0，我们会直接排除权重为0的节点，直到其恢复健康状态

一致性 hash

使用一个哈希函数对请求中的某些特征值进行计算，计算结果是哪台服务器就选择哪台服务器，简单来说是这样的，但是我们还漏了一致性，这里的一致性指保证服务集群的某个真实服务器出现故障或者向集群新增加一个机器后（这种情况很常见），节点之间的数据迁移只限于两个节点之间，不会造成全局的网络问题

这么做的目的重要为了解决在存储时，当集群中数据量很大时，采用一般的哈希函数，在节点数量动态变化的情况下会造成大量的数据迁移，导致网络通信压力的剧增，严重情况，还可能导致数据库宕机

根据业务需求，一致性哈希可以玩出很多花样，比如以下的是 redis 使用的一致性 hash 算法：

一致性 Hash 算法也是使用取模的方法，不过，上述的取模方法是对服务器的数量进行取模，而一致性的 Hash 算法是对 2 的 32 方取模，这导致一致性 Hash 算法将整个 Hash 空间组织成一个虚拟的圆环

利用服务器的一些参数进行同样的 hash 计算，同样可以唯一确定一个位置，数据在环上顺时针查找必定可以找到一台服务器

此时的数据倾斜怎么处理呢？同一个结点存放了大量的数据这种情况叫数据倾斜，可以将一台服务器虚拟化成多个服务器结点，就是所谓的虚拟节点技术 这种负载均衡偏向存储类，比如数据库，但是如果只做请求转发的话，普通哈希也是可以的

最少活跃数（最少连接数）

永远选择处理业务最少的那一台机器，每收到一个请求后，对应的服务提供者的活跃数+1，当这个请求处理完之后，活跃数-1

因为只有长连接猜可以这么做记录，这种策略就比较适合长时处理的请求服务，比如 FTP 传输