负载平衡策略

负载平衡在响应时间和吞吐量上同时提高了可伸缩服务的性能。可伸缩数据服务有两类。

• 纯粹

• 粘滞

纯粹服务可以使任何实例都可以对客户机的请求作出响应。粘滞服务使客户机将请求发送到同一实例。那些请求不被重定向到其它实例。

纯粹服务使用加权的负载平衡策略。在这种负载平衡策略下，客户机请求按缺省方式被均衡地分配到群集内的服务器实例之上。例如，在三节点群集中，假设每个节点的加权值为 1，则每个节点将对来自客户机（代表该服务）的所有请求的 1/3 进行服务。管理员可以随时通过 scrgadm(1M) 命令接口或通过 SunPlex Manager GUI 更改加权值。

粘滞服务有两种：普通粘滞服务和通配粘滞服务。粘滞服务使多个 TCP 连接上并发的应用程序级会话可以共享状态内内存（应用程序会话状态）。

普通粘滞服务使客户机可以在多个并发的 TCP 连接之间共享状态。相对于服务器实例在单个端口上侦听的情况，称该客户机是“粘滞”的。如果实例保持打开状态并可访问，并且在服务处于联机状态时未改变负载平衡策略，则可以保证该客户机的所有服务请求都传给相同的服务器实例。

例如，客户机上的 Web 浏览器在端口 80 使用三种不同的 TCP 连接连接到共享 IP 地址。但在服务时，这些连接将在它们之间交换缓存的会话信息。

可以将粘滞策略的本义延伸到在后台在相同实例上交换会话信息的多个可伸缩服务。当这些服务在后台在相同实例上交换会话信息时，可以说客户机相对于在不同端口上侦听的同一节点上的多个服务器实例是“粘滞的”。

例如，顾客在电子商务站点中通过在端口 80 使用 HTTP 向其购物车中添加商品。然后该顾客切换到端口 443 通过 SSL 来发送安全数据，以便通过信用卡为购物车中的商品进行支付。

通配粘滞服务使用动态分配的端口号，但仍期望客户机请求去往相同的节点。客户机就是端口（具有相同 IP 地址）上的“粘滞通配”。

被动模式 FTP 是这一策略的一个好例子。例如，客户机连接到端口 21 上的 FTP 服务器。然后该服务器指示客户机连接回动态端口范围中的侦听器端口服务器。此 IP 地址的所有请求都将转发到相同的节点，该节点是服务器通过控制信息通知客户机的。

默认情况下，对于每种粘滞策略，加权的负载平衡策略都是有效的。因此，客户的最初请求被定向到由负载平衡器指定的实例。在客户机为正运行实例的节点建立一种关联之后，以后的请求就会条件性地被定向到此实例。该节点必须可访问并且负载平衡策略未被更改。

有关特定的负载平衡策略的其他详细信息如下所示。

• 加权的。根据指定的加权值在各种节点间分配负载。此策略是使用 Load_balancing_weights 属性的 LB_WEIGHTED 值设置的。如果一个节点的加权未明显地设置，则会使用此节点的缺省加权值 1。

  这种加权策略将来自客户机的一定比例的流量重定向到特定的节点。如果 X=加权值，A=所有活动节点的总加权值，则大约 X/A 的新连接总数将定向到该活动节点。但是，此连接总数必须足够大。此策略不对个别请求寻址。

  注意，这一策略不是循环共享的。循环（共享）策略总是会使来自客户机的每个请求到达不同的节点。例如，第一个请求到达节点 1，第二个请求到达节点 2，以此类推。

• 粘滞的。在此策略中，端口集在配置应用程序资源时是已知的。此策略是使用 Load_balancing_policy 资源属性的 LB_STICKY 值设置的。

• 粘滞通配符。此策略是普通“粘滞”策略的超集。对于按照 IP 地址识别的可伸缩服务，端口由服务器分配（并且事先不知道）。端口可能会变化。此策略是使用 Load_balancing_policy 资源属性的 LB_STICKY_WILD 值设置的。