• 概述
• 安裝
• 結構與原理
• 應用場景
• Zookeeper rmi高可用實現
• 基於zookeeper
• redis高可用實現需求分析
什麼是Zookeeper
» Zookeeper 是 Google 的 Chubby一個開源的實現,是 Hadoop 的分佈式協調服務
» 它包含一個簡單的原語集,分佈式應用程序可以基於它實現同步服務,配置維護和命名服務等
爲什麼使用 Zookeeper
» 大部分分佈式應用需要一個主控、協調器或控制器來管理物理分佈的子進程(如資源、任務分配等)
» 目前,大部分應用需要開發私有的協調程序,缺乏一個通用的機制
» 協調程序的反覆編寫浪費,且難以形成通用、伸縮性好的協調器
» ZooKeeper:提供通用的分佈式鎖服務,用以協調分佈式應用
• Keepalived監控節點不好管理
• Keepalive 採用優先級監控
• 沒有協同工作
• 功能單一
• Keepalive可擴展性差
Zookeeper優點
zookeeper的工作原理
1.每個Server在內存中存儲了一份數據;
2.Zookeeper啓動時,將從實例中選舉一個leader(Paxos協議)
3.Leader負責處理數據更新等操作
4.一個更新操作成功,當且僅當大多數Server在內存中成功修改數據。
Zookeeper 能幫我們做什麼?
» Hadoop,使用Zookeeper的事件處理確保整個集羣只有一個NameNode,存儲配置信息等.
» HBase,使用Zookeeper的事件處理確保整個集羣只有一個HMaster,察覺HRegionServer聯機和宕機,存儲訪問控制列表等.
Zookeeper的特性
» Zookeeper是簡單的
» Zookeeper是富有表現力的
» Zookeeper具有高可用性
» Zookeeper採用鬆耦合交互方式
» Zookeeper是一個資源庫
Zookeeper 的安裝和配置(集羣模式)
» 創建myid文件,server1機器的內容爲:1,server2機器的內容爲:2,server3機器的內容爲:3
» 在conf目錄下創建一個配置文件zoo.cfg,tickTime=2000
dataDir=/Users/zdandljb/zookeeper/data
dataLogDir=/Users/zdandljb/zookeeper/dataLog
clientPort=2181
initLimit=5
syncLimit=2
server.1=server1:2888:3888
server.2=server2:2888:3888
server.3=server3:2888:3888
參數解釋
• tickTime:發送心跳的間隔時間,單位:毫秒
• dataDir:zookeeper保存數據的目錄。
• clientPort:客戶端連接 Zookeeper 服務器的端口,Zookeeper 會監聽這個端口,接受客戶端的訪問請求。
• initLimit: 這個配置項是用來配置 Zookeeper 接受客戶端(這裏所說的客戶端不是用戶連接 Zookeeper 服務器的客戶端是 Zookeeper 服務器集羣中連接到 Leader 的Follower 服務器)初始化連接時最長能忍受多少個心跳時間間隔 數。當已經超過 5 個心跳的時間(也就是 tickTime)長度後 Zookeeper 服務器還沒有收到客戶端的返回信息, 那麼表明這個客戶端連接失敗。總的時間長度就是 5*2000=10 秒
• syncLimit:這個配置項標識 Leader 與 Follower 之間發送消息,請求和應答時間長度,最長不能超過多少個 tickTime 的時 間長度,總的時間長度就是 2*2000=4 秒
• server.A=B:C:D:其 中 A 是一個數字,表示這個是第幾號服務器;B 是這個服務器的 ip地址;C 表示的是這個服務器與 集羣中的 Leader 服務器交換信息的端口;D 表示的是萬一集羣中的 Leader 服務器掛了,需要一個端口來重 新進行選舉,選出一個新的 Leader,而這個端口就是用來執行選舉時服務器相互通信的端口。如果是僞集羣 的配置方式,由於 B 都是一樣,所以不同的 Zookeeper 實例通信端口號不能一樣,所以要給它們分配不同的 端口號。
Zookeeper的角色
» 領導者(leader),負責進行投票的發起和決議,更新系統狀態
» 學習者(learner),包括跟隨者(follower)和觀察者(observer),follower用於接受客戶端請求並想
客戶端返回結果, 在選主過程中參與投票
» Observer可以接受客戶端連接,將寫請求轉發給leader,但observer不參加投票過程,只同步leader的狀態,observer的 目的是爲了擴展系統,提高讀取速度
» 客戶端(client),請求發起方
• Zookeeper的核心是原子廣播,這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩 種模 式,它們分別是恢復模式(選主)和廣播模式(同步)。當服務啓動或者在領導者崩潰後,Zab就進入了恢復模式,當 領導者被選舉出來,且大多數Server完成了和leader的狀態同步以後,恢復模式就結束了。狀態同步保證了leader和Server 具有相同的系統狀態。
• 爲了保證事務的順序一致性,zookeeper採用了遞增的事務id號(zxid)來標識事務。所有的提議(proposal)都在被提出 的時候加上了zxid。實現中zxid是一個64位的數字,它高32位是epoch用來標識leader關係是否改變,每次一個leader被選 出來,它都會有一個新的epoch,標識當前屬於那個leader的統治時期。低32位用於遞增計數。
• 每個Server在工作過程中有三種狀態:
• LOOKING:當前Server不知道leader是誰,正在搜尋
• LEADING:當前Server即爲選舉出來的leader
• FOLLOWING:leader已經選舉出來,當前Server與之同步
Zookeeper 的讀寫機制
» Zookeeper是一個由多個server組成的集羣
» 一個leader,多個follower
» 每個server保存一份數據副本
» 全局數據一致
» 分佈式讀寫
» 更新請求轉發,由leader實施
Zookeeper 的保證
» 更新請求順序進行,來自同一個client的更新請求按其發送順序依次執行
» 數據更新原子性,一次數據更新要麼成功,要麼失敗
» 全局唯一數據視圖,client無論連接到哪個server,數據視圖都是一致的
» 實時性,在一定事件範圍內,client能讀到最新數據
Zookeeper節點數據操作流程
• Follower主要有四個功能:
• 1. 向Leader發送請求(PING消息、REQUEST消息、ACK消息、REVALIDATE消息);
• 2 .接收Leader消息並進行處理;
• 3 .接收Client的請求,如果爲寫請求,發送給Leader進行投票;
• 4 .返回Client結果。
• Follower的消息循環處理如下幾種來自Leader的消息:
• 1 .PING消息: 心跳消息;
• 2 .PROPOSAL消息:Leader發起的提案,要求Follower投票;
• 3 .COMMIT消息:服務器端最新一次提案的信息;
• 4 .UPTODATE消息:表明同步完成;
• 5 .REVALIDATE消息:根據Leader的REVALIDATE結果,關閉待revalidate的session還是允許其接受消息;
• 6 .SYNC消息:返回SYNC結果到客戶端,這個消息最初由客戶端發起,用來強制得到最新的更新。
Zookeeper leader選舉
• 半數通過
– 3臺機器 掛一臺 2>3/2
– 4臺機器 掛2臺 2!>4/2
• A提案說,我要選自己,B你同意嗎?C你同意嗎?B說,我同意選A;C說,我同意選A。(注意,這裏超過半數了,其實在現 實世界選舉已經成功了。但是計算機世界是很嚴格,另外要理解算法,要繼續模擬下去。)
• 接着B提案說,我要選自己,A你同意嗎;A說,我已經超半數同意當選,你的提案無效;C說,A已經超半數同意當選,B提 案無效。
• 接着C提案說,我要選自己,A你同意嗎;A說,我已經超半數同意當選,你的提案無效;B說,A已經超半數同意當選,C的 提案無效。
• 選舉已經產生了Leader,後面的都是follower,只能服從Leader的命令。而且這裏還有個小
細節,就是其實誰先啓動誰當頭。
zxid
• zxid
• znode節點的狀態信息中包含czxid, 那麼什麼是zxid呢?
• ZooKeeper狀態的每一次改變, 都對應着一個遞增的Transaction id, 該id稱爲zxid. 由於zxid的遞增性質, 如果zxid1小於 zxid2, 那麼zxid1肯定先於zxid2發生. 創建任意節點, 或者更新任意節點的數據, 或者刪除任意節點, 都會導致Zookeeper狀 態發生改變, 從而導致zxid的值增加.
Zookeeper 工作原理
» Zookeeper的核心是原子廣播,這個機制保證了各個server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩 種模式,它們分別是恢復模式和廣播模式。當服務啓動或者在領導者崩潰後,Zab就進入了恢復模式,當領導者被選舉出 來,且大多數server的完成了和leader的狀態同步以後,恢復模式就結束了。狀態同步保證了leader和server具有相同的系 統狀態。
» 一旦leader已經和多數的follower進行了狀態同步後,他就可以開始廣播消息了,即進入廣播狀態。這時候當一個server加 入zookeeper服務中,它會在恢復模式下啓動,發現leader,並和leader進行狀態同步。待到同步結束,它也參與消息廣 播。Zookeeper服務一直維持在Broadcast狀態,直到leader崩潰了或者leader失去了大部分的followers支持。
» 廣播模式需要保證proposal被按順序處理,因此zk採用了遞增的事務id號(zxid)來保證。所有的提議(proposal)都在被提 出的 時候加上了zxid。實現中zxid是一個64爲的數字,它高32位是epoch用來標識leader關係是否改變,每次一個leader 被選出來,它都會有一個新的epoch。低32位是個遞增計數。
» 當leader崩潰或者leader失去大多數的follower,這時候zk進入恢復模式,恢復模式需要重新選舉出一個新的leader,讓 所有的server都恢復到一個正確的狀態。
Leader 選舉
» 每個Server啓動以後都詢問其它的Server它要投票給誰。
» 對於其他server的詢問,server每次根據自己的狀態都回復自己推薦的leader的id和上一次處理事務的zxid(系統啓動時每 個server都會推薦自己)
» 收到所有Server回覆以後,就計算出zxid最大的哪個Server,並將這個Server相關信息設置成下一次要投票的Server。
» 計算這過程中獲得票數最多的的sever爲獲勝者,如果獲勝者的票數超過半數,則改server被選爲leader。否則,繼續這個 過程,直到leader被選舉出來
» leader就會開始等待server連接
» Follower連接leader,將最大的zxid發送給leader
» Leader根據follower的zxid確定同步點
» 完成同步後通知follower 已經成爲uptodate狀態
» Follower收到uptodate消息後,又可以重新接受client的請求進行服務了
數據一致性與 數據一致性與paxos算法
• 據說Paxos算法的難理解與算法的知名度一樣令人敬仰,所以我們先看如何保持數據的一致性,這裏有個原則就是:
• 在一個分佈式數據庫系統中,如果各節點的初始狀態一致,每個節點都執行相同的操作序列,那麼他們最後能得到一個一致
的狀態。
• Paxos算法解決的什麼問題呢,解決的就是保證每個節點執行相同的操作序列。好吧,這還不簡單,master維護一個全局寫 隊列,所有寫操作都必須 放入這個隊列編號,那麼無論我們寫多少個節點,只要寫操作是按編號來的,就能保證一致性。沒 錯,就是這樣,可是如果master掛了呢。
• Paxos算法通過投票來對寫操作進行全局編號,同一時刻,只有一個寫操作被批准,同時併發的寫操作要去爭取選票,只有 獲得過半數選票的寫操作纔會被 批准(所以永遠只會有一個寫操作得到批准),其他的寫操作競爭失敗只好再發起一輪投 票,就這樣,在日復一日年復一年的投票中,所有寫操作都被嚴格編號排 序。編號嚴格遞增,當一個節點接受了一個編號爲 100的寫操作,之後又接受到編號爲99的寫操作(因爲網絡延遲等很多不可預見原因),它馬上能意識到自己 數據不一致 了,自動停止對外服務並重啓同步過程。任何一個節點掛掉都不會影響整個集羣的數據一致性(總2n+1臺,除非掛掉大於n 臺)。
• 總結
• Zookeeper 作爲 Hadoop 項目中的一個子項目,是 Hadoop 集羣管理的一個必不可少的模塊,它主要用來控制集羣中的 數據,如它管理 Hadoop 集羣中的 NameNode,還有 Hbase 中 Master Election、Server 之間狀態同步等。
Observer
• Zookeeper需保證高可用和強一致性;
• 爲了支持更多的客戶端,需要增加更多Server;
• Server增多,投票階段延遲增大,影響性能;
• 權衡伸縮性和高吞吐率,引入Observer
• Observer不參與投票;
• Observers接受客戶端的連接,並將寫請求轉發給leader節點;
• 加入更多Observer節點,提高伸縮性,同時不影響吞吐率。
• 爲什麼zookeeper集羣的數目,一般爲奇數個?
Leader選舉算法採用了Paxos協議;Paxos核心思想:當多數Server寫成功,則任務數據寫成功如果有3個Server,則兩個 寫成功即可;如果有4或5個Server,則三個寫成功即可。Server數目一般爲奇數(3、5、7)如果有3個Server,則最多允 許1個Server掛掉;如果有4個Server,則同樣最多允許1個Server掛掉由此,我們看出3臺服務器和4臺服務器的的容災能力 是一樣的,所以爲了節省服務器資源,一般我們採用奇數個數,作爲服務器部署個數。
Zookeeper 的數據模型
» 層次化的目錄結構,命名符合常規文件系統規範
» 每個節點在zookeeper中叫做znode,並且其有一個唯一的路徑標識
» 節點Znode可以包含數據和子節點,但是EPHEMERAL類型的節點不能有子節點
» Znode中的數據可以有多個版本,比如某一個路徑下存有多個數據版本,那麼查詢這個路徑下的數據就需要帶上版本
» 客戶端應用可以在節點上設置監視器
» 節點不支持部分讀寫,而是一次性完整讀寫
Zookeeper 的節點
» Znode有兩種類型,短暫的(ephemeral)和持久的(persistent)
» Znode的類型在創建時確定並且之後不能再修改
» 短暫znode的客戶端會話結束時,zookeeper會將該短暫znode刪除,短暫znode不可以有子節點
» 持久znode不依賴於客戶端會話,只有當客戶端明確要刪除該持久znode時纔會被刪除
» Znode有四種形式的目錄節點
» PERSISTENT、
» EPHEMERAL
» PERSISTENT_SEQUENTIAL、
» EPHEMERAL_SEQUENTIAL
org.apache.zookeeper.ZooKeeper類主要方法列表
觀察( watcher )
» Watcher 在 ZooKeeper 是一個核心功能,Watcher 可以監控目錄節點的數據變化以及子目錄的變化,一旦這些狀態發生 變化,服務器就會通知所有設置在這個目錄節點上的 Watcher,從而每個客戶端都很快知道它所關注的目錄節點的狀態發 生變化,而做出相應的反應
» 可以設置觀察的操作:exists,getChildren,getData
» 可以觸發觀察的操作:create,delete,setData
ACL
» 每個znode被創建時都會帶有一個ACL列表,用於決定誰可以對它執行何種操作
• KeeperState.SyncConnected 時事件類型爲EventType.None發生在客戶端收到ConnectResponse,與客戶端協調好 session time的時間後,會觸發一個KeeperState.SyncConnected 的None事件類型。
» 身份驗證模式有三種:
» digest:用戶名,密碼
» host:通過客戶端的主機名來識別客戶端
» ip: 通過客戶端的ip來識別客戶端
» new ACL(Perms.READ,newId("host","example.com"));這個ACL對應的身份驗證模式是host,符合該模式的
身份是 example.com,權限的組合是:READ
應用場景1-統一命名服務
» 分佈式應用中,通常需要有一套完整的命名規則,既能夠產生唯一的名稱又便於人識別和記住,通常情況下用樹形的名稱結 構是一個理想的選擇,樹形的名稱結構是一個有層次的目錄結構,既對人友好又不會重複。
» Name Service 是 Zookeeper 內置的功能,只要調用 Zookeeper 的 API 就能實現
» 配置的管理在分佈式應用環境中很常見,例如同一個應用系統需要多臺 PC Server 運行,但是它們運行的應用系統的某些配 置項是相同的,如果要修改這些相同的配置項,那麼就必須同時修改每臺運行這個應用系統的 PC Server,這樣非常麻煩而 且容易出錯。» 將配置信息保存在 Zookeeper 的某個目錄節點中,然後將所有需要修改的應用機器監控配置信息的狀態, 一旦配置信息發生變化,每臺應用機器就會收到Zookeeper 的通知,然後從 Zookeeper 獲取新的配置信息應用到系統 中。
應用場景2-配置管理
應用場景3-集羣管理
» Zookeeper 能夠很容易的實現集羣管理的功能,如有多臺 Server 組成一個服務集羣,那麼必須要一個“總管”知道當前集 羣中每臺機器的服務狀態,一旦有機器不能提供服務,集羣中其它集羣必須知道,從而做出調整重新分配服務策略。同樣當 增加集羣的服務能力時,就會增加一臺或多臺 Server,同樣也必須讓“總管”知道。
» Zookeeper 不僅能夠維護當前的集羣中機器的服務狀態,而且能夠選出一個“總管”,讓這個總管來管理集羣,這就是 Zookeeper 的另一個功能 LeaderElection。
» 規定編號最小的爲master,所以當我們對SERVERS節點做監控的時候,得到服務器列表,只要所有集羣機器邏輯認爲最小編 號節點爲master,那麼master就被選出,而這個master宕機的時候,相應的znode會消失,然後新的服務器列表就被推送到 客戶端,然後每個節點邏輯認爲最小編號節點爲master,這樣就做到動態master選舉。
總結
» Zookeeper 作爲 Hadoop 項目中的一個子項目,是Hadoop 集羣管理的一個必不可少的模塊,它主要用來控制集羣中的數 據,如它管理 Hadoop 集羣中的NameNode,還有 Hbase 中 Master Election、Server 之間狀態同步等。
» Zoopkeeper 提供了一套很好的分佈式集羣管理的機制,就是它這種基於層次型的目錄樹的數據結構,並對樹中的節點進行 有效管理,從而可以設計出多種多樣的分佈式的數據管理模型