Apache+Tomcat负载平衡设置实例详解 （2）

xiuxuan

使用cache_timeout的原因：

众所周知，一个身背重负的web server（例如apache）建立childs/threads来处理负载，而当负载减少时它将销毁无用的childs/threads。每个child在转发请求给Tomcat时要打开一个ajp13连接，而在Tomcat那一端也将建立一个ajp13线程与之通讯。

但是问题出现在一个ajp13连接建立完成后，child没有及时的释放那个ajp13连接，由于web server1将保持它的childs/threads运行已处理高负载，即使childs/threads处理快速的静态内容，在Tomcat端也将积累很多的无用ajp13线程。

socket_keepalive：

当防火墙位于web server与Tomcat之间时，防火墙将尝试断开未激活的网络连接。此属性将告诉操作系统在未激活的连接中发送KEEP_ALIVE信息(发送间隔时间依赖于操作系统的设置，一般为120秒)，这样将防止防火墙切断未激活的网络连接。

但此设置并不是，它对于某些防火墙也无能为力。

socket_timeout：

此属性说明连接在未激活的状况下持续多久，web server将主动切断之。这是一个使Tomcat端的陈旧线程不致过多的好方法，但是也带来了在下一次请求到来时需要重新打开socket的开销。此属性与cache_timeout有类似的功效，但是它工作在non-cache模式。

connect_timeout：

web server在连接建立后将一个PING请求发送到ajp13协议的连接上。 此属性说明了web server等待PONG回应的时间（以ms为单位）。此属性在jk 1.2.6版本被增加进来，以求避免Tomcat的死机，Tomcat 3.3.2+, 4.1.28+ and 5.0.13+实现了对使用ajp13的 ping/pong的支持。此属性默认为失效的。

prepost_timeout：

web server在转发一个请求后将一个PING请求发送到ajp13协议的连接上。此属性说明了web server等待PONG回应的时间（以ms为单位）。此属性在jk 1.2.6版本被增加进来，以求避免Tomcat的死机，Tomcat 3.3.2+, 4.1.28+ and 5.0.13+实现了对使用ajp13的 ping/pong的支持。此属性默认为失效的。

reply_timeout：

此属性告诉web server在接到远端的Tomcat已死并实时的切换到集群中的另外一个Tomcat的回应之前等待一段时间。默认情况下web server将永远等待。属性值为web server要等待回应的时间（以ms为单位），所以如果具有运行时间较长的servlet时设置其值要小心。此属性在jk 1.2.6版本被增加进来，以求避免Tomcat的死机和在支持ajp13的servlet引擎上发生的问题。此属性默认为失效的。

recovery_options：

此属性说明了web server在检测到Tomcat失败后如何进行恢复工作。默认情况下，web server将转发请求给处于负载平衡模式中的另一个Tomcat。属性值为0，说明全部恢复；属性值为1，说明如果在Tomcat接到请求后出现失败状况，则不进行恢复；属性值为2，说明如果在Tomcat发送http头给客户端后出现失败状况，则不进行恢复；属性值为3，说明如果在Tomcat接到请求后出现失败状况或者在Tomcat发送http头给客户端后出现失败状况，则不进行恢复。

此属性在jk 1.2.6版本被增加进来，以求避免Tomcat的死机和在支持ajp13的servlet引擎上发生的问题。此属性默认为全部恢复。

例如：一个名为“worker2”的worker的配置：

<ccid_nobr></ccid_nobr>

<ccid_code></ccid_code>worker.worker2.host=www2.x.com worker.worker2.port=8009 worker.worker2.lbfactor=3.5 worker.worker2.cachesize=10 worker.worker2.cache_timeout=600 worker.worker2.socket_keepalive=1 worker "worker2" want ajp13 connection to be dropped after 5mn (timeout)worker.worker2.socket_timeout=300

　　

说明：上例中的worker要求操作系统在连接上发送KEEP-ALIVE信号。

注意：在ajpv13协议中默认端口为8009。
　　4.设置lb Worker属性：

