1)事務請求的惟一調度者和處理者。保證事務處理的順序性java
事務請求:致使數據一致性的請求(數據發生改變)。如刪除一個節點、建立一個節點、設置節點數據,設置節點權限就是一個事物請求,全局的事物id(zxid)只能由leader來分配git
2)集羣內部個服務器之間的調度者github
1)處理客戶端的非事務請求。事務請求必須轉發給Leader服務器。數據庫
非事物請求:讀取數據
2)參與事務請求Proposal(議案)的投票
3)參與Leader選舉apache
3. Observer設計模式
在實際運行中,它只是負責讀,Leader不會將事務的投票發送給Observer。
在zk的配置server.1=master:2888:3888後面加:observer之後就是一個Observer
server.1=master:2888:3888:observerapi
常見序列化協議:服務器
ProtoBuf
Thrift
Hessian
Kryo
Avro
JDK Serializable
Jsoniter/Jackson分佈式
Jute是zookeeper序列化、反序列化協議。spa
基於TCP/IP協議,因此是一個長鏈接。zookeeper在這個基礎上完成客戶端和服務器,服務器和服務器之間的通訊。
zookeeper請求包:請求頭+請求體
0-3 |
4-11 |
12-n |
|||
len |
4-7 |
8-11 |
12-15 |
16-(n-1) |
n |
xid |
type |
len |
path |
watch |
zookeeper響應包:響應頭+響應體
0-3 |
4-19 |
20 - n |
|||||
len |
4-7 |
8-15 |
16-19 |
20-23 |
len位 |
48位 |
8位 |
xid |
zxid |
err |
len |
data |
...... |
pzxid |
0-3位:version+dbid+magic(魔數)
Zk有個內存數據庫:ZkDataBase、DataTree、DataNode
運行時,不停地有數據寫入。
當日志的剩餘空間不足4K(4096),日誌就作擴充,擴充64M,後面以「0」填充。
log都是使用zxid做爲文件名的後綴。
查看日誌方式:
cd /software/zookeeper-3.4.6
java -cp ./zookeeper-3.4.6.jar::./lib/log4j-1.2.16.jar:./lib/slf4j-api-1.6.1.jar:./lib/slf4j-log4j12-1.6.1.jar org.apache.zookeeper.server.LogFormatter /zookeeper/zk1/version-2/log.100000001
說明:
1)必須在zookeeper的安裝目錄下執行
2)/zookeeper/zk1/是zookeeper配置文件裏面配置的數據目錄(dataDir)
快照數據:在某一時刻內存全部全量數據的一個磁盤文件。舉例:快照閾值100000,觸發快照數據。
快照數據都是使用Zxid做爲文件名的後綴。這樣的話,獲取快照數據的時候就不用遍歷了,直接根據Zxid去獲取就好了
查看快照命令:
cd /software/zookeeper-3.4.6
java -cp ./zookeeper-3.4.6.jar::./lib/log4j-1.2.16.jar:./lib/slf4j-api-1.6.1.jar:./lib/slf4j-log4j12-1.6.1.jar org.apache.zookeeper.server.SnapshotFormatter /zookeeper/zk1/version-2/snapshot.100000050
說明:
1)必須在zookeeper的安裝目錄下執行
2)/zookeeper/zk1/是zookeeper配置文件裏面配置的數據目錄(dataDir)
快照觸發機制,非「半數機制」,過半隨機策略。
logcount > (snapcount/2 + randroll)
logcount: 表明當前記錄日誌數量
snapcount: 多少次事務日誌記錄後觸發一次數據快照
randroll: 1~snapcount/2 之間的一個隨機數
ZK在分佈式系統中的各類應用,本質其實就是對節點的建立,刪除,數據更新等事件作監聽,監聽到之後作對應的操做
ZK是觀察者設計模式
都是爲了解決高可用,解決單點故障問題,數據可靠性