Zookeeper bug的排查方法

本篇內(nèi)容主要講解“Zookeeper bug的排查方法”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“Zookeeper bug的排查方法”吧!

起因

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

復(fù)現(xiàn)問題

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

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

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

修改后重新驗證解決。

到此，相信大家對“Zookeeper bug的排查方法”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！