负载平衡策略

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

可伸缩数据服务有两类： 纯粹服务和粘滞服务。 纯粹服务就是它的任何实例都可以对客户机的请求作出响应的服务。 粘滞服务是客户机发送请求到相同实例的那种服务。 那些请求不被重定向到其它实例。

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

粘滞服务有两种风格：普通粘滞服务和通配粘滞服务。 粘滞服务允许多个 TCP 连接上并行的应用程序级会话来共享状态内内存（应用程序会话状态）。

普通粘滞服务允许客户机在多个并行的 TCP 连接之间共享状态。 相对于监听单个端口的服务器实例来说，可以说客户机是“粘滞的”。 假设实例保持打开状态并可访问，并且在服务处于联机状态时负载平衡策略不更改，将保证该客户机的所有服务请求都传给相同的服务器实例。

例如，客户机的 Web 浏览器连接到使用三种不同 TCP 连接，连接到端口为 80 的共享 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 值设置的。