负载均衡

均衡不能狭义地理解为给每个服务器分配同样的工作量，因为没台服务器的承载能力各不相同，这可能是因为硬件配置，网络带宽导致的差异。这里所说的均衡，就是希望所有服务器不要过载，并且能够最大限度地发挥作用。

先看一下经典的网络分层图：

为什么分享这张图那？因为我们的负载均衡就要在应用层和运输层上面去进行。

Http 重定向

【应用层】Http 重定向实现负载均衡

原理：根据用户的 Http 请求计算出一个真实的 web 服务器地址，并将该 web 服务器地址写入 Http 重定向响应中返回给浏览器，由浏览器重新进行访问。

优点：

比较简单。

缺点：

客户端每次需要多请求一次重定向服务器才能完成请求，性能较差。Http 重定向服务器自身处理能力可能成为瓶颈。
吞吐率限制。假设目前采用轮询的调度策略，子服务器的最大吞吐率为 1000 reqs/s，那么重定向服务器的吞吐率要达到 3000 reqs/s 才能完全发挥子服务器的特点。
重定向访问深度。重定向到一个静态网页和重定向到一个复杂的动态网页的负载差异是不可预料的，所以整站使用重定向方法做负载不太好。我们需要权衡转移请求和处理实际请求的开销，前者相对于后者越小，那么重定向的意义就越大。

很多镜像下载网站下，基本都是用了 Location 做了重定向。

DNS 负载均衡

【应用层】DNS 域名解析负载均衡。

原理：在 DNS 服务器上配置多个域名对应 IP 的记录。例如一个域名 www.baidu.com 对应一组 web 服务器 IP 地址，域名解析时经过 DNS 服务器的算法将一个域名请求分配到合适的真实服务器上。

优点：

将负载均衡的工作交给了 DNS，需要 DNS 还支持基于地理位置的域名解析，将域名解析成距离用户地理位置最近的一个服务器地址，加快速度。

缺点：

目前的 DNS 解析时多级解析，每一级 DNS 都可能缓存记录 A，当某个服务器下线后，该服务器对应的 DNS 记录 A 可能仍然存在，导致分配到该服务器的用户访问失败。

DNS 负载均衡的控制权在域名服务商手里，网站无法做出过多的改善和管理。自定义开发门槛非常之高，所以 DNS 服务器并不能很好地完成工作量均衡分配。

反向代理负载均衡

【应用层】反向代理负载均衡，反向代理服务器工作在 HTTP 层。

原理：反向代理处于 web 服务器这边，反向代理服务器提供负载均衡的功能，同时管理一组 web 服务器，它根据负载均衡算法将请求的浏览器访问转发到不同的 web 服务器处理，处理结果经过反向服务器返回给浏览器。

例如：浏览器访问请求的地址是反向代理服务器的地址114.100.80.10，反向代理服务器收到请求，经过负载均衡算法后得到一个真实物理地址10.0.03，并将请求结果发给真实的服务，真实服务器处理完后通过反向代理服务器返回给请求用户。

优点：部署简单，处于 HTTP 协议层面。

缺点：使用了反向代理服务器后，web 服务器地址不能直接暴漏在外，因此 web 服务器不需要使用外部 IP 地址，而反向代理服务作为沟通桥梁就需要配置双网卡，外部内部两套 IP 地址。

这个大家应该都比较熟悉，因为几乎所有的主流 web 服务器都热衷于支持反向代理的负载均衡。

特性：

调度策略丰富，可以为不同的实际服务器设置不同的权重。
对反向代理服务器的并发处理能力要求较高，因为它工作在 HTTP 层面。
反向代理服务器可以让用户在一次会话周期内的所有请求始终转发到一台特定的后端服务器上，这样能一直保持 session 的本地访问。

IP 负载均衡-NAT

【传输层】IP 负载均衡，LVS-NAT，Linux Virtual Server-Network Address Translation

原理：通过修改目标地址进行负载均衡。

用户访问请求到达负载均衡服务器，负载均衡服务器在操作系统内核进程获取网络数据包，根据算法得到一台真实的服务器地址，然后将用户请求的目标地址修改成真实的服务器地址，数据处理完毕后返回给负载均衡服务器，负载均衡服务器收到响应将自身地址修改成原用户访问地址后将数据返回回去。

优点：在响应请求时速度较反向服务器负载均衡要快。

缺点：当请求数据较大时，速度较慢。

对比上面的反向代理服务器，反向代理服务器工作在 HTTP 层，其本身的开销就严重制约了其可扩展性，从而也限制了它的性能极限。那么能否在 HTTP 层面以下实现负载均衡那？

NAT 服务器：它工作在传输层，它可以修改送过来的 IP 数据包，将数据包的目标地址修改为实际服务器地址。

在 Linux 系统中，通过 IPVS 就可以快速实现负载均衡系统。

实验证明，使用基于 NAT 的负载均衡系统。作为调度器的 NAT 服务器可以将吞吐率提高到一个新的高度，几乎是反向代理服务器的两倍以上。这大多要归功于在内核中进行请求转发的较低开销。但是它的瓶颈就是 NAT 服务器的网络带宽。

IP 负载均衡-DR 直接路由

【数据链路层】数据链路层负载均衡，LVS-DR Linux Virtual Server Direct Routing

原理：在数据链路层修改 Mac 地址进行负载均衡。

负载均衡服务器的 IP 和它所管理的 web 服务群的虚拟 IP 一致。负载均衡数据分发过程中不修改访问地址的 IP 地址，而是修改 Mac 地址。通过这两点达到不修改数据包的原地址和目标地址就可以正常访问。

优点：不需要负载均衡服务器进行地址的转换。数据响应时不需要经过负载均衡服务器。

缺点：负载均衡服务器的网卡带宽要求较高。

NAT 是工作在网络分层模型的传输层（第四层），而直接路由是工作在数据链路层（第二层）。它通过修改数据包的目标 MAC 地址（没有修改目标 IP），将数据包转发到实际服务器上，响应数据直接发送给客户端，不经过调度服务器。

LVS-DR 相较于 LVS-NAT 的最大优势在于 LVS-DR 不受调度器带宽的限制。LVS-DR 适合搭建可扩展的负载均衡系统，不论是 Web 服务器还是文件服务器，以及视频服务器都有出色的性能。

IP 负载均衡-Tunneling IP 隧道

基于IP隧道的请求转发机制：将调度器收到的IP数据包封装在一个新的IP数据包中，转交给实际服务器，然后实际服务器的响应数据包可以直接到达用户端。目前Linux大多支持，可以用LVS来实现，称为LVS-TUN，与LVS-DR不同的是，实际服务器可以和调度器不在同一个WANt网段，调度器通过IP隧道技术来转发请求到实际服务器，所以实际服务器也必须拥有合法的IP地址。

总体来说，LVS-DR和LVS-TUN都适合响应和请求不对称的Web服务器，如何从它们中做出选择，取决于你的网络部署需要，因为LVS-TUN可以将实际服务器根据需要部署在不同的地域，并且根据就近访问的原则来转移请求，所以有类似这种需求的，就应该选择LVS-TUN。