背景

一個月左右zk掛了2次，在此期間
Mafka和其他服務不可用，因為業務(使用不當)原因導致zk掛掉,間接影響其他服務(包括mafka)可用性，目前線上多個業務和多種服務共同一套mobile-zk叢集，
只要一個業務使用不當，對zk造成影響或不可用，就會影響其他業務，所以現階段拆分zk叢集，做物理隔離，把mobile-zk叢集按照業務分拆為多個zk叢集。為mafka服務建立獨立zk叢集。

問題

2個原因造成zk叢集宕機

其一是業務混布,多個業務依賴同一個mobile-zk叢集，其二是zk叢集部署存在問題，zk例項部署沒有做隔離，一個虛擬機器部署3個zk例項。

業務使用zk不當

• 錯誤把zk當做kv儲存使用。
• 建立海量連線，耗盡資源最終壓垮zk叢集
• 其他不當操作等

前期zk部署方案

當時zk叢集中所有節點參與選舉，客戶端通過配置ip列表連線本地機房zk節點。由於業務使用不當很容導致所有節點掛掉導致zk叢集不可用，因為Kafka強依賴zk服務，這直接影響Kafka的可用性。

後期zk改進部署方案

部署改進：mafka-zk叢集包括三臺leader/follower和若干observer，每個機器上跑一個zk例項；客戶端通過域名與本機房的observer連線，不直接與選舉節點連線，觀察節點不夠可以隨時擴容。遷移收益：可擴充套件性：客戶端通過域名與本機房的observer連線，服務可以透明擴容和升級。可用性：mafka-zk叢集包括三臺follwer/leader和若干observer，客戶端只訪問observer，他的任何操作不會導致整個叢集掛掉，不會影響zk叢集可用性。

其他改進：流控和ip連線數限制，加強監控報警。

Zookeeper監控
可以使用淘寶的開源工具TaoKeeper進行監控。Zookeeper的監控包括下面幾個方面：
1、機器的CPU、記憶體、負載、硬碟IO利用率等基礎監控，這些均可以網管系統實現；
2、ZK日誌目錄所在磁碟空間監控，這可以針對性的監控；
3、各節點的程序監控，配置自動拉起等；
4、各節點的連線數監控，配置峰值告警；
5、各節點的Watcher數監控，配置峰值告警；
6、使用四字命令，對每個節點進行檢查，確保程序不僵死；
7、節點存活個數監控；