[[389119]]

起因

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

復現問題

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

結果意想不到的是使用mntr命令查看，所有的機器狀態都是正常，但是zk client無法訪問，一訪問就卡住，問題可以在測試環境穩定復現。

問題排查

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

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

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

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

在CommitProcessor我們發現了原因，代碼如下：

<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中調用了 workerPool.join實際上已經將請求處理的開關關閉了，但是并沒有將workerPool設置為null。在start方法中會根據workerPool==null來創建WorkerService并開始處理請求。

修改后重新驗證解決。