负载平衡类型的worker并不与Tomcat worker通讯，它负责管理这些Tomcat worker。

其管理范围如下：

* 初始化在web server的worker列表中定义的worker。

* 使用worker的负载平衡权值，执行基于权值的负载平衡，将数量多的请求发送到负载平衡权值高（在web server看来就是更加健壮的）的worker。

* 维护在同一个Tomcat worker上的同一个session的请求，使其发送到同一个Tomcat worker上。以达到Tomcat worker上的session一致性、持续性。

* 标识已经失败的Tomcat workers，悬空发向它们的请求，在被lb worker管理的其它workers上寻找可以失败恢复的worker。

被同一个lb worker管理多个worker之间的负载平衡的（基于它们的lbfactor和当前用户session），也可以尽量避免由于单一的Tomcat进程死掉而造成这个网站被“杀”的不良反应。

下表说明了lb worker接受的属性：

* balanced_workers：一个由“，”分割的worker列表，用来声明lb worker需要被管理的workers。这些workers不应出现在worker.list属性中。

* sticky_session：表述是否将对SESSION ID的请求路由回到相同的Tomcat worker。如果属性值不为0，它将被设置为JK_TRUE，session将是粘性的，即SESSION ID的请求路由回到相同的Tomcat worker；当Tomcat正使用能够跨越多个Tomcat实例持久化session数据的Session Manager时，它将被设置为JK_FALSE。属性默认值为JK_TRUE。

例如：worker balance1管理着两个workers：worker1、worker2：

worker.balance1.balanced_workers=worker1, worker2

5.高级lb Worker属性：

JK 1.2.x版本通过增加两个新的属性：local_worker_only 和 local_worker 为lb worker增添了新的负载平衡和容错支持。

下面让我们举一个实际的环境作为example：

一个集群具有两个节点(worker1+worker2)，一个web server与tomcat workers一前一后，一个负载平衡器（lb Worker）位于节点的前面、web server的后面。

配置如下：



<ccid_nobr></ccid_nobr>

<ccid_code></ccid_code>worker.list=router# Define a 'local_worker' worker using ajp13worker.worker1.port=8009 worker.worker1.host=node1.domain.org worker.worker1.type=ajp13 worker.worker1.lbfactor=1 worker.worker1.local_worker=1# Define another 'local_worker' worker using ajp13worker.worker2.port=8009 worker.worker2.host=node2.domain.org worker.worker2.type=ajp13 worker.worker2.lbfactor=1 worker.worker2.local_worker=0# Define the LB workerworker.router.type=lb worker.router.balanced_workers= worker1,worker2worker. router.local_worker_only=1

　　

在worker1和worker2上的local_worker标志告诉lb_worker哪个连接属于本地worker。

如果local_worker值为非0，则它将被设置为JK_TRUE，用来标记“local worker”，而JK_FALSE的情况则相反。如果至少一个worker被标记为local worker，则lb_worker将工作于local worker模式。这种模式下，所有的local workers将被移到在lb_worker中的内部worker列表的头部。

这意味着一个带有session id的请求到达lb_worker时，相应的worker（根据权值排序，权值最大的那个worker）将被确定作为此请求的接受/处理者。如果这个worker死掉/当机，请求将被发送到处于非错误状态的第一个local worker；如果一个没有session id的请求到达lb_worker时，此请求将被路由到第一个local worker。

如果所有的local worker均处于错误状态，则这时“local_worker_only”标志显得尤其重要。如果local_worker_only的属性值为非0，则它被设置为 JK_TRUE，否则被设置为 JK_FALSE。

当它被设置为 JK_TRUE时，这个没有session id的请求将得到一个错误作为回应，否则lb_worker将尝试将请求路由到其它的被管理的worker上。如果其中的一个worker处于错误状态，并且恢复会话的工作并没有任何改变，local worker将查找这个没有session id的请求（因为在local worker中保存有这个请求的session），而其它的worker只能查找带有session id的请求。

注意：local_worker默认值是0，local_worker_only默认值也是0。