负载平衡器如何工作

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

使用负载平衡器还可以启用从一个服务器实例故障转移到另一个服务器实例的请求。对于要保留的 HTTP 会话信息，请配置 HTTP 会话持久性。有关更多信息，请参见第 8 章，配置高可用性会话持久性和故障转移。

有关配置负载平衡的完整说明，请参见 Sun Java System Application Server 高可用性管理指南。

使用 asadmin 工具而不是管理控制台来配置 HTTP 负载平衡。

• 指定的请求和未指定的请求

• HTTP 负载平衡算法

• 样例应用程序

另请参见：

• 设置负载平衡的先决条件

• 指定的请求和未指定的请求

• HTTP 负载平衡算法

• 设置负载平衡的步骤

指定的请求和未指定的请求

在某个请求首次从 HTTP 客户机传入负载平衡器时，此请求为新会话请求。新会话请求称为未指定的请求。负载平衡器会根据循环（共享）算法将此请求路由到群集中的应用程序服务器实例。

在某个应用程序服务器实例中创建会话后，负载平衡器会将此会话的所有后续请求都路由到该特定实例而且只路由到该实例。现有会话的请求称为指定的或粘性请求。

HTTP 负载平衡算法

Sun Java System Application Server 负载平衡器使用粘性 Round Robin 算法对收到的 HTTP 和 HTTPS 请求进行负载平衡。给定会话的所有请求都将被发送到同一个应用程序服务器实例。使用粘性负载平衡器，会话数据将被高速缓存在单个应用程序服务器上，而不会被分布到群集中的所有实例。

因此，粘性 Round Robin 方案能够带来明显的性能优势，这些优势通常超过了使用纯 Round Robin 方案带来的更加平均分布负载的优势。

新的 HTTP 请求发送到负载平衡器插件时，系统将基于简单的 Round Robin 方案将该请求转发到某个应用程序服务器实例。随后，将通过使用 Cookie 或显式 URL 重写将该请求“粘”到此特定应用程序服务器实例上。

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

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

• Cookie 方法：负载平衡器插件使用一个单独的 Cookie 来记录路由信息。要使用基于 Cookie 的方法，HTTP 客户机必须支持 Cookie。

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

样例应用程序

以下目录包含了用于演示负载平衡和故障转移的样例应用程序：

install_dir/samples/ee-samples/highavailability
install_dir/samples/ee-samples/failover

ee-samples 目录还包含有关设置运行样例的环境的信息。