Zookeeper基礎及簡單集群配置

  • 2020 年 1 月 16 日
  • 筆記

基礎篇

1、zookeeper是什麼 Zookeeper,一種分散式應用的協作服務,是Google的Chubby一個開源的實現,是Hadoop的分散式協調服務,它包含一個簡單的原語集,應用於分散式應用的協作服務,使得分散式應用可以基於這些介面實現諸如同步、配置維護和分集群或者命名的服務。

zookeeper是一個由多個service組成的集群,一個leader,多個follower,每個server保存一份數據部分,全局數據一致,分散式讀寫,更新請求轉發由leader實施.

更新請求順序進行,來自同一個client的更新請求按其發送順序依次執行,數據更新原子性,一次數據更新要麼成功,要麼失敗,全局唯一數據試圖,client無論連接到哪個server,數據試圖是一致的.

2、為什麼要用zookeeper 大部分分散式應用需要一個主控、協調器或控制器來管理物理分布的子進程（如資源、任務分配等）,目前,大部分應用需要開發私有的協調程式,缺乏一個通用的機制.協調程式的反覆編寫浪費,且難以形成通用、伸縮性好的協調器,ZooKeeper：提供通用的分散式鎖服務,用以協調分散式應用

3、zookeeper工作原理 zookeeper的核心是原子廣播,這個機制保證了各個server之間的同步,實現這個機制的協議叫做Zab協議.Zab協議有兩種模式,他們分別是恢復模式和廣播模式.

（1）當服務啟動或者在領導者崩潰後,Zab就進入了恢復模式,當領導著被選舉出來,且大多數server都完成了和leader的狀態同步後,恢復模式就結束了.狀態同步保證了leader和server具有相同的系統狀態.

（2）一旦leader已經和多數的follower進行了狀態同步後,他就可以開始廣播消息了,即進入廣播狀態.這時候當一個server加入zookeeper服務中,它會在恢復模式下啟動,發下leader,並和leader進行狀態同步,待到同步結束,它也參與廣播消息.

說明:

廣播模式需要保證proposal被按順序處理,因此zk採用了遞增的事務id號(zxid)來保證.所有的提議(proposal)都在被提出的時候加上了zxid.實現中zxid是一個64為的數字,它高32位是epoch用來標識leader關係是否改變,每次一個leader被選出來,它都會有一個新的epoch.低32位是個遞增計數.    當leader崩潰或者leader失去大多數的follower,這時候zk進入恢復模式,恢復模式需要重新選舉出一個新的leader,讓所有的server都恢復到一個正確的狀態.    zookeeper服務一致維持在Broadcast狀態,直到leader崩潰了或者leader失去了大部分的followers支援.    Broadcast模式極其類似於分散式事務中的2pc（two-phrase commit 兩階段提交）：即leader提起一個決議,由followers進行投票,leader對投票結果進行計算決定是否通過該決議,如果通過執行該決議（事務）,否則什麼也不做.

3、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的請求進行服務了.

4、zookeeper的數據模型 層次化的目錄結構,命名符合常規文件系統規範 每個節點在zookeeper中叫做znode,並且其有一個唯一的路徑標識 節點Znode可以包含數據和子節點,但是EPHEMERAL類型的節點不能有子節點 Znode中的數據可以有多個版本,比如某一個路徑下存有多個數據版本,那麼查詢這個路徑下的數據就需要帶上版本 客戶端應用可以在節點上設置監視器,節點不支援部分讀寫,而是一次性完整讀寫

Zoopkeeper 提供了一套很好的分散式集群管理的機制,就是它這種基於層次型的目錄樹的數據結構,並對樹中的節點進行有效管理,從而可以設計出多種多樣的分散式的數據管理模型

5、Zookeeper的節點 Znode有兩種類型,短暫的（ephemeral）和持久的（persistent） Znode的類型在創建時確定並且之後不能再修改 短暫znode的客戶端會話結束時,zookeeper會將該短暫znode刪除,短暫znode不可以有子節點 持久znode不依賴於客戶端會話,只有當客戶端明確要刪除該持久znode時才會被刪除 Znode有四種形式的目錄節點,PERSISTENT、PERSISTENT_SEQUENTIAL、EPHEMERAL、EPHEMERAL_SEQUENTIAL.

znode 可以被監控,包括這個目錄節點中存儲的數據的修改,子節點目錄的變化等,一旦變化可以通知設置監控的客戶端,這個功能是zookeeper對於應用最重要的特性,通過這個特性可以實現的功能包括配置的集中管理,集群管理,分散式鎖等等.

6、Zookeeper的角色 （1）領導者（leader）：負責進行投票的發起和決議,更新系統狀態 （2）學習者（learner）：包括跟隨者（follower）和觀察者（observer）. a、follower用於接受客戶端請求並想客戶端返回結果,在選主過程中參與投票 b、Observer可以接受客戶端連接,將寫請求轉發給leader,但observer不參加投票過程,只同步leader的狀態,observer的目的是為了擴展系統,提高讀取速度 （3）客戶端（client）,請求發起方

Watcher

Watcher 在 ZooKeeper 是一個核心功能,Watcher 可以監控目錄節點的數據變化以及子目錄的變化,一旦這些狀態發生變化,伺服器就會通知所有設置在這個目錄節點上的 Watcher,從而每個客戶端都很快知道它所關注的目錄節點的狀態發生變化,而做出相應的反應

可以設置觀察的操作：exists,getChildren,getData

可以觸發觀察的操作：create,delete,setData

