[[389119]]

起因

某一天突然有同事說zk client連不上server，考慮到最近業(yè)務(wù)代碼沒有變更，懷疑是運維同學做了什么操作導致，急忙聯(lián)系運維同學，確實最近做了變更。為了避免擴大影響范圍，先讓運維同學回滾了變更，回滾后可以正常訪問了。

復現(xiàn)問題

詢問運維同學后，得到變更流程：由于zk集群有一臺服務(wù)器存在性能隱患，需要變更到新的一個實例。于是運維先將新機器加入zk集群，修改舊服務(wù)器上配置逐個重啟，重啟后新zk的角色是leader，此時zk狀態(tài)正常，運維同學也就認為變更完成。

結(jié)果意想不到的是使用mntr命令查看，所有的機器狀態(tài)都是正常，但是zk client無法訪問，一訪問就卡住，問題可以在測試環(huán)境穩(wěn)定復現(xiàn)。

問題排查

1 猜測zk端口沒有監(jiān)聽成功，登錄服務(wù)器使用netstat查看server打開的三個端口都是正常狀態(tài)，也使用了telnet測試可以連上。

2 猜測同步節(jié)點數(shù)不足一半，或者follower連不上leader觸發(fā)重新選舉，但很快就被排除，因為上面說了使用mntr命令查看節(jié)點狀態(tài)都正常，從日志中也未能找到對應(yīng)日志記錄。

3 我們再使用stat來觀察server的連接情況，運行zk client發(fā)現(xiàn)server收到了client的請求，但是沒有回消息，看來原因就是zk server沒處理client的請求了。

跟蹤到這里，就應(yīng)該進入源碼了，由于對zk源碼不熟悉，咨詢了某位大佬，建議我們看zk請求處理類CommitProcessor。

在CommitProcessor我們發(fā)現(xiàn)了原因，代碼如下：

<code>@Override 
public void start() { 
    ... 
    if (workerPool == null) { 
        workerPool = new WorkerService("CommitProcWork", numWorkerThreads, true); 
    } 
    ... 
} 
 
public void shutdown() { 
    LOG.info("Shutting down"); 
 
    halt(); 
 
    if (workerPool != null) { 
        workerPool.join(workerShutdownTimeoutMS); 
    } 
 
    if (nextProcessor != null) { 
        nextProcessor.shutdown(); 
    } 
} 
</code><button>復制</button> 

在shutdown中調(diào)用了 workerPool.join實際上已經(jīng)將請求處理的開關(guān)關(guān)閉了，但是并沒有將workerPool設(shè)置為null。在start方法中會根據(jù)workerPool==null來創(chuàng)建WorkerService并開始處理請求。

修改后重新驗證解決。