zookeeper前言

很多初步瞭解zookeeper是什麼時候一定很蒙圈，因爲不知道是用在哪裏？如果有使用過dubbo框架的應該知道zookeeper應用當中起到的作用。本人拿着親身經歷zookeeper作爲dubbo的註冊中心爲大家講解zookeeper具體是個什麼東東？

zookeeper簡介紹

官方文檔上的解釋zookeeper，它是一個分佈式服務框架，是Apache Hadoop 的一個子項目，它主要是用來解決分佈式應用中經常遇到的一些數據管理問題，如：統一命名服務、狀態同步服務、集羣管理、分佈式應用配置項的管理等。

上面的解釋有點抽象，簡單來說zookeeper=文件系統+監聽通知機制。他提供的主要功:是一個典型的分佈式數據一致性解決方案，分佈式應用程序可以基於 ZooKeeper 實現諸如數據發佈/訂閱、負載均衡、命名服務、分佈式協調/通知、集羣管理、Master 選舉、分佈式鎖和分佈式隊列等功能。

dubbo中爲何使用zookeeper（如果理解dubbo實現原理可以忽略）

剛初學者對dubbo或許只知道是分佈式，但是確不明白是什麼，在這裏我用最通俗易懂的方式告訴大家：在以往我們做的簡單項目都是單點項目，在一個服務器上就可以獨立完成（以及數據庫tomcat項目部署都在一臺服務器上就可以搞定這就是簡單的項目，但是如果我們項目使用率增大，那一臺服務器會掛掉，這個時候爲了解決這樣的問題出現，就出現了dubbo分佈式開發框架）

1和圖2就可以清晰的看出 現在因爲需求增多拆分了這麼多個，部署在不同的服務器上，那是不是相對以前都在一個服務器上，現在分佈式後，web層調用service層的服務變成了遠程調用？那怎樣像以前那樣都在一個服務器上自然而然調用方法呢？dubbo來解決。這就是下面dubbo的好處。

dubho好處簡單介紹下

1.透明化的遠程方法調用，就像調用本地方法一樣調用遠程方法，只需簡單配置，沒有任何API侵入。
2.軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，降低成本，減少單點。
3. 服務自動註冊與發現，不再需要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的IP地址，並且能夠平滑添加或刪除服務提供者。（下面講解）
Dubbo採用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring加載Dubbo的配置即可，Dubbo基於Spring的Schema擴展進行加載。
dubbo最爲突出的兩個角色
Provider（生產者）: 暴露服務的服務提供方。
Consumer（消費者）: 調用遠程服務的服務消費方

dubbo如何使用zookeeper的

圖1和圖2可以清楚的知道 web1234需要調用service1234的服務，所以web1234是消費者，service1234是生在產者

通過此圖我們將消費層和生產層分離開了 那如果按照上面的圖片進行消費調用生產那是不是就會亂套呢？

就會變成這樣，這只是簡單的分佈式，那如果更多是不是就會更亂，所以這時候就會出現zookeeper了：
Registry（註冊中心）: 服務註冊與發現的註冊中心。dubbo推薦的是zookeeper。什麼是zookeeper？zookeeper是用於分佈式中一致性處理的框架。簡單的講，zookeeper就是個圖書館，圖書館的（生產者）把所有圖書放在圖書管進行管理（註冊中心）那裏，想借書的（消費者）去圖書館那裏獲得所有書的信息。於是，我們的圖變成了這樣

這時候zookeeper的作用就會出現了，通過此圖就可以看出來，zookeeper就是一個註冊中心，管理生產者和消費者的中心；

但是這還不夠，如果那個服務器掛到了怎麼辦？ Monitor: 統計服務的調用次調和調用時間的監控中心，監控服務器心跳，
來發一個dubbo官方給的圖 （從0開始看起）
往下看

zookeeper流程圖

自己腦海裏按照上圖走了一遍後，看看自己想的是不是和下面說明一樣。
0 服務容器負責啓動，加載，運行服務提供者。

1. 服務提供者（生產者）在啓動時，向註冊中心註冊自己提供的服務。
2. 服務消費者在啓動時，向註冊中心訂閱自己所需的服務。
3. 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
4. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
5. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心

dubbo和zookeeper簡單大白話講解

dubbo是service（interface）和serviceImpl（實現interface）的關係（service（interface）和serviceImpl（實現interface）分別寫在兩個項目或者多個項目），將這兩個分開到多個項目，比如查詢用戶信息一個springboot一個項目消費者也就是查詢接口入口service（interface）這個接口不做任何數據庫層業務邏輯，然後在用一個或者多個相同的springboot項目serviceImpl（實現interface），最後通過dubbo.xml文件配置上面接口和實現接口的配置和zookeeper信息，這時候zookeeper就是註冊中心的作用，來管理上面dubbo中service（interface）和serviceImpl（實現interface）信息，來實現分佈式，這樣也就解耦項目的流暢性 ，這樣可以通過上面的圖片也可以看出來整個過程，

zookeeper以什麼形式保存service（interface）和serviceImpl（實現interface）

1.大白話講解，就好比我們文件夾，我們創建一個文件夾，文件夾下面可以有多個文件信息，比如123.txt,1234.txt,這樣我們可以看出來，文件夾一般不會改變，我們稱爲永久性節點，而下面的文件信息是可以隨時刪除的，所以這樣就很好理解爲service爲永久性節點，他的實現接口serviceImpl可以有很多個稱爲臨時性節點，這樣就當你調用service時候可以再臨時性節點中serviceImpl調用，這樣就實現分佈式調用了哦，如果serviceImpl那個宕機，這樣就會調用其他的臨時性節點，也讓程序更加穩定公運行

2.官方解釋
1.每一個節點都稱之爲 znode，它可以有子節點，也可以有數據；
2.每個節點分爲臨時節點和永久節點，臨時節點在客戶端斷開後消失；
3.每個 zk 節點都有各自的版本號，可以通過命令(get path)來顯示節點信息；
4.每當節點數據發生變化，那麼該節點的版本號會累加（樂觀鎖）；
5.刪除/修改過時的節點，版本號不匹配則會報錯；
6.每個 zk 節點存儲的數據不宜過大，幾 kb 即可；
7.節點可以設置權限 acl（權限控制列表），可以通過權限來限制用戶的訪問；

宏觀性

（說句在通俗易懂的：dubbo就相當於將接口和實現層分離開，zookeeper將接口和實現層控制再它這裏，打個比方：如果你將dubbo負載均衡設置成隨機，那就是5000人同時訪問接口，這時候你是5個生產者，就會被zookeeper隨機發送給這5個生產者，既然是隨機就大概是每個生產者1000個訪問，這樣就會大大解耦，降低了高併發問題）

結束語

zookeeper就講到這裏，他的用處很廣泛，很多地方，大家有時間可以瞭解下，zookeeper的選舉機制有時間可以瞭解下還有zookeeper的集羣部署機制，大家可以瞭解下，集羣部署和選舉機制都是保護程序正常運行的關鍵。（集羣部署往往3臺或者5臺服務器，選舉機制是當某一個服務器掛掉，選舉出新的領導者來保證程序正常運行）