2.5.8　计算过程中的相关时间属性设置

我们有时在计算过程中，发现ParkServer窗口输出的信息如图2-23所示。

图2-23　工人忙碌提示

如果ParkServer窗口出现“INFO：_worker_faultworker.13D7C5BDC9A-11FF07AC4566cant be deleted or not exist!”的信息，并不是框架出故障了，而是表明：您的工人当前太繁忙了，无法按照跟职介所约定的心跳时间保持联系，职介所长时间没有收到该名工人的联系，认为他已经不活跃了，将其从活跃工人列表中删除，于是出现了上面的提示信息。不过职介所将工人从活跃列表删除，并不影响本次计算，因为职介所将工人介绍给包工头后，计算过程中是包工头和工人直接交互，不再依赖职介所。受影响的是下次计算时，包工头再次到职介所获取工人时，职介所不会再推荐该名工人了。

在config.xml的Park部分配置里，有下面两个时间配置项：

<HEARTBEAT>3000</HEARTBEAT>
<MAXDELAY>0</MAXDELAY>

HEARTBEAT是心跳时间，默认配置是3000毫秒，也就是3秒钟工人和职介所保持一次联系，可以根据计算需要调整这个心跳时间。

注意

在同台机器，工人、职介所、包工头共用一个配置文件时，修改HEARTBEAT即可。如果工人、职介所、职介所在不同机器，拥有各自的配置文件，需要将各自文件的HEARTBEAT配置为一致。

我们从上面注意到，工人和职介所失去联系，可能仅仅是因为计算太忙碌，而不是因为工人机器故障宕机，同样的情况还有网络波动等，因此，为了让职介所不轻易删除掉工人节点，可以设置一个抢救期，只要是在抢救期内能恢复联系，那么不认为该工人节点死亡，过了抢救期，才判定死亡。

MAXDELAY是抢救期时间，默认配置是0毫秒，也就是关闭状态，默认不进行抢救期判断，如果需要，修改MAXDELAY为一个大于0的值。

为了演示抢救期的效果，我们还是使用前面FaultWorker的例子，只不过是把配置项改为：

<HEARTBEAT>6</HEARTBEAT>
<MAXDELAY>8</MAXDELAY>

我们把心跳时间和抢救时间改的非常小，这个时间具体多小可以根据当前机器调整，心跳时间很小时，工人来不及和职介所联系，于是会达到我们演示效果的目的。

启动ParkServerDemo以及FaultWorker，之后出现图2-24所示的结果。

图2-24　心跳抢救时间设置

我们从上面的信息可以看到

WARNING: _worker_faultworker、13D80B483C2-697540AA5E1 slow and weak heartbeat!

表明心跳联系缓慢，已经处在抢救期内，如果超过了抢救期，那么最后会判定节点死亡并从职介所删除。

在计算很繁忙的时候，为了不影响工人和职介所保持联系，可以将HEARTBEAT时间设置的比较长一些，比如30秒或者以上，但是也意味着集群节点真的故障宕机，需要30秒延时才能感知，因此，可以通过进一步配置MAXDELAY抢救时间，既避免工人计算繁忙时跟职介所失去联系，也可以避免集群状态感知的太长时间延迟。