工做中遇到如下問題:
一、一臺zk節點失聯後,重啓一直沒法加入zk集羣中,致使沒法對外提供服務
二、zk的log和快照佔大量空間
三、客戶端鏈接有失敗有成功
四、zk客戶端偶爾會有失敗鏈接
五、報錯:smaller server identifier,so dropping服務器
以上問題生產環境中常常會遇到網絡
現象: 使用zkCli.sh沒法鏈接成功該zk節點
日誌: 首先想到的是將該節點restart, 但問題依舊, 故查看zk的log, 有大量的以下日誌併發
2018-07-18 17:31:12,015 - INFO [WorkerReceiver Thread:FastLeaderElection@496] - Notification: 1 (n.leader), 77309411648 (n.zxid), 1 (n.round), LOOKING (n.state), 1 (n.sid), LOOKING (my state) 2018-07-18 17:31:12,016 - INFO [WorkerReceiver Thread:FastLeaderElection@496] - Notification: 3 (n.leader), 73014444480 (n.zxid), 831 (n.round), LEADING (n.state), 3 (n.sid), LOOKING (my state) 2018-07-18 17:31:12,017 - INFO [WorkerReceiver Thread:FastLeaderElection@496] - Notification: 3 (n.leader), 77309411648 (n.zxid), 832 (n.round), FOLLOWING (n.state), 2 (n.sid), LOOKING (my state) 2018-07-18 17:31:15,219 - INFO [QuorumPeer:/0.0.0.0:2181:FastLeaderElection@697] - Notification time out: 6400
解決辦法:
這個是在3.3.4版本中的一個bug,在新版本中3.5已經修復了,建議使用最新版本
若是你使用的是這個版本,那你只能經過重啓leader來解決了tcp
現象:zk的datadir下的version-2下有不少快照,日誌目錄下有大日誌文件(單個文件太大),有些東西是沒有用的,因此建議按期清除
解決辦法:在zk的配置文件中添加自動清理日誌和快照的開關autopurge.purgeInterval=1,固然也能夠中過個年autopurge.snapRetainCount來設置須要保留的snapshot文件個數,默認是3個。ide
現象:客戶端的鏈接有的能夠連,有的鏈接失敗
日誌:Too many connection from 127.0.0.1 -max is 60
解決辦法:
更改zk配置的鏈接數maxClientCnxns 加大這個值,默認是60,不建議設置的太大,防止DDOS×××高併發
現象:有時客戶端偶爾會連不上zk
緣由:.net
這種狀況比較複雜,跟代碼及邏輯有關係了,以及當前的業務量有關係,好比zk處理大量的短鏈接請求時,SYN QUEUE的accept queue有時候被打滿,這就尷尬了,直接致使鏈接失敗。
詳細能夠查看這篇文章
https://blog.csdn.net/varyall/article/details/79681562
解決辦法:
syn隊列的大小是系統用來限制網絡的高併發的,具體參數以下:
net.ipv4.tcp_max_syn_backlog和net.core.somaxconn,這兩值設置爲同樣便可
若是過小了,會致使這種問題,須要按量提升,不要過高了。
生產環境中最終的解決辦法是最好下降和zk的短鏈接數量,這樣就基本不會出這種問題。rest
現象:使用客戶端鏈接無法連上,查看zk日誌,發現不少報錯報錯:smaller server identifier,so dropping
解決辦法:
按zk的myid的大小從小到大一次重啓zk服務器,首先保證有問題的zk不重啓。
分析緣由:zk是須要集羣中全部機器兩兩創建鏈接的, 其中配置中的3555端口是用來進行選舉時機器直接創建通信的端口, 大id的server纔會去鏈接小id的server,避免鏈接浪費.若是是最後重啓myid最小的實例,該實例將不能加入到集羣中, 由於不能和其餘集羣創建鏈接日誌