zookeeper客戶端KeeperErrorCode = ConnectionLoss異常問題排查歷險記

通過線報，說前方應用有異常，致使了可用性變差。咦！討厭的異常，拋異常是程序猿最討厭的事情之一。

通過收集異常信息以下

 

​

 

​

2019-06-24 10:57:41.806 ERROR [hades-afe-opw,,,] 67380 --- [erFactory-Timer] c.t.p.s.s.TBScheduleManagerFactory       : KeeperErrorCode = ConnectionLoss for /taobao-pamirs-schedule/hades-earn-opw/factory/10.10.128.163$tjsr-2$9235182DDA104802AB642BC0CF418A22$0000003165

org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss for /taobao-pamirs-schedule/hades-earn-opw/factory/10.10.114.63$tjsr-2$9235182DDA104802AB642BC0CF418A22$0000003165
 at org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
 at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
 at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1045)
 at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:1073)
 at com.taobao.pamirs.schedule.zk.ScheduleStrategyDataManager4ZK.loadManagerFactoryInfo(ScheduleStrategyDataManager4ZK.java:295)
 at com.taobao.pamirs.schedule.strategy.TBScheduleManagerFactory.refresh(TBScheduleManagerFactory.java:164)
 at com.taobao.pamirs.schedule.strategy.ManagerFactoryTimerTask.run(TBScheduleManagerFactory.java:438)
 at java.util.TimerThread.mainLoop(Timer.java:555)
 at java.util.TimerThread.run(Timer.java:505)

　　

一看異常很神祕，

從異常的表面意思看就是去zookeeper查詢某個node是否存在而後爆出了 KeeperErrorCode = ConnectionLoss這個錯誤

通過各類查詢說須要調優zookeeper，具體狀況你們能夠自行進行搜索。

---

咱們的實現立刻轉移到zookeeper上面，觀察zk的運行環境。

咱們通過了以下各類過程處理（如下是未成功的處理）：

         加內存：2G-->4G（雖然咱們知道加內存沒有用，本身內心安慰一下萬一能解決那，哈哈）

         加CPU：4C-->6C

         換磁盤空間並打開虛擬機讀寫限制

         移動虛擬機主機位置

調整先後統計對比圖：

 

網絡 I/O：sar -n DEV 1

 

​

CPU I/O: vmstat 1

​

 

磁盤 I/O : sar -d 1

​

 

 

這裏我說下通過各類環境的取值分析得出以下現象和結論：

現象：

        CPU有點高可是在可接受範圍內

        內存徹底夠用不存在內存溢出可能

        磁盤讀寫徹底沒有達到所能承受的上限

        網絡一樣沒有達到可用的上限

        問題指標

                  發現cpu執行的IO等待高，why？

通過各類數據的分析有了以下大膽的猜想，

        zookeeper是強一致性的分佈式系統，

        CAP理論中它屬於CP系列，

        因此對於讀寫有強一致的要求，

        大量併發狀況下對一個文件的讀寫（zookeeper日誌文件 log.xxxxx的那個文件）會有排隊想象同時他還會對從機進行分發數據，

        搞得主機（master）很忙形成cpu的操做都在等待那一個文件上面，

        但實際上讀寫的內容並很少，

        也就沒有達到磁盤的上限。

        而後就形成了主動斷開鏈接上面的異常 ConnectionLoss。

        也就是說這個異常我的猜想是zookeeper的主動行爲，不然的話會報超時異常。

 

因此針對各類分析與搜索以及實踐有以下兩種方法解決：

1. 設置zookeeper自己的參數forceSync=no 
2. 將日誌文件寫入目錄指向內存句柄

以上兩個方案都有一個弊端，就是在zookeeper集羣中master忽然斷電的時候會形成少許數據由於沒有落盤而丟失，因此對於數據有相應要求的狀況請慎用

本次採用第二種方法：修改zoo.cfg配置文件：

dataLogDir=/zookeeper/logs 修改成
dataLogDir=/dev/shm

從目前狀況看問題基本解決，也請你們調整相關係統框架與zookeeper的心跳頻率，以減小zk的壓力。