1、zookeeper的定義node
打開zookeeper官網,赫然一行大字,寫着:「Apache ZooKeeper致力於開發和維護實現高度可靠的分佈式協調的開源服務器」。什麼意思呢?就是Apache ZooKeeper的目標是開發和維護開源服務器,這服務器是幹什麼的呢?是作分佈式協調的。這服務器的特色是什麼呢?是高度可靠的。關鍵就是高度可靠,不用去驗證,也不用懷疑zookeeper的高度可靠性,搜索應用界的大佬solr和大數據服務界的大佬Hadoop就是使用zookeeper提供集羣管理。程序員
2、什麼是zookeeperapache
ZooKeeper誕生於Yahoo,後轉入Apache孵化,最終孵化成Apache的頂級項目,是Hadoop和Hbase的重要組件。ZooKeeper是一種集中式服務,用於維護配置信息、命名、提供分佈式同步和提供組服務。全部這些類型的服務都以分佈式應用程序的某種形式使用。因爲實現上述需求都須要作不少工做來修復不可避免的錯誤和競爭條件。所以,這些服務的實現變得很是困難,即便這些服務順利完成,管理和運維的成本也很是高,因此zookeeper以救世主的身份出現,解決上述技術難題,下降了分佈式應用程序的開發難度和工做量,讓程序員專一於分佈式架構的設計。服務器
3、zookeeper的三中部署方式網絡
一、獨立部署模式,即部署在單臺機器上的一個zookeeper服務,適用於學習、瞭解zookeeper基礎功能。架構
二、僞分佈模式,即部署在一臺機器上的多個(原則上大於3個)zookeeper服務,虛擬分佈式的zookeeper集羣,適用於學習、開發和測試,不適用生產環境。運維
三、全分佈式模式(複製模式),即在多臺機器上部署zookeeper服務,真正的集羣模式,適合於學習、開發和測試,可投入到生產環境中使用。分佈式
3、在什麼場景下使用zookeeperoop
一、集羣管理性能
①、節點監控:集羣環境下,有不少節點,節點可能由於網絡故障鏈接不上,可能由於機器故障沒法工做,要求保證集羣中的節點都能正常工做,就須要把異常的節點從集羣中屏蔽掉,這時使用zookeeper的短暫節點和watcher機制,能夠很好的實現集羣的管理。
②、領導者選舉:集羣是多個節點(可把節點理解爲機器)協同工做,這是須要一個把控全局的領導者節點來接收外部請求、任務派發等,那麼,領導者節點如何產生?領導者節點出現故障怎麼處理?領導者選舉是zookeeper最優秀的功能之一,若是當前領導者節點出現故障,zookeeper可在很短的時間內選舉出新的領導者來接替故障領導者的工做。
二、配置管理
實際應用中,配置使應用變得靈活,可是在分佈式應用下,須要到每一臺機上面修改配置,維護配置則複雜不少,基於這種場景,把配置放在zookeeper的znode中,分佈式應用的機器到zookeeper的znode中讀取配置應用到系統中便可。此外,利用zookeeper的watcher機制,若是配置(znode)發生改變,zookeeper通知各個機器配置信息已經被修改,各機器經過刷新來獲取到最新的配置。
zookeeper還能夠應用到不少場景,好比分佈式鎖、數據的發佈和訂閱、隊列管理等等,此處就不一一介紹了。
4、zookeeper的性能
zookeeper旨在提供高性能,可是zookeeper的性能如何呢?zookeeper官網提供了一份性能測試結果圖,經過分析測試結果圖,能夠大概瞭解zookeeper的性能,以下圖所示:
從測試結果圖得知測試分爲5組,分別爲3臺服務器一組(暫且稱爲A組)、5臺服務器一組(暫且稱爲B組)、7臺服務器一組(暫且稱爲C組)、9臺服務器一組(暫且稱爲D組)、13臺服務器一組(暫且稱爲E組),觀察到幾個現象:
①、讀取請求的百分比在60%以前,吞吐率爲A>B>C>D>E。
②、讀取請求百分比到達80%偏左側一點,大概75%時,吞吐率開始發生變化,A組的吞吐率開始被其餘組超越。
③、讀取請求百分比到達約95%時,吞吐率發生逆轉,約爲E>D>C>B>A,讀取請求百分比趨近於瓶頸時,zookeeper集羣約龐大,知足的吞吐率約高。
④、zookeeper集羣的吞吐率起點大約在10000左右,性能下限很高。
結論:
①、zookeeper小規模集羣也能提供較高的吞吐率,若是對吞吐率有較高要求時,能夠經過新增zookeepe服務節點來知足需求。
②、隨着zookeeper服務節點的增長,zookeeper的性能呈指數上升。
這篇博文是zookeeper系列的第一篇,對zookeeper作一個簡單的介紹,關於zookeeper的更多內容和實際操做,會在後續博文中詳述。
因爲能力有限,若有不足和錯誤之處,還望不吝指出!