工作機制

zk從設計模式角度理解：是一個基于觀察者模式的分布式服務管理框架，它負責存儲和管理大家都關心的數(shù)據(jù)，然后接受觀察者的注冊，一旦數(shù)據(jù)狀態(tài)發(fā)生變化，zk就將負責通知已經在zk上注冊的觀察者做出反應。

特點

1.一個leader，多個follower組成的集群
2.集群中半數(shù)以上節(jié)點存活，zk就能正常服務，所以zk適合安裝奇數(shù)節(jié)點
3.全局數(shù)據(jù)一致：每個Server保存一份相同的數(shù)據(jù)副本，Client無論連接哪個server，數(shù)據(jù)都一致
4.更新請求順序執(zhí)行，來自同一個client的更新請求按其發(fā)送順序依次執(zhí)行
5.數(shù)據(jù)更新原子性：一個更新要么成功，要么失敗
6.實時性，在一定時間范圍內，Client能讀到最新數(shù)據(jù)

數(shù)據(jù)結構

樹形，每個znode默認能夠存儲1MB的數(shù)據(jù)，每個znode通過其路徑唯一標識。

應用場景

統(tǒng)一命名服務

圖片.png

統(tǒng)一配置管理

圖片.png

統(tǒng)一集群管理

圖片.png

服務器節(jié)點動態(tài)上下線

圖片.png

軟負載均衡

圖片.png

zookeeper集群

clientPort=2181 客戶端連接端口，通常不做修改
dataDir:保存zk數(shù)據(jù)
tickTime=2000 zk服務器與客戶端心跳時間
initLimit=10 LF初始通信時限。Leader和follower初始連接時能容忍的最多心跳數(shù)（tickTime數(shù)量）
syncLimit=5 LF同步通信時限。leader和follower通信時間如果超過syncLimit*tickTime，leader認為follower撕掉，從服務器列表移除follower

選舉機制

節(jié)點數(shù)據(jù)內容

1.czxid：創(chuàng)建節(jié)點的事務zxid
2.ctime：創(chuàng)建時間
3.mtime:最后修改時間
4.mzxid：最后更新的事務id
5.pzxid:znode最后更新的子節(jié)點zxid
6.cversion：znode子節(jié)點修改次數(shù)（子節(jié)點變化號）
7.dataversion:znode數(shù)據(jù)修改次數(shù)（數(shù)據(jù)變化號）
8.aclVersion：訪問控制列表的變化號
9.ephemeralOwner:如果是臨時節(jié)點，這是znode的sessionid，否則為0
10.dataLength:znode數(shù)據(jù)長度
11.numChildren:子節(jié)點數(shù)量

監(jiān)聽原理

1.main線程中創(chuàng)建zkCli，這時會創(chuàng)建兩個線程，一個負責網絡連接通信（connect），一個負責監(jiān)聽（listener）。
2.通過connect把監(jiān)聽事件發(fā)送給zk。
3.zk把監(jiān)聽事件添加到監(jiān)聽器列表中
4.zk監(jiān)聽到變化，將消息發(fā)送給listener線程
5.listener內部調用process方法

客戶端向服務端寫數(shù)據(jù)

圖片.png

圖片.png

zk分布式鎖

Curator框架實現(xiàn)分布式鎖

注：生產集群安裝多少zk合適：10臺服務器3zk，20臺服務器5zk，100服務器11zk，200服務器11zk