Zookeeper詳細使用解析！分布式架構中的協調服務框架最佳選型實踐

ZooKeeper概念

Zookeeper是分布式協調服務,用于管理大型主機,在分布式環境中協調和管理服務是很復雜的過程,Zookeeper通過簡單的架構和API解決了這個問題

Zookeeper實現分布式鎖

分布式鎖三要素: 加鎖 解鎖 鎖超時

Zookeeper數據結構類似樹結構,由節點Znode組成

Znode分為四種類型:

持久節點(PERSISTENT): 默認節點類型,創建節點的客戶端與Zookeeper斷開連接后,節點依舊存在

持久節點順序節點(PERSISTENT_SEQUENTIAL): 持久節點順序節點就是在創建持久節點時,Zookeeper根據創建節點的時間順序給節點進行編號

臨時節點(EPHEMERAL): 創建節點的客戶端與Zookeeper斷開連接后,臨時節點會被刪除

臨時節點順序節點(EPHEMERAL_SEQUENTIAL): 臨時節點順序節點就是在創建臨時節點時,Zookeeper根據創建節點的時間順序給節點進行編號

應用Zookeeper的臨時順序節點,實現分布式鎖

Zookeeper與Redis分布式鎖比較:

Zookeeper的數據模型

類似數據結構中的樹,文件系統中的目錄

Zookeeper的數據存儲基于節點Znode

Znode的引用方式是路徑引用,每一個Znode節點擁有唯一的路徑

Znode中的元素

data: Znode存儲的數據信息

ACL: 記錄Znode的訪問權限,即哪些進程和IP可以訪問本節點

stat: Znode的各種元數據(數據的數據)

child: 當前節點的子節點引用

Zookeeper的應用場景是讀多寫少的應用場景:Znode不用來存儲大規模的業務數據,用于存儲少量的狀態和配置信息(Znode存儲數據不能超過1MB)

Zookeeper基本操作

創建節點:create

刪除節點:delete

判斷節點是否存在:exists

獲得一個節點的數據:getData

設置一個節點的數據:setData

獲取節點下的所有子節點:getChildren

exists,getData,getChildren屬于讀操作,Zookeeper客戶端在請求讀操作時,可以選擇是否設置watch

Zookeeper事件通知

Watch可以理解成注冊在特定Znode上的觸發器

當Znode發生改變的時候,調用create,delete,setData方法,將會觸發Znode上注冊的對應事件,請求的Watch的客戶端會接收到異步通知

Zookeeper事件通知的交互過程:

客戶端調用getData方法,watch的參數是true,服務端接收到請求,返回節點數據,在對應的Hash表中插入被Watch的Znode路徑以及Watcher列表

當被Watch的Znode刪除,服務端會查找Hash表,找到該Znode對應的所有Watcher,異步通知客戶端,并且刪除Hash表中對應的key-value

Zookeeper的一致性

Zookeeper Service集群是一主多從結構

在更新數據時,首先更新到主服務器,再同步到從服務器

在讀數據時,直接讀取任意節點

采用ZAB協議,為了保證主從節點數據的一致性

ZAB協議

ZAB(Zookeeper Automic Broadcast): 解決Zookeeper集群崩潰恢復,主從數據同步問題

ZAB三種節點狀態:

Looking:選舉狀態

Following:Following節點(從節點)所處的狀態

Leading:Leading(主節點)所處的狀態

最大ZXID: 節點本地的最新事務編號,包含epoch和計數兩部分

ZAB集群崩潰恢復

當Zookeeper的主節點服務器宕機后,集群就會進行崩潰恢復,分成三個階段:

Leader election(選舉階段):

集群中的節點處于Looking狀態,各自向其它節點發起投票,投票當中包含自己服務器的ID和最新事務ID(ZXID)

節點用自身的ZXID和其它節點收到的ZXID作比較,如果發現其它節點的ZXID比自身大,即數據比自己新,就重新發起投票,投票給目前已知最大ZXID所屬節點

每次投票后,服務器都會統計投票數量,判斷是否某個節點得到半數以上的投票,這樣的節點將會成為準Leader,狀態變為Leading,其它節點狀態變為Following

Discovery(發現階段):

在從節點發現最新的ZXID和事務日志,目的是為了防止在意外情況,選舉產生多個Leader

Leader接收所有Follower發送的最新的epoch值,Leader從中選出最大的epoch,基于此值+1,生成新的epoch分發給各個Follower

各個Follower接收到最新的epoch,返回ACK(響應碼)給Leader,帶上各自最大的ZXID和歷史事務日志,Leader選出最大的ZXID,并更新自身歷史日志

Synchronization(同步階段):

將Leader收集得到的最新歷史事務日志,同步給集群中的所有Follower,只有當半數Follower同步成功,這個準Leader才能成為正式Leader.集群崩潰恢復正式完成

ZAB主從數據同步

Broadcast

Zookeeper常規情況下更新數據的時候,由Leader廣播到所有的Follower:

客戶端發出寫入數據請求給任意的Follower

Follower把寫入數據請求轉發給Leader

Leader采取二階段提交方式:(先保留提交日志,再提交數據)先發送Propose廣播給Follower

Follower接收到Propose消息,寫入日志成功后,返回ACK消息給Leader

Leader接收到半數以上的ACK消息,返回成功給客戶端,并且廣播commit請求給Follower

數據一致性: 強一致性 弱一致性 順序一致性:Zookeeper,依靠事務ID和版本號,保證數據的更新和讀取是有序的

Zookeeper應用場景

分布式鎖: 應用Zookeeper的臨時順序節點,實現分布式鎖

服務注冊與發現: 利用Znode和Watcher,實現分布式服務注冊與發現,如Dubbo

共享配置和狀態信息: Redis的分布式解決方案Codls,利用Zookeeper存放數據路由表和codls-proxy節點元信息,同時colds-config發起的命令都會通過Zookeeper同步到各個存活的codls-proxy

高可用實現: Kafka,HBase,Hadoop都依靠Zookeeper同步節點信息,實現高可用

基于Docker創建Zookeeper

1.創建docker-compose.yml zoo: image: zookeeper restart: always hostname: zoo ports: - 2181:2181 environment: - ZOO_MY_ID: 1 - ZOO_SERVER: server.1(id)=zoo(IP):2888:3888 2.執行docker-compose up -d

Zookeeper三種工作模式

單機模式: 存在單點故障

集群模式: 在多臺服務器上部署Zookeeper集群

偽集群模式: 在同一臺服務器上運行多個Zookeeper實例,仍然有單點故障問題,其中配置的端口號要錯開

Zookeeper三種端口號

2181: 客戶端連接Zookeeper集群使用的監聽端口號

3888: 選舉Leader使用

2888: 集群內機器通訊使用(Leader和Follower之間數據同步使用的端口號,Leader監聽此端口)

ZooKeeper 分布式

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。