**# 1.zookeeper**
它是一個分布式開源的應用程序協調服務,它是集群的管理者,監視著集群中各個節點的狀態,根據節點提交的反饋進行下一步合理操作,最終將簡單易用的接口和性能高效,功能穩定的系統提供給用戶
它提供了文件系統,通知機制
**# 2.文件系統(znode)**
每個子目錄項如 NameService 都被稱作為znode,和文件系統一樣,我們能夠自由的增加、刪除znode,在一個znode下增加、刪除子znode,唯一的不同在于znode是可以存儲數據的。
有四種類型的znode:
<1>、PERSISTENT-持久化目錄節點
客戶端與zookeeper斷開連接后,該節點依舊存在
<2>、PERSISTENT_SEQUENTIAL-持久化順序編號目錄節點
客戶端與zookeeper斷開連接后,該節點依舊存在,只是Zookeeper給該節點名稱進行順序編號
<3>、EPHEMERAL-臨時目錄節點
客戶端與zookeeper斷開連接后,該節點被刪除
<4>、EPHEMERAL_SEQUENTIAL-臨時順序編號目錄節點
客戶端與zookeeper斷開連接后,該節點被刪除,只是Zookeeper給該節點名稱進行順序編號
**# 3.Zookeeper通知機制**
客戶端注冊監聽它關心的目錄節點,當目錄節點發生變化(數據改變、被刪除、子目錄節點增加刪除)時,zookeeper會通知客戶端。
**# 4.Zookeeper做了什么?**
1.命名服務 2.配置管理 3.集群管理 4.分布式鎖 5.隊列管理
**# 5.分布式與數據復制 **
Zookeeper作為一個集群提供一致的數據服務,自然,它要在所有機器間做數據復制。數據復制的好處:
<1>、容錯:一個節點出錯,不致于讓整個系統停止工作,別的節點可以接管它的工作;
<2>、提高系統的擴展能力 :把負載分布到多個節點上,或者增加節點來提高系統的負載能力;
<3>、提高性能:讓客戶端本地訪問就近的節點,提高用戶訪問速度。
**#
6.從客戶端讀寫訪問的透明度來看,數據復制集群系統分下面兩種:**
<1>、寫主(WriteMaster) :對數據的修改提交給指定的節點。讀無此限制,可以讀取任何一個節點。這種情況下客戶端需要對讀與寫進行區別,俗稱讀寫分離;
<2>、寫任意(Write Any):對數據的修改可提交給任意的節點,跟讀一樣。這種情況下,客戶端對集群節點的角色與變化透明。
對zookeeper來說,它采用的方式是寫任意。通過增加機器,它的讀吞吐能力和響應能力擴展性非常好,而寫,隨著機器的增多吞吐能力肯定下降(這也是它建立observer的原因),而響應能力則取決于具體實現方式,是延遲復制保持最終一致性,還是立即復制快速響應。
**# 7.角色和描述**
角色:領導者(Leader) 描述:領導者負責進行投票的發起和決議,更新系統狀態
角色:學習者(Learner) ---又分為 跟隨者:(Follower) 和 觀察者: (obServer)
---跟隨者:用于接收客戶請求并向客戶端返回結果,在選主過程中參與投票。
---觀察者:可以接收客戶端連接,將請求轉發給領導者節點,但是它不參加投票的過程,只是同步領導者的狀態,它的目的是為了擴展系統,提高讀取速度。
角色:客戶端 (Client) 描述:請求發起方
**# 8.zookeeper工作原理**
Zookeeper 的核心是原子廣播,這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式,它們分別是恢復模式(選主)和廣播模式(同步)。當服務啟動或者在領導者崩潰后,Zab就進入了恢復模式,當領導者被選舉出來,且大多數Server完成了和 leader的狀態同步以后,恢復模式就結束了。狀態同步保證了leader和Server具有相同的系統狀態。
為了保證事務的順序一致性,zookeeper采用了遞增的事務id號(zxid)來標識事務。所有的提議(proposal)都在被提出的時候加上了zxid。實現中zxid是一個64位的數字,它高32位是epoch用來標識leader關系是否改變,每次一個leader被選出來,它都會有一個新的epoch,標識當前屬于那個leader的統治時期。低32位用于遞增計數。
**#
9.zookeeper下Server工作狀態**
每個Server在工作過程中有三種狀態:
LOOKING:當前Server不知道leader是誰,正在搜尋
LEADING:當前Server即為選舉出來的leader
FOLLOWING:leader已經選舉出來,當前Server與之同步
**# 10.Zookeeper選主流程(basic paxos)**
當leader崩潰或者leader失去大多數的follower,這時候zk進入恢復模式,恢復模式需要重新選舉出一個新的leader,讓所有的Server都恢復到一個正確的狀態。Zk的選舉算法有兩種:一種是基于basic paxos實現的,另外一種是基于fast paxos算法實現的。系統默認的選舉算法為fast paxos。
<1>. 選舉線程由當前Server發起選舉的線程擔任,其主要功能是對投票結果進行統計,并選出推薦的Server;
<2>. 選舉線程首先向所有Server發起一次詢問(包括自己);
<3>. 選舉線程收到回復后,驗證是否是自己發起的詢問(驗證zxid是否一致),然后獲取對方的id(myid),并存儲到當前詢問對象列表中,最后獲取對方提議的leader相關信息(id,zxid),并將這些信息存儲到當次選舉的投票記錄表中;
<4>. 收到所有Server回復以后,就計算出zxid最大的那個Server,并將這個Server相關信息設置成下一次要投票的Server;
<5>. 線程將當前zxid最大的Server設置為當前Server要推薦的Leader,如果此時獲勝的Server獲得n/2 + 1的Server票數,設置當前推薦的leader為獲勝的Server,將根據獲勝的Server相關信息設置自己的狀態,否則,繼續這個過程,直到leader被選舉出來。 通過流程分析我們可以得出:要使Leader獲得多數Server的支持,則Server總數必須是奇數2n+1,且存活的Server的數目不得少于n+1. 每個Server啟動后都會重復以上流程。在恢復模式下,如果是剛從崩潰狀態恢復的或者剛啟動的server還會從磁盤快照中恢復數據和會話信息,zk會記錄事務日志并定期進行快照,方便在恢復時進行狀態恢復。
**# 11.Zookeeper同步流程**
選完Leader以后,zk就進入狀態同步過程。
<1>. Leader等待server連接;
<2>. Follower連接leader,將最大的zxid發送給leader;
<3>. Leader根據follower的zxid確定同步點;
<4>. 完成同步后通知follower 已經成為uptodate狀態;
<5>. Follower收到uptodate消息后,又可以重新接受client的請求進行服務了。
**# 12.Zookeeper工作流程-Leader**
<1> .恢復數據;
<2> .維持與Learner的心跳,接收Learner請求并判斷Learner的請求消息類型;
<3> .Learner的消息類型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息,根據不同的消息類型,進行不同的處理。
PING 消息是指Learner的心跳信息;
REQUEST消息是Follower發送的提議信息,包括寫請求及同步請求;
ACK消息是 Follower的對提議的回復,超過半數的Follower通過,則commit該提議;
REVALIDATE消息是用來延長SESSION有效時間。
**# 13.Zookeeper工作流程-Follower**
Follower主要有四個功能:
<1>. 向Leader發送請求(PING消息、REQUEST消息、ACK消息、REVALIDATE消息);
<2>. 接收Leader消息并進行處理;
<3>. 接收Client的請求,如果為寫請求,發送給Leader進行投票;
<4>. 返回Client結果。
**# 14.返回Client結果。**
Follower的消息循環處理如下幾種來自Leader的消息:
<1> .PING消息: 心跳消息;
<2> .PROPOSAL消息:Leader發起的提案,要求Follower投票;
<3> .COMMIT消息:服務器端最新一次提案的信息;
<4> .UPTODATE消息:表明同步完成;
<5> .REVALIDATE消息:根據Leader的REVALIDATE結果,關閉待revalidate的session還是允許其接受消息;
<6> .SYNC消息:返回SYNC結果到客戶端,這個消息最初由客戶端發起,用來強制得到最新的更新。