携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第25天，点击查看活动详情

负载平衡算法

网络层和应用层算法在分析传入流量的方式和用于分配流量负载的标准方面有所不同。

网络层负载平衡器面临的主要挑战是缺乏对流量流的可见性，仅限于存储在网络数据包标头中的信息。路由决策必须仅基于几个因素 — 主要是源和目标 IP 数据。

网络层负载平衡器无法评估传入请求的性质、其预期的负载生成和给定时间的可用服务器资源。他们需要一定程度的猜测才能做出路由决策。

网络层算法的示例包括：

轮循机制 – 对一批服务器进行编程，以按顺序轮换方式处理负载。该算法假设每个设备能够处理相同数量的请求，并且无法考虑活动连接。
加权轮循机制 – 根据每个服务器能够处理的请求的相对数量对服务器进行评级。具有较高容量的用户会收到更多请求。
最少连接数 – 假设所有连接生成的服务器负载量相等，则将请求发送到活动连接数最少的服务器。
加权最少连接 – 服务器根据其处理能力进行分级。负载根据服务器的相对容量和每个服务器上的活动连接数进行分配。
源 IP 哈希 – 在请求中组合源 IP 地址和目标 IP 地址以生成哈希密钥，然后将其指定给特定服务器。这允许将断开的连接返回到最初处理它的同一服务器。

虽然这些算法在可预测的流量方案中是足够的，但它们在处理不均匀/意外的服务器负载方面却不那么有效。

应用程序层负载均衡器根据正在处理的请求的内容（包括其 HTTP/S 标头和消息以及会话 Cookie）分发请求。它们还可以在从服务器返回时跟踪响应，从而始终提供有关每个服务器正在处理的负载的数据。

与网络负载平衡的推测性质相反，应用程序负载平衡是数据驱动的。这提供了传入请求的智能分布。

最值得注意的应用层算法是最小挂起请求（LPR）。它监视挂起的 HTTP/S 请求，并将其分发到最可用的服务器。LPR 可以立即适应新连接的突然涌入，同时持续监视服务器场中所有服务器的工作负载。

LPR 的优势包括：

选择负载平衡算法时有许多注意事项。具体来说，您的选择需要能够处理可预测的场景（例如，典型的流量）和不可预测的场景（例如，突然的请求涌入，造成重负载）。

网络层算法无法处理的不可预测的场景是站点运营商最关心的问题。此外，与 TTL 相关的延迟使网络负载平衡不是最佳解决方案。

另一方面，应用层算法有助于在可预测和不可预测的情况下保持最佳网站性能。