负载均衡（Server Load Balance），含义是将自载（工作任务）进行平衡，分摊到多个操作单元上进行执行，从而实现整个系统共同完成任务。
负载均衡的关键在于使任务负载在集群中的服务器上被尽可能均衡地承载，避免出现集群中某几台服务器超载而其他服务器闲置的情况。在实现了负载均衡的集群中，多台服务器通过网络连接在一起，通过在集群前端部署负载均衡设备，根据预先配置的均衡策略将用户请求在集群中分发，并维护服务器的可用性。负载均衡实现的示意图如图所示。
可以看出，负载均衡设备能够在服务器之前截获到客户端发来的用户请求，然后按照预先配置的负载均衡策略将其分发到合适的后端服务器上。因此，客户端发出的业务请求报文首先都要发送到负载均衡设备的IP地址上，因为该地址并不负责处理实际的业务操作，因此通常将该地址称为虚拟lP地址，而将后端真正的业务服务器称为真实服务器。负载均衡设备通过虚拟IP地址和客户端通信，再将负载合理地分配给真实服务器。
1. 负载均衡调度算法
负载均衡调度算法的目标是将用户请求和相关流量高效、正确地分发到处于正常工作状态的服务器上，使得各台服务器尽可能地保持负载均衡。
调度算法可以分为静态算法和动态算法两大娄。
- 静态算法是指按照预先设定的策略进行分发，而不考虑当前服务器的实际负载情况。典型的静态算法包括轮询、加权轮询、随机、加权随机、基于源IP的Hash、基于源IP端口的Hash、基于目的IP的Hash、基于UDP报文净荷的Hash等；
- 动态算法能够根据各服务器实际运行中的负载情况进行连接分发，具有更优的均衡效果，典型的动态算法包括基于最小连接、基于加权最小连接、最小响应时间等。
- 轮询（Round Robin）：依次将请求分发到不同的服务器上，使得各台服务器平均分担用户的连接请求，该算法适用于集群中各服务器性能相当而无明显优劣差异的场景。
- 加投轮询（Weighted Round Robin）：依次将请求分发到不同的服务器上，其中权值大的分配较多请求，权值小的分配较少请求，该算法利用权值标识服务器间的性能差异，适用于各服务器间性能不一的场景。
- 随机（Random）：随机地将请求分发到不同的服务器上，从统计学角度看，调度的结果为各台服务器平均分担用户的连接请求，该算法适用于集群中各服务器性能相当而无明显优劣差异的场景。
- 加权随机（Weighted Random）：随机地将请求分发到不同的服务器上，从统计学角度看，调度的结果为各台服务器按照权值比重分担用户的连接请求，该算法适用于集群中各服务器性能存在差异的场景。
- 基于源IP的Hash( Source IP Hashing)：通过一个Hash函数将来自同一个源IP地址的请求映射到一台服务器上，该算法适用于需要保证来自同一用户的请求被分发到同一台服务器的场景。
- 基于源IP端口的Hash（Source IP and Source Port Hashing）：通过一个Hash函数将来自同一个源IP地址和源端口号的请求映射到一台服务器上，该算法适用于需要保证来自同一用户同一业务的请求教分发到同一台服务器的场景。
- 基于目的IP的Hash(Destination IP Hashing)：通过一个Hash函数将去往同一个目的IP地址的请求映射到一台服务器上，该算法适用于需要保证到达同一目的地的请求被分发到同一台服务器的场景。
- 基于UDP报文净荷的Hash（UDP Packet Load Hashing）：通过一个Hash函数将UDP报文载荷中特定字段的内容相同的请求映射到一台服务器上，该算法适用于需要保证UDP报文载荷中特定字段内容相同的请求被分发到同一台服务器的场景。
- 最小连接(Least Connection)：根据当前各台服务器的连接数估算服务器的负载情况，把新的连接分配给连接数最小的服务器。该算法能够将连接保持时长差异较大的用户请求合理地分发到各台服务器上，适用于集群中各服务器性能相当、无明显优劣差异，而且不同用户发起的连接保持时长差异较大的场景。
- 加权最小连接（Weighted Least Connection）：调度新连接时尽可能使得服务器上已经建立的活动连接数和服务器权值成一定比例，其中权值标识了服务器间的性能差异，该算法适用于集群中各服务器性能存在差异，而且不同用户发起的连接保持时长差异较大的场景。
- 最小响应时间（Least Response Time）：调度新连接时尽可能选择对用户请求响应时间短的服务器，该算法适用于用户请求对服务器响应时间要求较高的场景。
2. 会话持续性保证技术
会话持续性保证技术的目标是保证在一定时间段内某一个用户与系统的会话只交给同一台服务器处理，这一点在满足网银、网购等应用场景的需求时格外重要。
在实际的应用中，一次业务交互可能包含有多个TCP连接，不同业务的TCP连接有各自的特点。比如：FTP业务的连接包含了一个控制通道和多个数据通道，这些TCP连接之间存在显式的关联关系，即数据通道的TCP连接是通过控制通道协商得来的。因此，在负载均衡过程中只需要分析FTP业务的控制通道报文就可以获得各个数据通道的信息并进而将这些信息纳入到一个会话中，从而保证所有通道都访问同一台服务器。但是，对于HTTP业务而言，其各个TCP连接间就不存在这种显式的关联关系，HTTP是一个无状态协议。但是在某些场景中又要求一系列HTTP消息之间建立关联，比如HTTP网络购物，这只能依靠携带在数据报文中的相关信息表达连接之间的关联，例如源IP地址、Cookie数据等。
- 基于源IP地址的持续性保持：主要用于四层负载均衡，确保来自同一个源lP的业务能够分配到同一台服务器中。当负载均衡设备接收到某IP的首次请求时，建立持续性表项，记录下为该IP分配的服务器情况，在会话表项的生存周期内，后续具有相同源IP地址的业务报文都将被发往该服务器处理。
- 基于Cookie数据的持续性保持：主要用于七层负载均衡，用以确保同一会话的报文能够被分配到同一台服务器中。其中，根据服务器的应答报文中是否携带含有服务器信息的Set-Cookie字段，又可分为采用Cookie插入或者Cookie截取的方法。
① Cookie插入保持：服务器的应答报文中不携带含有服务器信息的Set-Cookie字段，而由负载均衡设备在报文中添加相关信息。这样，客户端就会在请求报文中加入含有该服务器信息的Cookie字段，进而由负载均衡设备按照Cookie字段中的服务器信息将请求报文发给相应的服务器。
② Cookie截取保持：服务器的应答报文中携带含有服务器信息的Set-Cookie字段，负载均衡设备根据用户配置的Cookie标识截取应答报文中的Cookie值。对于后续的客户端请求报文，如果能够匹配负载均衡设备中保存的Cookie值，则负载均衡设备直接将请求报文发给相应的服务器。 - 基于SIP报文Call-ID的持续性保持：主要用于七层负载均衡，用以确保IP会话中会话标识相同的SIP报文能够被分配到同一台服务器中。当负载均衡设备接收到某一个客户端的某一个业务的首次请求时，建立持续性表项，记录下为该客户端分配的服务器情况，在会话表项的生存周期内，后续具有相同会话标识的SIP业务报文都将被发往该服务器处理。
- 基于HTTP报文头的持续性保持：主要用于七层负载均衡，用以确保HTTP报文头中的某些关键信息相同的报文能够被分配到同一台服务器中。当负载均衡设备接收到某一个客户端的某一个业务的首次请求时，根据HTTP报文头关键字建立持续性表项，记录下为该客户端分配的服务器情况，在会话表项的生存周期内，后续具有相同HTTP报文头信息的报文都将被发往该服务器处理。至于什么信息被设置为关键字，是配置负载均衡策略的一个步骤。
3. 服务器健康检测技术
服务器健康检测技术的目标是及时发现和剔除工作状态不正常的服务器，保留“健康”的服务器池为用户提供服务。服务器健康检测的核心是定期对服务器的工作状态进行探测，收集相应信息，及时隔离工作状态异常的服务器。另外，除了标识服务器能否继续工作外，健康检测的结果还可以统计出服务器的响应时间，作为负载均衡设备选择服务器的依据。
主要方法是通过发送不同类型的协议报文并通过检查能否接收到正确的应答来判定服务器的健康程度，主要包括以下几项。
- ICMP：向集群中的服务器发送ICMP Echo报文，若正确收到ICMP Reply，则证明服务署ICMP协议处理正常。
- TCP：向集群中的服务器的某个端口发起TCP连接建立请求，若成功三次握手建立TCP连接，则证明服务器TCP协议处理正常。
- HTTP：与集群中的服务器的HTTP端口（默认情况为80端口）建立TCP连接，然后发出HTTP请求，若收到的HTTP应答内容正确，则证明服务器HTTP协议处理正常。
- FTP：与集群中的服务器的FTP端口（默认情况为21端口）建立TCP连接，然后获取服务器上的文件，若收到的文件内容正确，则证明服务器FTP协议处理正常。
- DNS：向集群中的DNS服务器发出DNS请求，若收到正确的DNS解析应答，则证明服务器DNS协议处理正常。
- RADIUS：向集群中的服务器发送RADIUS认证请求，若收到认证成功的应答，则证明服务器RADIUS协议处理正常。
- SSL：向集群中的服务器发起SSL连接建立请求，若成功建立SSL连接，则证明服务器SSL协议处理正常。
针对不同的服务器功用，可以选择相应的健康检测方法，例如ICMP检测适用于服务器主机层面的健康检测，TCP检测适用于业务层面的健康检测，HTTP和FTP等方面的检测适用于应用层面的健康检测。一旦发现服务器处理出现异常，即可以将其上分担的负载通过负载均衡机制转移到合适的“健康”服务器上，保证整个集群系统的可用性。