znode以某種方式發生變化時,「觀察」（watch）機制可以讓客戶端得到通知.

可以針對ZooKeeper服務的「操作」來設置觀察,該服務的其他 操作可以觸發觀察.

比如,客戶端可以對某個客戶端調用exists操作,同時在它上面設置一個觀察,如果此時這個znode不存在,則exists返回 false,如果一段時間之後,這個znode被其他客戶端創建,則這個觀察會被觸發,之前的那個客戶端就會得到通知.

7、Zookeeper集群搭建

Zookeeper 不僅可以單機提供服務,同時也支援多機組成集群來提供服務,實際上Zookeeper還支援另外一種偽集群的方式,也就是可以在一台物理機上運行多個Zookeeper實例.

Zookeeper通過複製來實現高可用性,只要集合體中半數以上的機器處於可用狀態,它就能夠保證服務繼續。

命令篇

  • 連接遠程Server：zkCli.sh –server <ip>:<port> 比如連接到本地Zoopker服務： ./zkCli.sh -server localhost:2181
  • 查看節點數據：ls <path>，比如ls / 則查看根目錄節點數據
  • 查看某個服務Service的提供者 ls 服務名/providers
  • 查看節點數據並能看到更新次數等數據：ls2 <path>，輸出欄位含義如下： cZxid：創建節點的事務id ctime：創建節點的時間 mZxid：修改節點的事務id mtime：修改節點的時間 pZxid：子節點列表最後一次修改的事務id。刪除或添加子節點，不包含修改子節點的數據 cversion：子節點的版本號，刪除或添加子節點，版本號會自增 dataVersion：節點數據版本號，數據寫入操作，版本號會遞增 aclVersion：節點ACL許可權版本，許可權寫入操作，版本號會遞增 ephemeralOwner：臨時節點創建時的事務id，如果節點是永久節點，則它的值為0 dataLength：節點數據長度（單位：byte），中文佔3個byte numChildren：子節點數量
  • 創建節點：create <path> <data>
  • 獲取節點，包含數據和更新次數等數據：get <path>
  • 修改節點：set <path> <data>
  • 刪除節點：delete <path>，如果有子節點存在則刪除失敗

配置篇（集群配置）

1、建立一個文件夾，如：zookeeper-cluster 2、下載Zookeeper，解壓，重命名為zookeeper-node1，然後複製2份，分別命名，如圖：

Snip20181002_2.png

2、zoo.cfx文件解析（zookeeper-node1、zookeeper-node2、zookeeper-node3需要分別配置，大同小異）： zookeeper-node1配置：

#zookeeper-3.4.6-node1的配置  tickTime=2000  initLimit=10  syncLimit=5  clientPort=2181  dataDir=/export/search/zookeeper-cluster/zookeeper-3.4.6-node1/data  server.1=localhost:2887:3887  server.2=localhost:2888:3888  server.3=localhost:2889:3889

解析： tickTime=2000: tickTime這個時間是作為Zookeeper伺服器之間或客戶端與伺服器之間維持心跳的時間間隔,也就是每個tickTime時間就會發送一個心跳；

initLimit=10: initLimit這個配置項是用來配置Zookeeper接受客戶端（這裡所說的客戶端不是用戶連接Zookeeper伺服器的客戶端,而是Zookeeper伺服器集群中連接到Leader的Follower 伺服器）初始化連接時最長能忍受多少個心跳時間間隔數。 當已經超過10個心跳的時間（也就是tickTime）長度後 Zookeeper 伺服器還沒有收到客戶端的返回資訊,那麼表明這個客戶端連接失敗。總的時間長度就是 10*2000=20 秒；

syncLimit=5: syncLimit這個配置項標識Leader與Follower之間發送消息,請求和應答時間長度,最長不能超過多少個tickTime的時間長度,總的時間長度就是5*2000=10秒；

dataDir=/export/search/zookeeper-cluster/zookeeper-3.4.6-node1/data dataDir顧名思義就是Zookeeper保存數據的目錄,默認情況下Zookeeper將寫數據的日誌文件也保存在這個目錄里；

clientPort=2181 clientPort這個埠就是客戶端連接Zookeeper伺服器的埠,Zookeeper會監聽這個埠接受客戶端的訪問請求；

server.1=localhost:2887:3887 server.2=localhost:2888:3888 server.3=localhost:2889:3889 server.A=B：C：D： A是一個數字,表示這個是第幾號伺服器,B是這個伺服器的ip地址 C第一個埠用來集群成員的資訊交換,表示的是這個伺服器與集群中的Leader伺服器交換資訊的埠 D是在leader掛掉時專門用來進行選舉leader所用

zookeeper-node2配置：

#zookeeper-3.4.6-node2的配置  tickTime=2000  initLimit=10  syncLimit=5  clientPort=2182  dataDir=/Users/huangyuan/Documents/lib/zookeeper-cluster/zookeeper-node2/data  server.1=localhost:2887:3887  server.2=localhost:2888:3888  server.3=localhost:2889:3889

zookeeper-node3配置：

#zookeeper-3.4.6-node3的配置  tickTime=2000  initLimit=10  syncLimit=5  clientPort=2183  dataDir=/Users/huangyuan/Documents/lib/zookeeper-cluster/zookeeper-node3/data  server.1=localhost:2887:3887  server.2=localhost:2888:3888  server.3=localhost:2889:3889

參考：https://www.cnblogs.com/dennisit/p/4141342.html

VirMach 便宜 VPS

QNews

QNews