JAVA複習筆記分布式篇：zookeeper

標籤：com   應用程式   透明   32位   目的   問題   Google   同步   電腦   

前言：終於到分布式篇，前面把JAVA的一些核心知識複習了一遍，也是一個JAVA程式員最基本要掌握的知識點，接下來分布式的知識點算是互連網行業的JAVA程式員必備的技能；

概念:ZooKeeper是一個分布式的，開放源碼的分布式應用程式協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個為分布式應用提供一致性服務的軟體，提供的功能包括：配置維護、網域名稱服務 (DNS)、分布式同步、組服務等

關鍵詞：分布式，一致性服務 

講得通俗一點，zookeeper的誕生就是為瞭解決分布式一致性的問題。

什麼是分布式一致性？

分布式：分布式系統是由一組通過網路進行通訊、為了完成共同的任務而協調工作的電腦節點群組成的系統。分布式系統的出現是為了用廉價的、普通的機器完成單個電腦無法完成的計算、儲存任務。其目的是利用更多的機器，處理更多的資料。

一致性：指對每個節點一個資料的更新，整個叢集都知道更新，並且是一致的 ；

PS：通俗一點以前一台伺服器支撐一個系統的模式升級為多台伺服器（多個容器）去支撐一個系統，這樣這個系統的並發、容災等各方面的能力將得到大大提升（傳統的ngix和叢集也能做到），分布式和叢集最大的一個區別是分布式的節點都是不同業務（比如帳號系統，訂單系統，物流系統，商品系統各自部署在不同伺服器上）這樣做的好處是可以根據不同模組的特性合理地分配資源（比如帳號系統訪問量很大，需要部署3-5台機器，而物流系統的訪問量較小，只需要部署1-2台伺服器即可），一致性就是雖然帳號系統部署了3台伺服器，對於client而言是透明的（訂單系統調用帳號系統的服務，不用知道調用的哪台伺服器上的系統，  結果每次都能得到等冪），那麼如何保證每次都能得到這個等冪結果？也就是zookeeper的要解決的問題

基本架構圖

 

　角色：

　　群首（leader）： Leader作為整個ZooKeeper叢集的主節點，負責響應所有對ZooKeeper狀態變更的請求；

　　追隨者（follower）：除了響應本伺服器上的讀請求外（exists，getData，getChildren等唯讀請求），follower還要處理leader的提議，並在leader提交該提議時在本地也進行提交

　　觀察者（observer）：Observer和Follower比較相似，只有一些小區別：首先observer不參加選舉也不響應提議；其次是observer不需要將事務持久化到磁碟，一旦observer被重啟，需要從leader重新同步整個名字空間。

整個zookeeper叢集只有這3種角色，可以看到leader只有一個，所有對資料變更的請求都需要有leader去調度（leader會向所有節點發送原子廣播，收到一半以上的節點都同意的訊息後才真正提交這個事務），所以leader這個節點相當重要，那如何確立這個learder呢？

答案是選舉，zookeeper採用選舉的方式確立leader（觸發選舉的情境分為2種，一種是伺服器初始化啟動時候，還有一種是伺服器運行期間無法和Leader保持串連）

講解選舉過程前先需要瞭解幾個名詞

electionEpoch：每執行一次leader選舉，electionEpoch就會自增，用來標記leader選舉的輪次

peerEpoch：每次leader選舉完成之後，都會選舉出一個新的peerEpoch，用來標記事務請求所屬的輪次

zxid：事務請求的唯一標記，由leader伺服器負責進行分配。由2部分構成，高32位是上述的peerEpoch，低32位是請求的計數，從0開始。所以由zxid我們就可以知道該請求是哪個輪次的，並且是該輪次的第幾個請求。

lastProcessedZxid：最後一次commit的事務請求的zxid

選舉過程（第一次部署）：假設當前有3台伺服器（server0，server1，server3）部署zk ，依次啟動，第一次投票時候每台伺服器都會把票投給自己，投票資訊包含自身節點id和事務id   zxid，第一次server0投出（0,0），server1投出（1,0）server2投出（2,0）

每個節點投完自己的票之後會接收其他伺服器的投票資訊，server0接到server1的投票（1,0）,因為     

==============================================未完待續=======================================

　　

 

JAVA複習筆記分布式篇：zookeeper