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

• 2021 年 5 月 18 日
• 筆記
• 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監聽此埠)