**狀態感知、配置管理、主從選舉
**zookeeper 是一個分散式協調服務，就是為使用者的分散式應用程式提供協調服務；
1.為別的分散式程式服務的
2.zookeeper本身就是一個分散式程式（只要半數以上的節點存活，zk就能正常服務）
3.zookeeper所提供的服務涵蓋：主從協調，伺服器節點動態上下線、統一配置管理、分散式共享鎖，同意名稱服務
4.雖然說可以提供各種服務，但是zookeeper在底層其實只提供了兩個功能：
管理（儲存，讀取）使用者程式提交的資料（配置管理）
併為資料提供監聽服務

**應用場景：1、服務端採集客戶端程式的資料進行分析，四臺客戶端對四臺服務端，實時流式，使用ftp傳送給服務端，
假如其中一臺伺服器宕機了，假設成功重啟，但是還要下載重啟之前的未接收的資料，負載比較大，跟不上實時的資料傳輸
解決方案：伺服器在zk上面註冊（/server/server01 /server/server02）,zk將伺服器的狀態資料或者使用者程式的資料儲存下來，並對註冊的伺服器進行監聽；（資料保管）
工作流程：因為所有機器都有一個父節點server,zk在server上進行監聽，假設其中有一臺伺服器宕機，zk監聽到，其他伺服器讀一下server下的子節點，就知道哪個伺服器宕機，選舉一個空閒伺服器接管這個宕機伺服器的工作（節點監聽）

2、為了服務高可用，同種服務有多臺伺服器，選哪個作為master(主從選舉)
解決方案：在zk上註冊伺服器/server/server01 state ip /server/server02 state ip並進行監聽！！
根據zk的選舉演算法，master,就選舉出來了。
客戶端在訪問伺服器之前先訪問server父節點，看看子節點誰是master，然後進行訪問，假設master宕機了,其他伺服器都收到zk的監聽訊息，就繼續選舉新的master,客戶端再去zk的server看看誰是新的master,再進行訪問
3、solrcloud
solr是伺服器版搜尋引擎單機版，在多臺機器上儲存同一個索引庫，進行切片多臺機器儲存（機器1 分片1 機器2 分片2），每個機器都有一個solr服務程序
幾臺機器的索引庫的配置資訊要一致（使用過程中配置資訊可能動態改變，包括分詞器的選擇，增加索引欄位等等），每臺伺服器的配置資訊要一致，如何保證伺服器的配置資訊更新一起成功
解決方案：將配置資訊放在zk伺服器上面，zk對資料進行監聽，一改變就通知伺服器群讀取新的配置，伺服器群一起去zk上面讀取資訊（保管資料，提供監聽，配置管理）

**廣播協議

**主從選舉使用PAXOS選舉演算法的簡化–>Zab

**選舉演算法（假設配置檔案中註冊了三臺）：
1.第一臺myid=1啟動，投自己, 1票，只有一票，等其他機器啟動
2.第二天myid=2啟動，發現沒有master,進行投票，1和2進行投票，1投給自己和2，2投自己和1，都是2票，一看沒有選出來，根據裡面演算法規則，投myid大的，1投給2,2投給2 （1:2票，2:4票）leader為2，1為follower
3.第三臺啟動，發現有leader 結束

**資料更新 假設訪問到follwer ,資料會傳送到leader,leader通知各個follower更新資料（假設機器叢集太大，一個leader要讓所有機器資訊都更新會有延遲，所以不適合對時間一致要求很高的系統）

**配置：
1、conf/zoo.cfg
tickTime 心跳週期（預設2000ms）
initLimit 初始化階段心跳時間個數（預設10個）
syncLimit 傳送一個請求到獲得響應之間最大的時差（5個心跳），超過5個心跳就認為請求得不到響應
dataDir 資料目錄，zk叢集資料的存放目錄
clientPort 客戶端訪問的埠(預設2181)
使用者補上
server.1 = zk1:2888:3888 (2888是leader和follower通訊埠，3888是投票通訊埠)
server.2 = zk2:2888:3888 ….

2、在dataDir裡面配置myid檔案，裡面存放該機器的myid數值

配置完畢

**啟動指令： zkCli.sh(或zkServer.sh) start
檢視狀態 zkServer.sh status

**客戶端命令：
ls /
create (-e)(短暫，不寫預設持久) (-s)（帶序號的節點，節點後面生成一個序號，可以防止命名重複） /app1 “資料”
get /app1 可以檢視—>節點資料
get /app1 watch(監聽節點資料，只能監聽一次本身節點的資料狀態，監聽不了其他子節點)
ls /app1 watch (監聽子節點變化)
set /app1 “修改資料”
rmr /app1 遞迴刪除節點
delete /app1 非遞迴刪除
quit

get /app1 可以檢視—>
“資料”
Stat{
cZxid 事務控制的編號
ctime 建立時間
mZxid 事務控制的編號（每次修改，都會遞增，而且是全域性遞增）
mtime
pZxid 事務控制的編號
cversion 建立版本號
dataVersion
ephemeralOwner
dataLength
numChildren 子節點數
}
**zk資料結構Znode(短暫（斷開連線自己刪除）和持久（斷開連線自己不刪除）)
樹狀結構
0 (/)根節點
(/app1)0 0 (/app2)
0 0 0 0 0 0

javaapi
create(節點，資料，許可權，節點型別)
獲取子節點getChildren(節點,boolean watch)
getData獲取znode資料
setData
exists(path,watch)
delete(節點，-1) -1表示刪除所有版本的znode

監聽機制：
客戶端在使用zk時候，會啟動兩個執行緒，一個監聽執行緒一個連線執行緒，連線執行緒將客戶端的埠等資料傳送給zk叢集，一旦zk節點發生變化，就將監聽事件傳送給客戶端監聽執行緒的port,實現監聽

伺服器動態上下線：關鍵，註冊臨時-序列化節點，伺服器下線就自動刪除這個臨時節點，伺服器可以用setdata在節點上編輯自己被連線的次數，實現負載均衡
客戶端先訪問zk,檢視註冊列表，並對列表進行監聽，可以感知伺服器下線 ，假如下線了，客戶端的watcher中的process方法中重新獲取伺服器列表，並再次註冊監聽