因为，负载均衡器应当只选择能正常做出响应的后端服务器，因此就需要有一种判断后端服务器是否「健康」的方法。为了监视后台服务器的运行状况，运行状态检查服务会定期尝试使用转发规则定义的协议和端口去连接后端服务器。如果，服务器无法通过健康检查，就会从池中剔除，保证流量不会被转发到该服务器，直到其再次通过健康检查为止。

负载均衡算法

负载均衡算法决定了后端的哪些健康服务器会被选中。几个常用的算法：

Round Robin（轮询）：为第一个请求选择列表中的第一个服务器，然后按顺序向下移动列表直到结尾，然后循环。
Least Connections（最小连接）：优先选择连接数最少的服务器，在普遍会话较长的情况下推荐使用，使得吞吐量变大。能者多劳。
Source：根据请求源的 IP 的散列（hash）来选择要转发的服务器。这种方式可以一定程度上保证特定用户能连接到相同的服务器。

如果你的应用需要处理状态而要求用户能连接到和之前相同的服务器。可以通过 Source 算法基于客户端的 IP 信息创建关联，或者使用粘性会话（sticky sessions）。

最后，想要解决负载均衡器的单点故障问题，可以将第二个负载均衡器连接到第一个上，从而形成一个集群。

当主负载均衡器发生了故障，就需要将用户请求转到第二个负载均衡器。因为 DNS 更改通常会较长的时间才能生效，因此需要能灵活解决 IP 地址重新映射的方法，比如浮动 IP（floating IP）。这样域名可以保持和相同的 IP 相关联，而 IP 本身则能在服务器之间移动。

一个使用浮动 IP 的负载均衡架构示意图：

以上，大致就是负载均衡的工作原理。

负载均衡的具体实现方式

DNS

DNS轮询是最简单的负载均衡方式。以域名作为访问入口，通过配置多条DNS A记录使得请求可以分配到不同的服务器。

DNS轮询没有快速的健康检查机制，而且只支持WRR的调度策略导致负载很难“均衡”，通常用于要求不高的场景。并且DNS轮询方式直接将服务器的真实地址暴露给用户，不利于服务器安全。

CDN

CDN（Content Delivery Network，内容分发网络）。通过发布机制将内容同步到大量的缓存节点，并在DNS服务器上进行扩展，找到里用户最近的缓存节点作为服务提供节点。

因为很难自建大量的缓存节点，所以通常使用CDN运营商的服务。目前国内的服务商很少，而且按流量计费，价格也比较昂贵。

IP负载均衡

IP负载均衡是基于特定的TCP/IP技术实现的负载均衡。比如NAT、DR、Turning等。是最经常使用的方式。关于其原理，可以参考下面另一篇文章：lvs中的负载均衡方式。

IP负载均衡可以使用硬件设备，也可以使用软件实现。硬件设备的主要产品是F5-BIG-IP-GTM（简称F5)，软件产品主要有LVS、HAProxy、NginX。其中LVS、HAProxy可以工作在4-7层，NginX工作在7层。

硬件负载均衡设备可以将核心部分做成芯片，性能和稳定性更好，而且商用产品的可管理性、文档和服务都比较好。唯一的问题就是价格。

软件负载均衡通常是开源软件。自由度较高，但学习成本和管理成本会比较大。

具体可参见

实现负载均衡的几种方式_HumorMrChen的博客-CSDN博客_负载均衡

用健康探测来保障高可用

常用负载均衡及策略图解_王道长的技术博客-CSDN博客_负载均衡策略

不管是什么样的策略，难免会遇到机器故障或者程序故障的情况。所以要确保负载均衡能更好的起到效果，还需要结合一些健康探测机制。定时的去探测服务端是不是还能连上，响应是不是超出预期的慢。

如果节点属于“不可用”的状态的话，需要将这个节点临时从待选取列表中移除，以提高可用性。一般常用的健康探测方式有 3 种。

HTTP 探测

使用 Get/Post 的方式请求服务端的某个固定的 URL，判断返回的内容是否符合预期。一般使用 HTTP 状态码、Response 中的内容来判断。

TCP 探测

基于 TCP 的三次握手机制来探测指定的 IP + 端口。

UDP 探测

可能有部分应用使用的是 UDP 协议。在此协议下可以通过报文来进行探测指定的 IP + 端口。

具体例子

Nginx和Tomcat对请求负载均衡的方案

整体思想方向：

前端部署nginx服务器，后端部署tomcat应用。用户访问nginx服务器，对于静态资源nginx服务器直接返回到浏览器展示给用户，对动态资源的请求被nginx服务器转发（分配）到tomcat应用服务器，tomcat应用服务器将处理后得到的数据结构返回给nginx服务器，然后返回到浏览器展示给用户。

注意：

在这里Tomcat应用服务器就是Java应用，可以理解为后台。