HTTP 负载平衡器如何工作

负载平衡器尝试在多个 Application Server 实例（独立或群集）之间平均分配工作量，从而提高系统的整体吞吐量。

HTTP 负载平衡器对 Java EE 应用服务器上部署的服务启用高可用性。在这样做时，如果检测到原始的处理实例因不可用或异常而无法处理请求，它会将会话请求故障转移到其他服务器实例。为了使 HTTP 会话信息能够保留下来，您必须使用群集配置文件，已安装和设置 HADB，并已配置 HTTP 会话持久性。有关更多信息，请参见第 9 章，配置高可用性会话持久性和故障转移。

负载平衡器不能处理大于 8k 的 URI/URL。

HTTP 负载平衡算法

默认情况下，Sun Java System Application Server 负载平衡器使用粘性 round robin 算法对收到的 HTTP 和 HTTPS 请求进行负载平衡。

新的 HTTP 请求发送到负载平衡器插件时，系统将基于简单的 round robin 方案将该请求转发到某个应用服务器实例。如果请求用于基于会话的应用程序，则这还包括对新会话的请求。来自同一客户机的对同一基于会话的应用程序的后续请求被认为是已分配的请求或粘性请求，并由负载平衡器路由到同一实例。粘性 round robin 由此得名。对非基于会话的应用程序的请求和对基于会话的应用程序的第一个请求称为未分配的请求。粘性是通过使用 Cookie 或显式 URL 重写实现的。负载平衡器会自动确定粘性方法。

负载平衡器插件使用以下方法来确定会话粘性：

• Cookie 方法：负载平衡器插件使用一个单独的 Cookie 来记录路由信息。HTTP 客户机（通常为 Web 浏览器）必须支持 Cookie 才能使用基于 Cookie 的方法。如果 HTTP 客户机无法接受 Cookie，则插件使用以下方法。

• 显式 URL 重写：粘性信息将被附加至 URL。即使 HTTP 客户机不支持 Cookie，也可以使用此方法。

从粘性信息中，负载平衡器插件将首先确定请求先前被转发到的实例。如果发现该实例工作正常，负载平衡器插件会将请求转发至该特定应用程序服务器实例。因此，给定会话的所有请求都将被发送到同一个应用程序服务器实例。