月份：2023年9月

现象：

一台机器的连接数忽然降低到个位数，且不恢复。

原因：

根据之前的排除经验，查看epoch指标，并没有发生变化，排除选举发生；

查看zxid没有发生变化，排除zxid。

排查packetReceived指标降低为0，说明自己关闭了自己的ZooKeeperServer。

查看机器日志如下：

很明显，出现问题的诱因是Connection reset问题，然后断开连接。第二行的日志显示它是和leader之间的连接出了问题，那么出现这种错误会如何呢？

首先，查询代码可知，能输出”Disconnected from leader”错误只能是Follower和Observer，以Follower为例：

org.apache.zookeeper.server.quorum.Follower#followLeader：
void followLeader() throws InterruptedException {
    self.end_fle = Time.currentElapsedTime();
    long electionTimeTaken = self.end_fle - self.start_fle;
    self.setElectionTimeTaken(electionTimeTaken);
    ServerMetrics.getMetrics().ELECTION_TIME.add(electionTimeTaken);
    LOG.info("FOLLOWING - LEADER ELECTION TOOK - {} {}", 
    //承担Follower角色

    try {
           QuorumServer leaderServer = findLeader();
        try {
            
            connectToLeader(leaderServer.addr, leaderServer.hostname);
            connectionTime = System.currentTimeMillis();
            //省略非核心
            QuorumPacket qp = new QuorumPacket();
            while (this.isRunning()) {
                //不断处理业务
                readPacket(qp);
                processPacket(qp);
            }
        } catch (Exception e) {
            LOG.warn("Exception when following the leader", e);
            closeSocket(); //关闭有问题的socket
         }
    } finally {
        //省略若干代码

        if (connectionTime != 0) {
            long connectionDuration = System.currentTimeMillis() - connectionTime;
            LOG.info(
                "Disconnected from leader (with address: {}). Was connected for {}ms. Sync state: {}",
                leaderAddr,
                connectionDuration,
                completedSync);
        }
    }

上面代码可以看出follower会一直处理业务请求，直到遇到错误，当遇到错误时，它会关闭连接，同时推出这个业务处理死循环，代码继续走到调用方，而调用方其实是QuorumPeer#run调用：

可以看出，follower.followLeader()平时不会执行退出，但是一旦执行完走出来，就会关闭Follower。然后更新状态为looking, 重新选举：

通过日志中的“LEADER ELECTION TOOK – 104 MS”，可以看出，花了104ms再次重新充当了Follower。考虑到这个时间很短，影响应该很小。

再回到这个问题的原始触发点，为什么会遇到connection reset，可以查看leader上是的日志线索：

通过上述日志可以看出是由于“transaction timeout”，那么这种错误指的是什么？什么时候会发生？找到代码所在地，它的位置就是LearnerHandler#ping方法？

public void ping() {
 
    long id;
    if (syncLimitCheck.check(System.nanoTime())) {
        id = learnerMaster.getLastProposed();
        QuorumPacket ping = new QuorumPacket(Leader.PING, id, null, null);
        queuePacket(ping);
    } else {
        LOG.warn("Closing connection to peer due to transaction timeout.");
        shutdown();
    }
}

顾名思义，肯定是做健康检查的。那什么时候会ping?  Leader启动后会执行Leader#lead方法，这个方法会一直持续检查follower/observer的情况，以决定是不是要断掉它们。

void lead() throws IOException, InterruptedException {
       long start =   Time.currentElapsedTime();
       long cur = start;
       long end = start + self.tickTime / 2;
       while (cur < end) {
          wait(end - cur);
          cur = Time.currentElapsedTime();
       } 

        startZkServer();
          
 
        while (true) {
            synchronized (this) {
                long start = Time.currentElapsedTime();
               
            for (LearnerHandler f : getLearners()) {
                f.ping();  //ping的调用，循环去ping follower/observer
            }
        }
 
    }  
}

同时仔细参考上述代码，还可以看出，它是每间隔一段时间做一次。间隔时间即上述代码中的“self.tickTime / 2”，其参数可配，默认如下：

public static final int DEFAULT_TICK_TIME = 3000;
protected int tickTime = DEFAULT_TICK_TIME;

那么，一旦做健康检查，它做的时机是什么？可以参考LearnerHandler.SyncLimitCheck，关键代码如下：

翻阅上面代码，结合之前的代码，大致可以了解到，在执行健康检查时，如果有正在做的业务，且做的业务请求如果已经在指定时间内还没有收到响应就算不健康了。如果它还没有到达超时时间，则发送一个ping请求到队列来做健康检查。如果当前根本没有业务，则也是直接发送一个ping。其中，超时时间也是配置项，不过它是必须配置的项目。

这里可以给出一个配置示例：

# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial 
# synchronization phase can take
initLimit=10
# The number of ticks that can pass between 
# sending a request and getting an acknowledgement
syncLimit=5

通过这个配置，可知，Leader每1秒做一次和Follower/Observer之间的健康检查，业务请求或者ping的响应最大超时时间为10秒。如果超过了，则leader会断开它们，然后他们遇到connection reset重新上线。

解决方案：

实际上，这种问题，通过上述的不断追问，我们已经知道，它的问题在于一个请求为什么会超过10秒没有返回。这种情况实际很多，例如主机资源使用率太高，请求量太大等，无法及时处理请求（本应用已排除这些因素），除了这点外，还有一些原因是不可控的。例如网络问题，导致的临时不可用。所以针对这个问题的解决方案是需要进一步观察，例如排查主机请求量等因素外，记录该问题发生的频率和时间以及区域特点，以做进一步明确和分析。