负载均衡 Load Balancing

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

现在的负载均衡一般被称做四层负载均衡与七层负载均衡，这里的四层说的是这些工作模式的共同特点都是维持一个 TCP 连接，而不是说它只工作在第四层，它只是一个统称

数据链路层负载均衡

数据链路层的负载均衡有硬件实现，这种负载均衡一般通过修改 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 通道来维持通信

应用层一般是由软件实现的，因为可以获取到数据包中的信息，因此可以实现更多操作，比如获取上层协议中的某个数据进行一致性哈希操作

均衡策略与实现

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

轮询与随机

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

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

随机权重与加权轮询

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

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

一致性 hash

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

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

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

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

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

此时的数据倾斜怎么处理呢？同一个结点存放了大量的数据这种情况叫数据倾斜，可以将一台服务器虚拟化成多个服务器结点

这种负载均衡偏向存储类，比如数据库，但是如果只做请求转发的话，普通哈希也是可以的

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

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

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