Question

我创建了一个Curator客户端，如下所示：

    RetryPolicy retryPolicy = new RetryNTimes(3, 1000);
    CuratorFramework client = CuratorFrameworkFactory.newClient(zkConnectString, 
            15000, // sessionTimeoutMs
            15000, // connectionTimeoutMs
            retryPolicy);

运行我的客户端程序时，我通过关闭Curator用来与Zookeeper通信的NIC来模拟网络分区。根据我所看到的行为，我有几个问题：

10秒后我看到ConnectionStateManager - State change: SUSPENDED消息。 Curator进入SUSPENDED状态的时间是否可配置，基于其他超时值的百分比，或总是10秒？
自上次成功检测到心跳后，配置的15秒会话超时后，我才收到任何通知。我执行在日志中看到ZooKeeper - Session: 0x14adf3f01ef0001 closed消息，但这似乎并不是我可以捕获或侦听的事件。我在这里错过了什么吗？
我最终在连接丢失后差不多两分钟收到ConnectionStateManager - State change: LOST消息。为什么这么久？
如果我的目标是使用InterProcessMutex作为防止HA场景中的裂脑的方法，那么最安全的方法似乎是锁定持有者在SUSPENDED时假设它已失去锁定收到消息，因为Zookeeper完全有可能释放锁在网络分区的另一端不知道它。这是一种典型/理智的方法吗？

Answer 1

这取决于你使用的是哪个版本的策展人（注：我是策展人的主要作者）......

在Curator 2.x中，LOST状态表示重试策略已用尽。这并不意味着会话已经丢失。在ZooKeeper中，只有在修复与集合的连接后，才会确定会话丢失。因此，当Curator看到第一个“Disconnected”消息时，您会被暂停。然后，当由于重试策略放弃而导致操作失败时，您将失败。

在Curator 3.x中，LOST的含义发生了变化。在3.x时，当收到“Disconnected”时，Curator启动内部计时器。当计时器通过协商会话超时时，Curator调用getTestable（）。injectSessionExpiration（）并发布LOST状态更改。

Answer 2

正确。假设SUSPEND和LOST失去了领导力。这是Apache Curator配方的工作方式。您可能希望使用Apache Curator而不是实现自己的算法。 https://curator.apache.org/curator-recipes/index.html

Answer 3

第一个问题，Zookeeper有一个名为MAX_SEND_PING_INTERVAL的变量，该变量为10秒，因此根据您的情况始终为10秒。代码在ClientCnxn类中。

//1000(1 second) is to prevent race condition missing to send the second ping
//also make sure not to send too many pings when readTimeout is small 
int timeToNextPing = readTimeout / 2 - clientCnxnSocket.getIdleSend() - 
        ((clientCnxnSocket.getIdleSend() > 1000) ? 1000 : 0);
//send a ping request either time is due or no packet sent out within MAX_SEND_PING_INTERVAL
if (timeToNextPing <= 0 || clientCnxnSocket.getIdleSend() > MAX_SEND_PING_INTERVAL) {
    sendPing();
    clientCnxnSocket.updateLastSend();
} else {
    if (timeToNextPing < to) {
        to = timeToNextPing;
    }
}

策展人中的超时配置

3 个答案: